DDD和OO是有区别的:抽象名称选择很重要?主语语法遮蔽了真理 - macerub

20-09-02 banq

为你的抽象选择合适的名称很重要。如果名称不好,那么我们的设计将很难重复使用。例如,假设我们要设计一个可以关闭/打开灯的开关。

您认为该接口的好名字是什么?

banq注:如果从纯粹面向对象角度看,这种接口可以取“控制面板”或 "Swtichable"之类,用来解耦Switch和Lamp,但是取名需要上下文,当我们放入上下文去理解时,Switch和Lamp属于业务领域模型,而开关动作应该时Switch这个对象本身的动作,根本不应该独立成接口,Lamp实体可作为Switch聚合的一部分,如果上下文更复杂,Lamp属于另外一个有界上下文,那么Switch发出两个领域事件:开和关,这个事件发送到另外一个上下文中Lamp并作为命令改变其状态。

DDD分析方法和OO面向对象还是有区别的:DDD注重上下文和业务含义,这点反映在给对象取名中,有人说过:取名和缓存是计算机科学中最难的两件事,通常我们关注:名称是什么?给它取什么名称呢?其实忽视了一个大的问题,名称是一种物体对象的代指,当你思考取什么名称时,已经默认了这个名称代指的那个对象已经存在,而真正问题是:那个对象本身是否存在就值得怀疑,比如本例中给接口取名,但是接口本身是否有存在意义就值得怀疑!

这种误区通常来自我们的主语语言思考方式,维根斯坦认为语言决定了人的思考,当我们用主语语法时,例如它叫什么名称?名称是什么?这两句话的主语分别是“它”、“名称”,当我们用这种主语语法时,默认已经认为“它”肯定已经存在,其实“它”未必存在,我们没有去考究一下“它”是否真的存在。这类似海德格尔哲学了。正是这种主语语法限制遮蔽了我们的思考方向,形成一个思考陷阱或误区,这种误区是方向性的,是战略的:战略性思维模式MindSet的优势以及如何开发? 

另外一个DDD和OO不同的案例分析:API优先(API-first)是一个坏主意!

以命令和事件作为接口形式的设计:荷兰还有媲美光刻机的软技术:组件建模和分析框架Comma为复杂软件提供了高可靠性  

 

                   

2
猜你喜欢