领域驱动设计实现之路

　　怎样解决？谜底是：限界上下文和上下文映射图。

　　限界上下文（Bounded Context）

　　在一个领域/子域中，我们会建立一个观点上的领域界限，在这个界限中，任何领域工具都只表现特定于该界限内部简直切寄义。这样界限便称为限界上下文。限界上下文和领域具有一对一的关系。

　　举个例子，同样是一本书，在出书阶段和出售阶段所表达的观点是差别的，出书阶段我们主要关注的是出书日期，字数，出书社和印刷厂等观点，而在出售阶段我们则主要体贴价钱，物流和发票等观点。我们应该怎么办呢，将所有这些观点放在单个Book工具中吗？这不是DDD的做法，DDD有限界上下文将这两个差别的观点区离开来。

　　从物理上讲，一个限界上下文最终可以是一个DLL(.NET)文件或者JAR(Java)文件，甚至可以是一个命名空间（好比Java的package）中的所有工具。可是，手艺自己并不应该用来界分限界上下文。

　　将一个限界上下文中的所有观点，包罗名词、动词和形容词所有集中在一起，我们便为该限界上下文建立了一套通用语言。通用语言是一个团队所有成员交流时所使用的语言，营业剖析职员、编码职员和测试职员都应该直接通过通用语言举行交流。

　　对于上文中提到的各个子域之间的集成问题，实在也是限界上下文之间的集成问题。在集成时，我们主要体贴的是领域模子和集成手段之间的关系。好比需要与一个REST资源集成，你需要提供基础设施（好比Spring 中的RestTemplate），可是这些设施并不是你焦点领域模子的一部门，你应该怎么办呢？谜底是防腐层，该层卖力与外部服务提供方打交道，还卖力将外部观点翻译成自己的焦点领域能够明白的观点。固然，防腐层只是限界上下文之间众多集成方式的一种，另外另有共享内核、开放主机服务等，详细细节请参考《实现领域驱动设计》原书。限界上下文之间的集成关系也可以明白为是领域观点在差别上下文之间的映射关系，因此，限界上下文之间的集成也称为上下文映射图。

　　架构气势派头（Architecture）

　　DDD并不要求接纳特定的架构气势派头，由于它是对架构中立的。你可以接纳传统的三层式架构，也可以接纳REST架构和事务驱动架构等。可是在《实现领域驱动设计》中，作者比力推许事务驱动架构和六边形（Hexagonal）架构。

　　当下，面向接口编程和依赖注入原则已经在倾覆着传统的分层架构，若是再进一步，我们便获得了六边形架构，也称为端口和适配器（Ports and Adapters）。在六边形架构中，已经不存在分层的观点，所有组件都是同等的。这主要得益于软件抽象的利益，即各个组件的之间的交互完全通过接口完成，而不是详细的实现细节。正如Robert C. Martin所说：

　　抽象不应该依赖于细节，细节应该依赖于抽象。

　　接纳六边形架构的系统中存在着许多端口和适配器的组合。端口表现的是一个软件系统的输入和输出，而适配器则是对每一个端口的会见方式。好比，在一个Web应用程序中，HTTP协议可以作为一个端口，它向用户提供HTML页面而且接受用户的表单提交；而Servlet（对于Java而言）或者Spring中的Controller则是相对应于HTTP协议的适配器。再好比，要对数据举行持久化，此时的数据库系统则可看成是一个端口，而会见数据库的Driver则是响应于数据库的适配器。若是要为系统增添新的会见方式，你只需要为该会见方式添加一个响应的端口和适配器即可。

　　那么，我们的领域模子又怎样与端口和适配器举行交互呢？

　　上文已经提到，软件系统的真正价值在于提供营业功效，我们会将所有的营业功效剖析为若干个营业用例，每一次营业用例都表现对软件系统的一次原子操作。以是首先，软件系统中应该存在这样的组件，他们的作用即以营业用例为单元向外界袒露该系统的营业功效。在DDD中，这样的组件称为应用层（Application Layer）。

　　在有了应用层之后，软件系统和外界的交互便酿成了适配器和应用层之间的交互，如图-1所示。

图-1 六边形架构

　　从图-1中可以看出，领域模子位于应用程序的焦点部门，外界与领域模子的交互都通过应用层完成，应用层是领域模子的直接客户。然而，应用层中不应该包罗有营业逻辑，否则就造成了领域逻辑的走漏，而应该是很薄的一层，主要起到协调的作用，它所做的只是将营业操作署理给我们的领域模子。同时，若是我们的营业操作有事务需求，那么对于事务的治理应该放在应用层上，由于事务也是以营业用例为单元的。

 2/5   首页 上一页 1 2 3 4 5 下一页 尾页