关于DDD中Domain的思考

本文既不推销UML，也不推广DDD，更不涉及各类论战。-- 做者

    某天又一次打开关于DDD(领域驱动设计)的PDF文档时，本身有了个疑问：什么是领域(Domain)？译文中是这样描述领域：银行业务被银行的内部人员和专家所熟知。他们知道全部的细节、全部的困难、全部可能 出现的问题、全部的业务规则。这些就是咱们永远的起始点：领域。若是这就是领域，它彷佛不是"起始点"，而是“所有”--所有的业务规则、所有的细节、所有可能出现的问题。个人疑问正是始于此：Domain映射到软件，"所有"不就是整个系统？

    这里有个概念漏洞，Domain是"所有"，但不是全世界的"所有"，那它是什么的所有？显然，译文中看到的"银行业务"，其对应的Domain也不是指银行业务系统的所有，所以Domain的概念相对清晰--一个有清晰边界、内部的业务、规则、问题、细节都自成一派--你会问我，这是指对象(Object)吧！若是从低层次上讲，二者是有关系的。下一个疑问：Domain和Object有什么不一样？

    我思考的结果是封装的级别不一样：Object封装的目标是调用其方法实现所承诺的功能，但系统中的对象是有依赖的；Domain封装的目标是"所有"都在这里，即不须要依赖其余的Object或者Domain。之因此这么想，主要的依据是从那个经常使用的例子：机场、航线、飞机，虽然我看的译文中把这三个定义为对象，使用UML画了聚合关系；我更倾向于把它们当作Domain，即我认为机场不会调用飞机的方法（或者人），二者只是相互关注了对方(的事件)。例如，飞机A1和机场B1经过无线电沟通(消息)。Object间的消息通常是带着发送者或者接受者的数据，也就是A1发送的是B1要处理的；而Domain间的消息是否处理，如何处理则是彻底由接收者本身处理，发送者也不关心消息的处理。再一个疑问：如何达到"所有"封装？

    上面的例子中，我使用了"事件"这个关键字。事件(消息)不是新鲜事物，在面向对象的系统中，其做为异构子系统、系统间异步调用的桥梁，起着重要的做用；因此我认为“事件通知”不是实现Domain的途径，由于它是同步调用的变种：消息的生产者和消费者仍然有业务逻辑上的自然联系。事件除了通知，还有一种模式是监听。这种事件是公共资源，是开放的标准，不论采用广播、总线、管道各类模式，Domain监听本身关注的事件，并对其进行响应，若是产生了新的（"开放"）事件，则将事件发布回(广播、总线、管道的)'通道'。以机场和飞机为例，机场广播的跑道天气信息，飞机的飞行员若是关心，则经过无线电接听，若是不关心，则彻底能够关闭无线电。

    以上基本展现了我思考的过程。其间，我回顾了本身使用过的各类(X)O，(X)O包含面向服务(架构)-SO(A)，面向方面(编程)-AO(P)，面向对象-OO，面向过程-PO。

粗略地获得了下图：

从上图中除了有关于Domain的思考，还想了关于如何更好的使用各类方法论。我有个观点：同步就是两次或者屡次异步交互的集成。

    画图的过程当中，我又有了个疑问：服务间的异步通知类接口，是不是实现Domain的一种形态？经过与分布式服务系统的拆分，我认为：异步通知(接口)是一种补充，而不是Domain间交互的主要方式，它相似“塔台呼叫711，711听到请回答”；若是全程都是这样飞行，塔台须要为每一个飞机配置一个导航员，且每一个飞机独立使用一个频率，这不是一个好设计，尽管它在航空管制初期多是可行的。

    个人结论是：面向领域设计DDD中的领域是比对象、服务更加高度的封装，领域包含本身的数据、行为、控制等"所有"，并对外部事件（或者消息）作出响应，按照本身的规则完成特定的功能。基于这样的特色，Domain间的通信应该是异步事件监听模式。在Domain内部，能够利用面向对象、服务及各类方法论开发更耦合的功能--这能够解释为何如今更多的系统是采用的同步调用方式运行。这也是另外一个层面的“外松内紧”的耦合。