读《领域驱动设计精粹》

读这本书的背景

在日常项目管理中，会经常用到的一些方法，有效但是缺少方法论支撑，偶然间看到领域驱动开发系列丛书，从里面得到了很多方法论是日常实践过的，所以选择了一本入门级短篇，先了解，再根据reference深入学习。

阅读感想

1. 在奢侈品电商这个行业中，业务模型复杂度远大于技术模型复杂度。“以业务为中心”的模型设计应该占据主导，“以技术为中心”的设计理念要缩减影响范围。DDD的思维模型刚好适配这个行业的模型设计。DDD入门选这本开始就对了～

2. 领域要建立“通用语言”，找到“核心域”，用“上下文”划分边界严格筛选进入通用语言的内容。

3. 通用语言是一种领域内团队协作的心智模型，能大幅度提升领域内各团队的沟通效率.

4. 维护领域模型重叠区域是效率较高的一种模式，但是要看对方的业务领域是否会演变成一个大泥球领域？如果会，那么最好提早建立防腐层来做跨领域沟通。

5. 业务领域链接的几种方式：共享内核、客户-供应商、跟随者、防腐层、开放服务、已发布语言、各行其道、大泥球。

6. 前半部分讲透了，学到了不少东西，比如要创建通用语言，通用语言能够提效沟通和协作。 但是后半部分有点读不懂了，实战应用和读者之间感觉少了一层内容，导致理解不透。

7. 如果满分5颗星，评分给到3颗星，总体来讲，值得一读。

阅读摘录

1. 关于设计是否必要或是否负担得起的问题根本都没有问到点上：设计是不可或缺的。除了优秀设计就是糟糕设计，根本不存在“不做设计”一说。

2. 一个团队应该在一个限界上下文中工作。每个限界上下文应该拥有一个独立的源代码仓库。一个团队可能工作在多个限界上下文中，但是多个团队不应该在同一个限界上下文中共事。我们应该采用和分离通用语言同样的方式，干净地把不同限界上下文的源代码和数据库模式隔离开。并且，将同一个限界上下文中的验收测试、单元测试和主要源代码存放在一起。 尤其重要的是，要明确一个团队只在单一的限界上下文中工作。别给其他团队留下任何机会去修改你的源代码，从而引发意外。你的团队控制着源代码和数据库并定义了官方接口，必须通过这些接口才可以调用限界上下文。这是使用DDD所能带来的好处之一。

3. 我们甚至可以绘制一些简单的图画和图表。这些方式都是为了帮助团队进行良好的沟通。这里适当地提醒一句，当心你在建模工作中对文字场景、图画、图表这些文档长期保持同步花费过长的时间。这些文档并不是领域模型。相反，它们只是帮助你开发领域模型的工具。模型终将与代码融为一体。

4. 大泥球已经遍布于世界上的软件系统中，这个数量还铁定会逐月增长。即使可以通过采用DDD技术避免创建自己的大泥球，仍可能不得不与它们集成。如果必须与一个或多个这样的大泥球系统集成，请尝试针对每个这样的遗留系统创建一个防腐层，保护自己的模型免受污染，否则会陷入难以理解的泥潭。不管怎样，别“讲”这种语言！

5. 当C1向S1发起同步阻塞请求并等待其返回作为处理结果来响应C0的请求时，它们三者之间就形成了暂时性耦合。C0的请求是否能成功，返回的是快是慢，取决于S1和C1以及它们之间的连接（通常是网络连接）。一旦S1发生问题，C1和C0就会像相邻的火车车厢一样受到牵连。更糟的是，C0和C1还可能因为阻塞影响可用性。而使用异步消息机制之后，C0和C1首先从设计上就要考虑消息延迟和网络故障导致的失败，自身的健壮性更强。当它们触发命令（发布一条消息）之后，三者之间再无瓜葛， S1的失败影响范围就能降到最小。

6. 因为消息机制总是采用异步的请求响应[Reactive]通信方式，所以有一些延迟是正常的，也是可以预见的。服务请求应该（几乎）不会阻塞，直到服务完成。因此，设计时把消息机制放在心上意味着你至少需要时刻准备着处理一些延迟，这将使你的整体解决方案从一开始就更加健壮。