读书笔记：《实现领域驱动设计》

前言：有赞scrm的复杂度越来越高，作为业务中台，为了给业务方爸爸们提供更好更快的底层能力支持，开始走向了平台化。之前听从部门架构师的建议，没有一定的业务积累，不要学习DDD相关的内容，当时只是很零碎的看了一些领域建模的文章。这次正好有幸作为第一批参与平台化建设的人，斗胆系统性的开始学习领域建模。

书中其实也在权衡技术细节与DDD的实现，有非常多的取舍的地方，所以完美的DDD实现在现有技术组件下几乎是不存在的。这反而有种为了实现DDD而实现DDD的感觉，而关于DDD到底能带给我们什么，由于我没有实际DDD的经验，所以我并不能很真实的感觉到。

 

第1章：DDD入门

1、将领域专家引入到团队

领域专家并不是一个职位，他可以是精通业务的任何人。他们可能了解更多的关于业务领域的背景知识，他们可能是软件产品的设计者，甚至有可能是销售员。

在实施DDD的过程中，最好将那些不怎么使用技术语言的人加进自己的团队。就像你会向他们学习一样，他们也会向你学习。

2、什么是领域模型

领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。

3、为什么我们需要DDD

• 使领域专家和开发者在一起工作，这样开发出来的软件能够准确的传达业务规则。当然，对于领域专家和开发者来说，这并不表示单单的包容对方，而是将他们组成一个密切协作的团队。
• “准确传达业务规则”的意思是说，此时的软件就像如果领域专家是编码人员时所开发出来的一样。
• 可以帮助业务人员自我提高。没有任何一个领域专家或者管理者敢说他对业务已经了如指掌，业务知识也需要一个长期的学习过程。在DDD中，每个人都在学习，同时每个人又是知识的贡献者。
• 关键在于对知识的集中，因为这样可以确保软件知识并不只是掌握在少数人手中。
• 在领域专家、开发者和软件本身之间不存在“翻译”，意思是当大家都使用相同的语言进行交流时，每人都能听懂他人所说。
• 设计就是代码，代码就是设计。设计是关于软件如何工作的，最好的编码设计来自于多次试验，这得益于敏捷的发现过程。
• DDD同时提供了战略设计和战术设计两种方式。战略设计帮助我们理解哪些投入是最重要的；哪些既有软件资产是可以重新拿来使用的；哪些人应该被加到团队中？战术设计则帮助我们创建DDD模型中各个部件。

4、难以捉摸的业务价值：P6

5、DDD如何帮助我们：P7

6、处理领域复杂性：P8

4、什么样的软件系统值得做出DDD投入

应该将DDD应用在最重要是业务场景下，值得投入的是那些最重要的、复杂的东西，因为这些东西将带来可观的回报。DDD的作用是简化，而不是复杂化。在使用DDD时，我们应该采用最简单的方式对复杂领域进行建模，而不是使问题变得更加复杂。

5、如何评价业务领域的复杂性

可参考书中的DDD计分卡。（P8）

6、什么是通用语言

通用语言是团队共享的语言。领域专家和开发者使用相同的通用语言进行交流。事实上，团队中每个人都使用相同的通用语言。不管你再团队中的角色如何，只要你是团队的一员，都将使用通用语言。团队成员通过讨论、参考资料、引用标准、查阅字典等对通用语言进行改进。有时我们发现，有些我们曾经认为能很好表达业务的词汇不再适用了，而另外的一些词汇具有更好的效果。

7、使用通用语言的几点注意事项

• 这里的“通用”意思是“普遍的”，或者“到处都存在的”。通用语言在团队范围内使用，并且只表达一个单一的领域模型。
• “通用语言”并不表示全企业、全公司或者全球性的万能的领域语言。
• 限界上下文和通用语言间存在一对一的关系。在一个限界上下文中使用其专属的通用语言，对于那些不包含在通用语言中的概念，应该拒绝使用。
• 限界上下文是一个相对较小的概念，通常比我们起初想象的要小。限界上下文刚好能够容纳下一个独立的业务领域所使用的通用语言。
• 只有当团队工作在一个独立的限界上下文中时，通用语言才是“通用”的，
• 虽然我们只工作在一个限界上下文中，但是通常我们还需要和其他限界上下文打交道，这时可以通过上下文映射图对这些限界上下文进行集成。每个限界上下文都有自己的通用语言，而有时语言间的术语可能有重叠的地方。
• 如果你试图将某个通用语言运用在整个企业范围之内，或者更大、跨企业的范围内，你将失败。

