最近一鼓作气买了两本久负盛名的书《领域驱动设计 软件核心复杂性应对之道 》和《实现领域驱动设计》。开卷有益，在学习的途中，做些笔记巩固下，并记录下感想。先来说下《实现领域驱动设计》，大致翻了翻，本书并不是《算法导论》那种很高端难懂的类型，是属于思考实践总结类型的。我相信，一章一章看下去，会有很多收获的。本篇文章是个开篇说明，并不深究具体细节，讲述如何使用《实现领域驱动设计》。
DDD总览
DDD的通用语言(Ubiquitous Language)作用于某个限界上下文（Bounded Context），它对于领域建模是非常重要的。
战略建模
限界上下文是一种概念上的边界，领域模型方便工作于其中。同时，限界上下文为通用语言提供了一套环境，项目成员通过通用语言来表达软件模型，如流程图：
架构
战术建模
站术设计的一个重要模式是聚合（Aggregate）,聚合可以由单个实体（Entity)组成，也可以由一组实体和值对象（Value Object）组成，此时我们必须在聚合的整个生命周期保证事务上的一致性。
聚合实例通过资源库（Repository）进行持久化，另外对聚合的查找和获取也通过资源库完成。如图，两个聚合类型，它们拥有各自的事务一致性的边界。
在领域模型中，有些业务操作并不能自然的放在实体或值对象上，此时我们可以使用无状态的领域服务（Domain Service),领域服务执行特定与领域的操作，其中可能涉及多个领域对象
领域事件（Domain Event）表示领域模型中发生的重要事件。有多种方式可以对领域事件进行建模。在对聚合进行命令操作时，聚合本身将发布领域事件。
我们通常忽略了模块（Module),但是正确的设计模块同样重要，模块内包含的领域对象应该是内聚在一起的。
以上内容主要提到了通用语言，限界上下文，上下文映射图，聚合，实体，资源库，值对象，领域服务，领域事件，模块等概念。
书上总结内容完毕。
DDD不是无中生有，自动产生的。它来源于业务专家或软件开发师在沟通提炼业务的基础上归纳概括而来。所以在看书的过程中，会产生这个例子我见过，我用了相同的方法实现，感同身受的感受。也许当时你只是把问题解决了，并没有引起你多大的深思。但有些人，有些思想家遇到了很多的例子，成功或失败的例子，他们思考总结，写的多了，最后成了一本书。嘭的一声巨响，一个领域专家诞生了！
本篇完毕，谢谢观看。