为你的抽象选择合适的名称很重要。如果名称不好，那么我们的设计将很难重复使用。例如，假设我们要设计一个可以关闭/打开灯的开关。
您认为该接口的好名字是什么？
banq注：如果从纯粹面向对象角度看，这种接口可以取“控制面板”或 "Swtichable"之类，用来解耦Switch和Lamp，但是取名需要上下文，当我们放入上下文去理解时，Switch和Lamp属于业务领域模型，而开关动作应该时Switch这个对象本身的动作，根本不应该独立成接口，Lamp实体可作为Switch聚合的一部分，如果上下文更复杂，Lamp属于另外一个有界上下文，那么Switch发出两个领域事件：开和关，这个事件发送到另外一个上下文中Lamp并作为命令改变其状态。
DDD分析方法和OO面向对象还是有区别的：DDD注重上下文和业务含义，这点反映在给对象取名中，有人说过：取名和缓存是计算机科学中最难的两件事，通常我们关注：名称是什么？给它取什么名称呢？其实忽视了一个大的问题，名称是一种物体对象的代指，当你思考取什么名称时，已经默认了这个名称代指的那个对象已经存在，而真正问题是：那个对象本身是否存在就值得怀疑，比如本例中给接口取名，但是接口本身是否有存在意义就值得怀疑！
这种误区通常来自我们的主语语言思考方式，维根斯坦认为语言决定了人的思考，当我们用主语语法时，例如它叫什么名称？名称是什么？这两句话的主语分别是“它”、“名称”，当我们用这种主语语法时，默认已经认为“它”肯定已经存在，其实“它”未必存在，我们没有去考究一下“它”是否真的存在。这类似海德格尔哲学了。正是这种主语语法限制遮蔽了我们的思考方向，形成一个思考陷阱或误区，这种误区是方向性的，是战略的：战略性思维模式MindSet的优势以及如何开发？ 。
另外一个DDD和OO不同的案例分析：API优先（API-first）是一个坏主意！
以命令和事件作为接口形式的设计：荷兰还有媲美光刻机的软技术：组件建模和分析框架Comma为复杂软件提供了高可靠性