8、DDD的业务价值

• 获得了一个非常有用的领域模型
• 业务得到了更准确的定义和理解
• 领域专家可以为软件设计做出贡献
• 更好的用户体验
• 清晰的模型边界
• 更好的企业架构
• 敏捷、迭代式和持续建模
• 使用战略和战术新工具

9、实施DDD所面临的挑战

• 为创建通用语言腾出时间和精力
• 持续的将领域专家引入项目
• 改变开发者对领域的思考方式
• （自己额外增加的）现有技术生态多是为贫血模型和设计的，要在这样的情况下实现DDD，是有难度的。

10、如何选择开发方式

• 团队是否有领域专家，如果有，你如何围绕领域专家组织自己的团队？
• 虽然目前来说，你的业务领域是简单的，但它将来会变得复杂吗？对于复杂的系统来说，使用事务脚本是存在风险的。当领域变得复杂时，是否有可能将系统重构到富含行为的领域模型？
• DDD的战术模式是否可用简化与其他限界上下文的集成，不管是第三方的还是定制开发的？
• 使用事务脚本是否的确可用减少代码量？（经营表明，不管对于哪种开发方式，事务脚本都不能减少代码量。这可能是由于在项目计划阶段，领域复杂性并没有得到正确的认识所致。因此，我们需要在领域复杂性上下足功夫。）
• 你项目的进度安排是否允许在战术建模上有所投入？
• 你核心域上的战术投入能否消除架构变化所带来的影响？事务脚本是做不到这一点的（和领域模型层相比，其他层更容易受到架构变化的影响）
• 客户是否的确能从这种持续设计和开发的方式中获益，或者有现成的产品能满足他们的需求？换句话说，我们是否应该一开始就考虑定制化开发？你最终取悦你的客户，而不是技术开发者，所以得慎重的做成选择。
• 使用DDD的战术开发模式会比其他开发方式更加困难吗，比如事物脚本？（这个问题很大程度上取决于团队成员的技能水平和是否有领域专家）
• 如果团队已经具备了实施DDD的条件，我们还会可以的选择另一种开发方式吗？有些开发者已经将模型的持久化变得很实用了，比如使用ORM、全聚合序列化和持久化、事件存储（Event Store）、或者战术DDD框架等。但是我们也不能排除还有热衷于其他开发方式的开发者。

 

第2章：领域、子域和限界上下文

1、什么是领域

从广义上讲，领域即是一个组织所做的事情以及其中所包含的一切。商业机构通常会确定一个市场领域模型，然后在这个市场中销售产品和服务。每个组织都有它自己的业务范围和做事方式。这个业务范围以及其中所进行的活动便是领域。当你为某个组织开发软件时，你面对的便是这个组织的领域。这个领域对于你来说应该是明晰的，因为你在这个领域中工作。

2、核心域、支撑子域、通用子域

3、问题空间

问题空间是领域的一部分，对问题空间的开发将产生一个新的核心域。对问题空间的评估应该同时考虑已有子域和额外所需子域。因此，问题空间是核心域和其他子域的组合。问题空间中的子域通常随着项目的不同而不同，他们各自关注于当前的业务问题，这使得子域对于问题空间的评估非常有用。子域允许我们快速的浏览领域中的各个方面，这些方面对于解决特定的问题是必要的。

4、解决方案空间

解决方案空间包括一个或多个限界上下文，即一组特定的软件模型。这是因为限界上下文即是一个特定的解决方案，它通过软件的方式来实现解决方案。

5、实施解决方案之前，需要对问题空间和解决方案空间进行评估