来源：https://www.jianshu.com/p/a775836c7e25
一个微服务最大不要超过一个BC，否则微服务内会存在有歧义的领域概念。
分层架构
分层架构的一个重要原则是每层只能与位于其下方的层发生耦合。分层架构可以简单分为两种，即严格分层架构和松散分层架构。在 严格分层架构中，某层只能与位于其直接下方的层发生耦合，而在 松散分层架构 中，则允许某层与它的任意下方层发生耦合。
分层架构的好处是显而易见的。首先，由于层间松散的耦合关系，使得我们可以专注于本层的设计，而不必关心其他层的设计，也不必担心自己的设计会影响其它层，对提高软件质量大有裨益。其次，分层架构使得程序结构清晰，升级和维护都变得十分容易，更改某层的具体实现代码，只要本层的接口保持稳定，其他层可以不必修改。即使本层的接口发生变化，也只影响相邻的上层，修改工作量小且错误可以控制，不会带来意外的风险。
要保持程序分层架构的优点，就必须坚持层间的松散耦合关系。设计程序时，应先划分出可能的层次，以及此层次提供的接口和需要的接口。设计某层时，应尽量保持层间的隔离，仅使用下层提供的接口。关于分层架构的优点，Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案：
“金无足赤，人无完人”，分层架构也不可避免具有一些缺陷：
在每个BC中为了凸显领域模型，DDD中提出了分层架构模式。最近几年，笔者在实践DDD的过程中，也经常使用分层架构模式，本文主要分享DDD分层架构中比较经典的三种模式。
模式一：四层架构
Eric Evans在《领域驱动设计－软件核心复杂性应对之道》这本书中提出了传统的四层架构模式，如下图所示：
笔者在四层架构模式的实践中，对于分层的本地化定义主要为：
说明：严格意义上来说，User Interface指的是用户界面，Restful消息和配置文件解析等处理应该放在Application层，User Interface层没有的话就空缺。但User Interface也可以理解为用户接口，所以将Restful消息和配置文件解析等处理放在User Interface层也行。
模式二：五层架构
James O. Coplien和Trygve Reenskaug在2009年发表了一篇论文《DCI架构：面向对象编程的新构想》，标志着DCI架构模式的诞生。有趣的是James O.Coplien也是MVC架构模式的创造者，这个大叔一辈子就干了两件事，即年轻时创造了MVC和年老时创造了DCI，其他时间都在思考，让我辈望尘莫及。
面向对象编程的本意是将程序员与用户的视角统一于计算机代码之中：对提高可用性和降低程序的理解难度来说，都是一种恩赐。可是虽然对象很好地反映了结构，但在反映系统的动作方面却失败了，DCI的构想是期望反映出最终用户的认知模型中的角色以及角色之间的交互。传统上，面向对象编程语言拿不出办法去捕捉对象之间的协作，反映不了协作中往来的算法。就像对象的实例反映出领域结构一样，对象的协作与交互同样是有结构的。协作与交互也是最终用户心智模型的组成部分，但你在代码中找不到一个内聚的表现形式去代表它们。在本质上，角色体现的是一般化的、抽象的算法。角色没有血肉，并不能做实际的事情，归根结底工作还是落在对象的头上，而对象本身还担负着体现领域模型的责任。
人们心目中对“对象”这个统一的整体却有两种不同的模型，即“系统是什么”和“系统做什么”，这就是DCI要解决的根本问题。用户认知一个个对象和它们所代表的领域，而每个对象还必须按照用户心目中的交互模型去实现一些行为，通过它在用例中所扮演的角色与其他对象联结在一起。正因为最终用户能把两种视角合为一体，类的对象除了支持所属类的成员函数，还可以执行所扮演角色的成员函数，就好像那些函数属于对象本身一样。换句话说，我们希望把角色的逻辑注入到对象，让这些逻辑成为对象的一部分，而其地位却丝毫不弱于对象初始化时从类所得到的方法。我们在编译时就为对象安排好了扮演角色时可能需要的所有逻辑。如果我们再聪明一点，在运行时才知道了被分配的角色，然后注入刚好要用到的逻辑，也是可以做到的。
算法及角色-对象映射由Context拥有。Context“知道”在当前用例中应该找哪个对象去充当实际的演员，然后负责把对象“cast”成场景中的相应角色（cast这个词在戏剧界是选角的意思，此处的用词至少符合该词义，另一方面的用意是联想到cast 在某些编程语言类型系统中的含义）。在典型的实现里，每个用例都有其对应的一个Context 对象，而用例涉及到的每个角色在对应的Context 里也都有一个标识符。Context 要做的只是将角色标识符与正确的对象绑定到一起。然后我们只要触发Context里的“开场”角色，代码就会运行下去。
于是我们有了完整的DCI架构（Data、Context和Interactive三层架构）：
关于多角色对象，举个生活中的例子:
引入DCI后，DDD四层架构模式中的Domain层变薄了，以前Domain层对应DCI中的三层，而现在：
笔者在实践中，将这五层的本地化定义为：
DDD五层架构模式讨论完了吗？故事还没有结束…
笔者参与的很多DDD落地实践，都是面向控制面或管理面且消息交互比较多的系统。这类系统的一次业务，包含一组同步消息或异步消息构成的序列，如果都放在Context层，会导致该层的代码比较复杂，于是我们考虑：
因此，在面向控制面或管理面且消息交互比较多的系统中，DDD分层架构模式就变成了六层，如下图所示：
笔者在实践中，将这六层的本地化定义为：
事务层的核心是事务模型，事务模型的框架代码一般放在基础设施层。关于事务模型，笔者以前分享过一篇文章— 《Golang事务模型》 ，感兴趣的同学可以看看。
综上所述，DDD六层架构可以看做是DDD五层架构在特定领域的变体，我们统称为DDD五层架构，而DDD五层架构与传统的四层架构类似，都是 限定型松散分层架构 。
模式三：六边形架构
有一种方法可以改进分层架构，即依赖倒置原则(Dependency Inversion Principle,DIP)，它通过改变不同层之间的依赖关系达到改进目的。
根据该定义，DDD分层架构中的低层组件应该依赖于高层组件提供的接口，即无论高层还是低层都依赖于抽象，整个分层架构好像被推平了。如果我们把分层架构推平，再向其中加入一些对称性，就会出现一种具有对称性特征的架构风格，即六边形架构。六边形架构是Alistair Cockburn在2005年提出的，在这种架构中，不同的客户通过“平等”的方式与系统交互。需要新的客户吗？不是问题。只需要添加一个新的适配器将客户输入转化成能被系统API所理解的参数就行。同时，对于每种特定的输出，都有一个新建的适配器负责完成相应的转化功能。
六边形架构也称为端口与适配器，如下图所示：
六边形每条不同的边代表了不同类型的端口，端口要么处理输入，要么处理输出。对于每种外界类型，都有一个适配器与之对应，外界通过应用层API与内部进行交互。上图中有3个客户请求均抵达相同的输入端口（适配器A、B和C），另一个客户请求使用了适配器D。假设前3个请求使用了HTTP协议（浏览器、REST和SOAP等），而后一个请求使用了AMQP协议（比如RabbitMQ）。端口并没有明确的定义，它是一个非常灵活的概念。无论采用哪种方式对端口进行划分，当客户请求到达时，都应该有相应的适配器对输入进行转化，然后端口将调用应用程序的某个操作或者向应用程序发送一个事件，控制权由此交给内部区域。
应用程序通过公共API接收客户请求，使用领域模型来处理请求。我们可以将DDD战术设计的建模元素Repository的实现看作是持久化适配器，该适配器用于访问先前存储的聚合实例或者保存新的聚合实例。正如图中的适配器E、F和G所展示的，我们可以通过不同的方式实现资源库，比如关系型数据库、基于文档的存储、分布式缓存或内存存储等。如果应用程序向外界发送领域事件消息，我们将使用适配器H进行处理。该适配器处理消息输出，而上面提到的处理AMQP消息的适配器则是处理消息输入的，因此应该使用不同的端口。我们在实际的项目开发中，不同层的组件可以同时开发。当一个组件的功能明确后，就可以立即启动开发。由于该组件的用户有多个，并且这些用户的侧重点不同，所以需要提供多个不同的接口。同时，这些用户的认识也是不断深入的，可能会多次重构相关的接口。于是，组件的多个用户经常会找组件的开发者讨论这些问题，无形中降低了组件的开发效率。
我们换一种方式，组件的开发者在明确了组件的功能后就专注于功能的开发，确保功能稳定和高效。组件的用户自己定义组件的接口（端口），然后基于接口写测试，并不断演进接口。在跨层集成测试时，由组件开发者或用户再开发一个适配器就可以了。
六边形架构模式的演变
尽管六边形架构模式已经很好，但是没有最好只有更好，演变没有尽头。在六边形架构模式提出后的这些年，又依次衍生出三种六边形架构模式的变体，感兴趣的读者可以点击链接自行学习：
小结
本文先和读者一起回顾了DDD和分层架构的相关知识，然后将DDD分层架构中常用的三种模式（四层架构、五层架构和六边形架构）结合实践经验分别进行详细阐述，使得读者深刻理解DDD分层架构模式，以便在微服务的开发实践中根据具体情况选择最合适的DDD分层架构模式，从而交付结构清晰且易维护的软件产品。
如果此文对你有所帮助，希望能随手点个转发！
本文分享自微信公众号 - JAVA日知录（javadaily）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。