以前看过一些名字叫 "精粹" 的书籍，一般都是进阶级别的，但这本书不同，这本书依然是入门级别的，而且是具备很强的操作指导性书籍。领域驱动设计的好书还有几本，不过都篇幅较长，概念很多（大量新概念，学习曲线很陡峭），本书则精选了最重要的概念，且篇幅短小精悍。这对于初学者来说非常适合。强烈推荐初学者从此书入手，然后尝试，然后再回来阅读，这个时候就可以啃一啃其他几本书作为补充阅读了。

领域驱动设计精粹，这本书的可读性太差。领域名词、模型抽象、实践经验，要么语句不通，要么抽象不足、无法拿来即用。无论如何，还是有一些启发的概念或观点。如下：- 战略先行：先战略后战术，无战略不设计。战略设计工具包括 限界上下文、通用语言、子域、上下文映射。- 战术设计：战术设计工具包括 聚合、领域事件。- 限界上下文：通过限界上下文，能够明确什么是核心。DDD 以业务为核心，战略层与技术无关。- 子域：核心、支撑、通用。- 上下文映射：。- 聚合：将若干实体和值对象以恰当的大小聚集在一起。包括聚合根、实体 / 值对象。- 领域事件：。- 事件风暴：领域专家，场景、故事、用例，命令、事件、实体 / 聚合的关联；发现边界。其它观点，如下：-— 设计先行：先设计后开发，无设计不开发。设计是否有必要、这个问题根本没问到点上，设计是不可或缺的；除了优秀设计就是糟糕设计，根本不存在 "不做设计" 一说。前期不周详设计、后期运营成本高，这种情况在 CRUD 工程师身上尤其明显。如果担心周详的设计会带来高昂的软件开发成本，那么设想一下，将来为了维护甚至修缮一套糟糕设计的软件就需要付出更为昂贵的代价。组织限界：限界上下文不应该跨团队共享，每个限界上下文都应该有独立的源代库、数据库设计，其他团队必须通过接口调用来修改限界上下文。领域划分：领域模型本身与技术无关。这也是为什么事务是由应用服务管理，而不是由领域模型来管理的原因。子域划分：多用形象举例。不要将核心域局限在名词上、相反应当使用一组具体场景来表达核心域，这些场景描述了领域模型应该做的事情。聚合原则：聚合设计的一条普遍规则是，只能在一次事务中修改一个聚合实例并提交；业务规则是最终驱动，它决定了哪些对象在事务提交中是完整、完全和一致的。贫血模型：不要贫血模型。贫血指的是，领域模型缺少必要的业务逻辑，如把业务逻辑放到上应用服务中、领域类只有 getter、setter 方法。过度抽象：不要过度抽象。要根据领域专家的心智模型，脚踏实地地对通用语言进行建模、实现当下的业务需求。领域事件：命名，领域事件是对已发生事件的陈述，命名应该使用动词的过去式，如 ProductCreated 表示在过去的某个时间 Product 被创建了。属性，增加额外属性、可以方便消费者通过领域事件获取更多信息，避免了不必的限界上下文查询；但也要避免把太多数据塞给领域事件，凡事过犹不及。事件风暴：把命令、事件通过实体 / 聚合关联起来，命令在实体 / 聚合上执行、并产生领域事件的结果；在 IT 设计中，绘制 E-R 图通常是最流行的第一步、大错特错，因为业务人员更关注业务流程、而非数据，E-R 图在事件风暴中只能排到第三步。

前面还好，后面感觉翻译质量越来越差，直到不知所云当然，或许跟我理解能力也有关系