第一章 DDD 入门
什么是领域模型? 领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。
- 领域专家将关注点放在交付业务价值上，而开发者则将注意力放在技术实现上；
- DDD关注的三个方面：
- 领域专家和开发人员一起创建一套适用于领域建模的通用语言；
- DDD关注业务战略；
- 通过使用战术设计建模工具；
第二章 领域，子域和界限上下文
领域
- 从广义上讲，领域即是一个组织所做的事情，及其所包含的一切；
- 每个组织都有他自己的业务范围和做事方式，这个业务范围以及在其中所进行的活动便是领域；
为什么要划分子域
如果不通过子域对软件模型进行划分，事情将变的更加繁琐，因为系统中的各个部分都是紧密联系在一起的，用DDD将交织的模型划分成逻辑上相互分离的子域，在一定程度上减少系统的复杂性；
界限上下文
界限上下文是一个显式的边界，领域模型便存在于边界之内，在边界内，通用语言中的所有术语和词组都有特定的含义，而模型需要准确的反映通用语言。
第三章 上下文映射图
界限上下文的关系
- 合作关系：两个界限上下文的团队之间建立合作关系；
- 共享内核：共享模型和代码；
- 客户方-供应方开发：上下游关系；
- 遵奉者：在存在上下游关系的两个团队中，如果上游团队已经没有动力提供下游之所需，处于利他主义，对下游团队做出种种很可能无法实现的承诺；
- 防腐层（ACL）：防腐层通过已有接口与其他系统交互，其他系统只需要做很小的修改，甚至无需修改，在防腐层内部，它在你自己的模型和他方模型之间做翻译转换；
- 开放主机服务(OHS)：定义一种协议，让你的子系统通过该协议来访问你的系统；
- 发布语言(PL)：发布出来的共享语言（在两个界限上下文之间翻译模型的公用语言），通常与主机开放服务一起使用；
- 另谋他路：功能解耦；
- 大泥球：系统中混在一起的边界模糊的模型；
上下文映射图
- 上游模型会对下游模型产生影响，不管是正面的还是负面的，就像河流一样；
集成界限上下文
集成模式采用的技术：
- 开放主机服务：该模式可以通过REST实现，通常来讲，我们可以将开放主机服务看成是远程过程调用的API,同时，他也可以通过消息机制实现。
- 发布语言：XML、JSON、HTML，同时，发布语言还可以用于事件驱动架构，其中，领域事件以消息的形式发送到订阅方；
- 防腐层：翻译；
第四章 架构
分层
- DDD系统的传统分层模型，用户接口层-》应用层-》领域层-》基础设施层
- 分层架构的原则：根据该原则，迁移后的系统应该属于严格分层架构；
- 严格分层架构：某层只能与直接位于其下方的层发生耦合；
- 松散分层架构：允许任意上方层与任意下方层发生耦合；
- 用户界面层： 只用于处理用户显示和用户请求，它不应该包含领域或业务逻辑；
- 应用层：应用服务，应用服务很轻量，主要协调对领域服务对象的操作，同时，应用服务是表达用例和用户故事的主要手段。应用服务的通常用途是，接受来自用户节目安的输入参数，再通过资源库获取到聚合实例，然后执行相应的命令操作。
依赖倒置原则
高层模块不应该依赖底层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
六边形架构
- 外部区域：不同的客户提交输入；
- 内部区域：获取持久化数据，并对程序输出进行存储，或者在中途将输出转发到另外的地方； 将
- 端口与适配器风格：每种类型的客户都拥有他自己的适配器。
- 无论采用哪种方式对端口进行划分，当客户请求到达时，都应该有相应的适配器对输入进行转化，然后端口将调用应用程序的某个操作，或者向应用程序发起一个事件，控制权由此交给内部区域。
- 应该根据应用程序的功能需求来创建用例，而不是客户数量或输出机制；
- 六边形的一大好处在于，我们可以轻易的开发用于测试的适配器，整个应用程序和领域模型都可以在没有客户和存储机制的条件下进行设计开发；
- 分层架构的原则：根据该原则，迁移后的系统应该属于严格分层架构；
面向服务架构（SOA）
soa原则
- 服务契约：通过契约文档，服务阐述自身的目的和功能；
- 松耦合：服务将依赖关系最小化；
- 服务抽象：服务只发布契约，而向客户隐藏内部逻辑；
- 服务重用性：一种服务可以被其他服务所重用；
- 服务自治性：服务自行控制环境与资源以保持独立性，这有助与保持服务的一致性和可靠性；
- 服务无状态性：服务负责消费方的状态管理，这不能与服务的自治性发生冲突；
- 服务可发现性：客户可以通过服务元数据来查找服务和理解服务；
- 服务组合性：一种服务可以由其他的服务组合而成，而不管其他服务的大小和复杂性如何；