最近在换工作，利用间隙看了两本领域驱动设计的经典书籍：《领域驱动设计：软件核心复杂性应对之道》，《实现领域驱动设计》。

领域设计中的元素

限界上下文

• 限界上下文是一个显式的边界，领域模型便存在于这个边界之内。
• 通俗来讲上下文可以认为是一个能够独立运转的模块。同一种概念在不同上下文中可能具有不同的意义。
• 不同上下文之间可以用RPC/REST接口访问（使用防腐层确保上下文数据安全），或领域事件进行通信（可以实现上下文更高的自治性）。`
• 例：采购上下文，库存上下文。

实体

• 实体是一个唯一的东西，并且可以在相当长的一段时间内持续地变化，拥有唯一的身份标识。
• 实体不应该是贫血的，实体拥有业务逻辑。
• Hibernate框架可以实现实体-数据映射。

值对象

• 值对象是一个不变的数字，字符串或一种用来描述的对象。
• 值对象类似DTO的概念。

领域服务

• 领域中的服务表示一个无状态的操作，它用于实现特定于某个领域的任务。
• 当某个操作不适合放在聚合和值对象上时，最好的方式便是使用领域服务了。
• 过度使用领域服务可能会造成贫血模型。

领域事件

• 用来捕获发生在领域中的一些事情。
• 可以用于向远程限界上下文发布领域事件。
• 消息的一致性实现，消息时延问题。
• 消息中间件（RabbitMQ）

聚合

• 将实体和值对象在一致性边界之内组成聚合。
• 设计小聚合。通过唯一标识引用其他聚合，避免大对象给JVM造成负担。
• 原则上一次事务只操作一个聚合，这样服务会有更好的伸缩性和分布式特性。
• 在一个事务中操作大聚合对象，高并发时容易造成失败。

工厂

• 用来创建模型对象，对客户端隐藏创建的细节。

资源库

• 资源库表示一个安全的存储区域，并且对其中所存放的物品起保护作用。
• 存在一些额外的行为，如统计数量。

应用服务

• 用户界面使用应用服务来协调用例任务，管理事务，并执行一些必要的安全授权。

心得体会

• 当应用程序业务逻辑越来越复杂的时候，使用面向数据开发方式会越来越吃力。无限多的条件判断来控制不同的业务逻辑，修改一个功能也不知道会引起其他业务逻辑上的问题。
• 我在项目的中期尝试引入DDD，靠自己对面向对象的理解和一些网上文章的经验，还是收到了一些不错的效果：使得业务设计层面与实现层面能够分离，让应用程序有更好的可扩展性，避免业务逻辑之间有过多的牵扯。
• 如今微服务概念流行，按DDD的方式划分出限界上下文与领域事件，正好可以让业务设计上天生支持微服务架构。必要时再引入CQRS方案解决跨上下文查询的问题。
• DDD虽好也不是银弹。软件设计是一种玄学，无法简单的判断对错，很多时候需要具体场景具体分析，达到业务抽象与性能的平衡。