最近一段时间在了解领域模型，之前拜读了下《领域驱动设计——软件核心复杂性应对之道》，结果看的云里雾里，晦涩的语句，不明所以的专业术语，加上翻译导致的语句流畅性，可以说观看体验并不是很好。然后同事推荐我先看《实现领域驱动设计》这本书，但是对于这种软件设计的书，稍微之前那本好点了。以前都是“talk is cheap, show me the code”，加上自己在这方面没啥经验积累，看的过程中，没啥共鸣。
接下来主要是自己在看的过程中的一些笔记和理解。
领域模型之贫血模型和充血模型
贫血模型：Model中，仅包含状态属性，不包含个行为，采用这种设计时，需要分离出DB曾，左门用语数据库操作。现在的web软件开发主要使用的就是贫血模式。
优点：系统层次结构清楚，各层之间单向依赖，缺点是不够面向对象
充血模型：Model中即包含状态，也包含行为，是最符合面向对象的设计方式。
优点面向对象，缺点比较复杂，对技术要求更高。
Spring data 的 Repository 是对充血模型的最佳实践
领域、子域和限界上下文
在DDD领域中，一个领域被分为若干个子域，领域模型在界限上下文中进行开发。
限界上下文是一个显示边界，灵越模型便存在边界之内。在边界内，通用语言中的所有术语和词组都有特定的含义，而模型需要准确的反映通用语言。
架构风格
在选择使用框架时，需要明确其使用目的：建立一种可以表达领域模型的实现并且用它来解决重要问题。
分层架构
分层架构主要是给复杂的应用程序划分诚实。在每一层内分别进行设计，使其具有内聚性并且只依赖于它的下层。这种架构模式类似于MVC框架。
- 用户界面层：负责向用户显示信息和解释用户指令。比如在MVC框架中，这一层主要指的是Controller层。
- 应用层：定义要完成的任务，并指挥表达领域概念的对象解决问题。对应MVC中service。
- 领域层：负责处理基本业务规则，比如事物回滚，业务逻辑等。
- 基础设施层：为上层提供通用的技术能力，个人理解这一层在MVC中指的是比如数据库操作等这些基础功能。
事件驱动架构
六边形架构
CQSR
CQRS 就是平常大家在 讲的读写分离，通常读写分离的目的是为了提高查询性能，同时达到读/写的解耦。让DDD和CQRS结合，我们可以分别对读和写建模，查询模型通常是一种非规范化数据模型，它并不反映领域行为，只是用于数据显示；命令模型执行领域行为，且在领域行为执行完成后，想办法通知到查询模型。
REST
RESTful风格的架构将‘资源’放在第一位，每个‘资源’都有一个URI与之对应，可以将‘资源’看着是ddd中的实体；RESTful采用具有自描述功能的消息实现无状态通信，提高系统的可用性；至于‘资源’的哪些属性可以公开出去，针对‘资源’的操作，RESTful使用HTTP协议的已有方法来实现：GET、PUT、POST和DELETE。
聚合
聚合就是指一组相关对象的集合，我们把它作为数据修改的单元。每个聚合都有一个聚合根(root)和一个边界(boundary)。边界定义了聚合内部有什么，而根则是一个特定的entity，两个聚合之间，只能通过根引用去向深入引用其他引用变量。
例子还是沿用电商系统中的订单和商品模块。在聚合模式中，订单不能够直接关联到商品的规格信息，如果一定要查询，则应该通过订单关联到的商品，由商品去访问商品规格。在这个例子中，订单和商品分别是两个边界，而订单模块中的订单entity和商品模块中的商品entity就是分别是各自模块的root。遵循这个原则，可以使我们模块关系不那么的盘根错节，这也是众多领域驱动文章中不断强调的划分限界上下文是第一要义。
资源库
严格来说，只有聚合才拥有资源库。
管理事务
对于事务的管理绝对不能放在领域模型和领域层中。通常来说，与领域模型相关的操作都是非常细粒度的，以致于无法用于事务管理。
一般来说，事务的管理应该放在应用层。
