领域驱动设计读书笔记

<p>[TOC]</p> <h2>第一章 消化知识</h2> <p>书中作者提到了他们开发一个 PCB 软件，但是开发人员对硬件知识知之甚少，PCB 专家对软件开发也一窍不通，前者可以算是开发人员、后者可以算是开发对象的领域专家，因此两方首先做的就是深入交流，PCB 专家试图向开发者阐述清楚各种元件和调用机制，开发者则在这个过程中不断完善自己的理解：</p> <p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/22c232a7659f01a0a7950ddf99c117af?showdoc=.jpg" alt="" /></p> <p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/4f67ead5e64a42fd8a5c22e81081826f?showdoc=.jpg" alt="" /></p> <p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/73ded0db91ee72e0352284f575d70776?showdoc=.jpg" alt="" /></p> <p>从上述的开发过程，作者总结了一下有效建模的因素：</p> <p>模型和实现的绑定，建立模型与实现的连接 建立了一种基于模型的语言，一开始PCB专家和软件开发者互相不了解对方的知识，但是在沟通过程中，双方逐渐可以使用项目中的术语开始互相理解 开发一个蕴含丰富知识的模型，模型需要包含各种领域知识，不仅仅是数据 提炼模型，重要概念不断加入模型，并且考虑是否需要分隔一些概念到新模型 头脑风暴和实验</p> <h2>第二章 交流与语言的使用</h2> <p>项目需要一种公共语言，在反复的沟通磨合下，领域模型可以成为这种通用语言的核心，同时将团队沟通与软件实现紧密联系到一起。有了通用语言之后，开发人员应该使用基于模型的语言来描述系统中的工件、任务和功能。这个模型应该为开发 人员和领域专家提供一种用于相互交流的语言。</p> <p><strong>文档和图</strong> 通常我们会在做架构设计时勾画 UML 图，主要是类图和交互图为主。但是，UML 图无法传达模型最重要的两个方面，<strong>一个方面是模型所表示的概念的意义，另一方面是对象应该做哪些事情</strong>。这时我们可以借助文档进行补充 —— 文档应作为代码和口头交流的补充。</p> <h2>领域驱动架构设计</h2> <h3>分层</h3> <p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/578e5ee3bf47d9d548b3f1f73a053293?showdoc=.jpg" alt="" /></p> <h3>依赖倒置原则</h3> <p>采用依赖倒置原则，使领域层和基础设施层都只依赖于由领域模型所定义的抽象接口 <img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/511727b2000ab6e8c278b4ac1bbc3df6?showdoc=.jpg" alt="" /></p> <h3>六边形架构</h3> <p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/00406a29ef425f387f562cebad15c18a?showdoc=.jpg" alt="" /></p> <h3>命令和查询职责分离——CQRS</h3> <p>将领域数据映射到界面显示中，就是 CQRS</p> <p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/d8c6db75989b9e0bb2a5a2496d301273?showdoc=.jpg" alt="" /></p> <p>事件驱动架构</p> <p><img src="https://www.showdoc.com.cn/server/api/attachment/visitfile/sign/fc230a566796af59464cf56e03f54a6d?showdoc=.jpg" alt="" /></p>