<<领域驱动开发>>摘要

分层

领域层 – 核心
应用层 – 领域的一个使用场景
基础设施 – 实现的支撑系统

构件

Entity – 需要追踪生命周期的具有唯一标识的对象
Value Object – 属性对象，一般不可变
Service – 放置不属于领域层对象（Entity或Value Object）的操作
Aggregate – 领域对象的集合，以Entity作为跟外部交互的root，有且只有一个root，内部对象封装在它里面
Factory – 封装对象创建逻辑
Repository – 跟持久化交互的层，封装简单存储、恢复对象的操作

其他模式

specification 一种VO，封装条件逻辑，在验证、从集合中选择对象、根据要求创建对象的时候使用

Intention-Revealing interface 接口设计原则，只描述意图而隐藏实现。命名类和操作时要描述它们的效果和目的，而不要表露它们通过何种方式达到目的。清楚地分离函数、命令或查询，函数描述它的行为，命令需要说明它的副作用。

side-effect-free function 尽可能把程序逻辑放到函数中，因为函数不产生副作用。如果发现一个适合承担复杂逻辑职责的概念，就可以把这个复杂逻辑放到value object中。

assertion 使用断言把副作用表示出来。

closure of operation 闭合操作，实现者的类型和参数、返回值的类型一致，那么这个操作没有引入其他依赖类型，可以认为是一个闭合操作。

柔性设计

去掉类之间不必要的关联，保持低耦合。低耦合的极致是standalone class。
每多产生一个概念-显示或隐式，都会加重理解的负担。

切入问题的角度

• 分割子领域
  重点突击某个部分，使设计的一个部分真正变得灵活起来

• 尽可能利用已有的形式
  对领域中建立已久的概念加以修改和利用

战略设计

开发一个包含所有业务的统一大模型不是一种行之有效且经济的做法。

三个主题

• 上下文 bounded context 划分了各个子模型的边界

  给上下文起名称，并添加到ubiquitous language中
  在单个bounded context中持续集成
  一般来说，一个bounded context对应一个团队。一个团队可以维护多个bounded context，但是多个团队在一个bounded context工作通常比较困难。

  • 合并代码和其他实现工件

  • 自动测试查明模型分裂问题

  • 严格坚持使用ubiquitous language，对概念模型达成共识

    bounded context之间使用context map描述它们的关系
    context map模式之间的区别在于对另一模型的控制程度、两个团队的合作水平和合作类型，以及特性和数据的集成程度

  • shared kernel 两个团队共享各自领域模型的一个子集以及相关代码、数据，集成的频率比持续集成低，每次修改必须通过两个团队的测试

  • customer/supplier development team 单向的依赖关系，必须有自动测试套件，两个团队需要良好的合作，最好属于同一个管理者

  • conformist 跟随者模式 当上游团队没有合作意愿的时候，且接口很大集成很重要的时候，遵从上游团队的模型可以简化集成

  • anticorruption layer 当需要集成不同模型且无法控制的系统时，创建防护层是一个防止模型因为集成而受到影响的好方法。

    • 以service提供对集成系统的访问
    • adapter 接收访问请求，处理集成系统返回的结果
    • facade 对集成系统的接口进行简化
    • translator 提供对象转换功能，adapter调用它实现转换

    • separate way 独立自主 集成代价高而收益小，不如单独开发一个新的 bounded context

    • open host service 当需要与大量其他子系统集成时，可以把你的子系统作为一组service供其他系统访问

      • published language 良好文档化、能够表达领域信息的共享语言作为公共的通信媒介

    

• 精炼 集中注意力到最核心的部分

  目的

  • 帮助所有团队成员掌握系统的总体设计及协调

  • 找到适度规模的核心模型并把它添加到通用语言中，从而促进沟通

  • 指导重构

  • 专注于模型最有价值的部分

  • 指导外部、现成组件的使用以及人物委派

    实施方法

  • 对模型进行提炼，找到并精炼core domain，最有价值和最专业的概念要轮廓分明。

  • 让最有才能的人来开发core domain

  • 识别并分离通用子领域（非core domain），考虑使用现成的解决方案或公开发布的模型

    

  • domain vision statement 领域前景说明，写一份core domain的简短描述以及它会创造的价值，展示出领域模型是如何实现和均衡各方利益的。

  • highlighted core 编写简短文档，描述core domain和core元素之间的主要交互过程。

  • cohesive mechanism 把概念上的内聚机制分离到单独的轻量级框架中，用一个intention-revealing interface来公开框架的功能，它用来满足规则或模型指定的计算。

  • segregated core 把核心概念从支持性元素中分离出来，增强core内聚性，减少与其它代码的耦合。

  • abstract core 把模型中最基本的概念识别出来，并分离到不同的类、抽象类或接口中，使之能表达出重要组件的大部分交互。

• 大比例结构

  大比例结构是一种语言，人们可以用它来从大局上讨论和理解系统。
  设计一种应用于整个系统的规则（或角色和关系）模式，使人们可以通过它在一定程度上了解各个部分在整体中所处的位置。

  

• evolving order

  应该允许大比例结构随着应用程序一起演变，有些设计和模型的决策必须在掌握了详细知识之后才能确定，这样的决策不能过早地制定。
  当发现一种大比例结构明显地使系统变得更清晰，而又没有为模型开发施加不自然的约束时，就应该采用这种结构。要记住宁缺毋滥的原则。

• system metaphor 当系统的一个具体类比正好符合团队成员对系统的想象，并且能够引导他们向着一个有用的方向思考时，就应该把这个类比用作一种大比例结构。

• responsibility layer 如果在领域中发现了自然的层次结构，就把它们转换为主要的抽象职责。

• knowledge level 创建一组不同的对象，用它们来描述和约束基本模型的结构和行为。把这些对象分为两个级别，一个是非常具体的级别，另一个则提供了一些可供用户或超级用户定制的规则和知识。

• plugable component framework 从接口和交互中提炼出一个abstract core，并创建一个框架，这个框架要允许这些接口的各种不同实现被自由替换。缺点是难以使用和只为应用程序提供有限的选择。

战略设计决策的要点

• 决策必须传达到整个团队
• 决策过程必须收集反馈意见
• 计划必须允许演变
• 架构团队不必把所有最好、最聪明的人员都吸收进来
  领域专家对架构也很重要。应用程序的开发也需要技术能力强的人。
• 战略设计需要遵守简约和谦逊的原则
• 对象的职责专一，而开发人员应该是多面手

领域驱动设计的标志

把理解目标领域并把学到的知识融合到软件中当作首要任务。