这是这本书的第一部分的最后一章，过去的章节其实主要围绕了DDD设计模式对复杂领域的一些解决方法，得知了很多概念，以及他们的含义和关联关系，比如子域、上下文映射、通用语言、领域模型、DDD分层架构等等，总的来说我了解了一些，但是感觉还是没有学到有用的太多有用的东西，只是在工作中有过相似经历的会知道偶尔原来说的这么回事，后面的两大部分是会分别详细介绍战略设计和战术设计，可能结合案例和代码估计会更好理解吧，后面会继续记录。
1.推广使用DDD
使用前提
-
热衷学习的、有技术、充满热情的团队。
-
对业务很重要的不简单的问题域
-
有与项目愿景保持一致的领域专家的参与。
-
遵循迭代式开发
1.1 培训团队
专注业务保持一致，专注领域上下文、描述模型的语言，与领域专家协作，专注不受混乱基础架构和技术问题
影响的抽象概念模型。
1.2 与业务人员交流
业务人员不希望听到新一代的开发思想体系或者方法论，只关心交付价值，可以和他们讨论DDD，单要专注协作需要上。
2.应用DDD的原则
2.1理解业务愿景
与业务人员会谈期间，带着问题去思考问题业务愿景，捕获产品的特性。
-
产品的业务目标、驱动因素是什么？
-
产品会为业务代理什么？
-
如何才能知道取得了成功？好的一面看起来什么样？
-
这样做和之前的做法有什么不同？
2.2捕获所需的行为
2.2.1 提炼问题空间
问题空间复杂难以管理，可创建子域并借助将问题抽象到更高的层级环节日志负荷。
2.2.2 专注重要方面
专注核心域
2.3 理解环境的现实情况
识别出直接影响产品或者被产品影响的起作用的不同有界上下文。
重复如下步骤
-
确定影响问题域的模型，绘制上下文并命名，说明负责人。不知从何处开始，可以参考团队组织结构。
-
映射集成点以及集成方法。
-
映射要交换的数据以及谁拥有这些数据。
-
标记上下文映射关系。
-
重复上述步骤，直到捕获与你开发的环境有关的内容。
2.3 对解决方案建模
在值得使用DDD问题上、多于专家进行交流、选择行为并围绕具体场景建模，演化UL以及移除歧义，
并不断尝试设计模型，并在代码实现，有必要的情况下进行代码重构。
image-20220807015059034.png
网友评论