领域驱动设计《读书笔记》
很多因素致使软件错综复杂,其中最主要的因素是领域本身错综复杂.领域驱动讲求将领域模型作为领域专家、分析人员、开发人员之间交流沟通的核心.所以要在开发中找到一个好的领域模型,好的领域模型不是仅仅停留在表面，而要深入到领域的实质结构。势必需要达到了解或者精通领域业务的层次。当然有领域专家的辅助可以节省一些挖掘领域业务知识的时间和精力.
领域模型是领域专家和分析人员互相沉淀知识的一个工具，它帮助分析人员理解领域知识，也为领域专家提供一个规范的表达形式，有条有理的描绘领域知识，分析、解决领域问题。另外，领域模型也是开发团队知识沉淀的一种方式，帮助开发人员了解他所从事的特定领域，提高建模技能。领域模型其实是一种语言，领域专家与分析人员、开发人员之间交流的通用语言。
领域驱动设计的实质是"消化大量的知识，最后产生一个反映深层次领域知识并聚焦于关键概念的模型”.本书的核心思想是在实现，设计和团队交流中使用一个模型作为基础.
参见:http://kb.cnblogs.com/a/814784/
领域驱动设计书本结构
1,让领域模型发挥作用:提出领域驱动开发的基本目标
2,模型驱动设计的构造块:将建模核心的最佳实践提炼为一组基本的构造块
3,通过重构加深理解:深入研究模型-》实现初始设计-》反复设计-》重构
4,战略设计:讨论复杂系统，大型组织以及与外部系统和遗留系统的交互,探讨应用于系统的3条原则：上下文，提炼和大规模结构
PART1:让领域模型发挥作用
开发人员必须专研领域已获取业务知识，必须练习建模技巧，精通领域设计.
CP1消化知识
有效建模的要素:模型和实现绑定，获取基于模型的语言，开发蕴含丰富知识的模型，提炼模型，头脑风暴和实验
消化知识和持续学习(高效率的团队需要有意识的积累知识，并持续学习).
通过各种方式学习领域知识:与领域专家进行交流沟通,查找学习相关资料/知识…如此才能构建深层模型.
CP2语言的交流和沟通
UBIQUITOUS LANGUAGE:建立统一的术语，统一团队语言.使用统一的词汇表(类名称和主要操作)，所有开发人员都是基于模型的语言来描述系统的工件，任务和功能.
将模型作为语言的中心，确保团队在所有的交流活动和代码中坚持使用这种语言.
文档应该作为代码和口头交流之外的补充,必须保持最新.
CP3绑定模型和实现
MDD(MODEL-DRIVEN DESIGN):分析模型工作一定要抓住领域内的基础概念，并且用易于理解和表达的方式描述.软件的各部分设计都应该忠实反映模型.软件开发就是一个不断精化模型，设计和代码的统一的迭代过程.一定要在可控的范围内保持设计和模型的一致性…
设计需要反复研究领域，不断重构，将重要的概念提炼成简单而清晰的模型.
MDD利用模型来解决问题，项目组通过消化知识来提炼模型，MDD将模型和设计紧密结合，UBIQUITOUS LANGUAGE成为开发人员，领域专家和软件产品之间传递信息的渠道.
PART2:模型驱动设计的构造块
本书所讲的设计风格主要遵循”职责驱动设计”原则.
此图为MDD语言导航图，用于描述本部分的模式和彼此关联
CP4分离领域
将领域对象和系统中的其他功能分离，以避免将领域概念和其他软件技术相关的概念混淆.
1LAYERED ARCHITECTURE分层
| UI层 |
| 应用层(为领域层协调任务,分配工作) |
| 领域层(负责业务概念，反映业务情况的状态,由业务逻辑和实现组成) |
| 基础设施层(为上层提供通用技术) |
先中间(领域层)后两边(应用层,UI层和基础设施层)，模型属于领域层。
2THE SMART-UI"ANTI-PATTERN"
在用户界面层中实现业务逻辑，嵌入业务规则---》反模式
CP5软件中所表示的模型
模型的三种模式:ENTITY,VALUE OBJECT,SERVICE
一个对象表示具有连续性和标识的食物呢还是用于描述某个事物的的某种状态属性呢？这是ENTITY和VALUE OBJECT的区别。
领域中还有一些适用作操作和动作的表示—》SERVICE。
MDD中MODULE是模型的一部分，应该反映领域中的相关概念.
减少关联的方法
- 规定一个遍历方向
- 添加一个限定符，以便有效减少多重关联
- 消除不必要的关联
模式:
- ENTITY(REFERENCE OBJECT)：ENTITY的基本职责是确保连续性，以便使其行为更清楚且可预测.保持实体的简练.
- VALUE OBJECT：用于描述领域的某个方面而本身没有概念标识的对象称为VALUE OBJECT.只关心模型的属性时应该把它归类为VALUE OBJECT
- SERVICE：模型中的操作，不适合被建模为对象--》服务
- MODULE：MODULE间为低耦合，内部为高内聚.MODULE不仅仅是代码的划分，而是概念的划分.内聚的概念集合.
一切设计都是基于模型进行展开.
CP6领域对象的生命周期
对象创建出来要么被删除，要么存档。
模式:AGGREGATE—>FACTORY/REPOSITORY
使用AGGREGATE建模用于控制对象的所属关系和分界，使用FACTORY创建对象，使用REPOSITORY提供查询和检索持久化对象.
在AGGREGATE模式中只能外界只能通过Entity进行访问,AGGREGATE内部的属性不能为外界说持有引用，只能暂时使用.
模式:Factory
为创建复杂对象提供统一接口(设计模式中工厂方法，抽象工厂，创建者比较适用,如果需要根据不同规则进行创建,则可能需要使用策略模式进行创建),固定规则可以在FACTORY内部直接定义好.
模式:REPOSITORY
对象存储持久化操作，基本上都是涉及到数据库操作，当然可以使用对文件,流等不同形式对模型进行持久化.
CP7使用语言:一个扩展的示例
使用第二部分的模式进行演示.
PART3通过重构加深理解
不断重构是给系统中最需要修改的地方添加灵活性，前提为必须对领域知识的不断深入掌握.
CP8突破
团队掌握,积累,消化知识,进行不断重构.重构的原则始终小步前景，保持系统正常运转.深层建模(深入领域知识，冷静决策).
CP9将隐式概念转变为显式概念
概念挖掘:倾听领域专家的语言,挖掘不同,不理解,沟通不畅的概念.检查不足之处.思考矛盾之处.查阅书籍.尝试.
如何为不明显概念建模:显示的约束(规则)
模式:SPECIFICATION
通过SPECIFICATION对规则进行封装.
通过特性对属性进行封装:碗->口径，材质，价格等属性通过模型进行抽象封装…
CP10:柔性设计
使变更更加容易而且清晰,根本目的在于提高内聚,降低耦合.
模式:INTENTION REVEALING-INTERFACES(释意接口)-类,函数，其他元素名称放映他们的目的，也放映客户开发人员的价值.暴露接口而非实现(名字即表达用意)
模式:SIDE EFECT FREE FUNCTION（无副作用函数）-专注函数功能,避免副作用函数,将复杂计算封装到SIDE EFECT FREE FUNCTION,边际效应/副作用 是状态的记录、改变造成，象deep copy（Hibernate等ORM中就用的很多）就是为了避免side effect。
模式:ASSERTION-预测结果，将函数副作用暴露出来
模式:CONCEPTUAL CONTOUR(概念轮廓)-将相关内容某型放在相应的区域中.使得局部相对稳定.
模式:STANDALONE CLASS-将复杂计算封装到STANDALONE CLASS中.
模式:CLOSURE OF OPERATION-指返回值跟操作对象类型相同，主要用在值对象上,用于定义不涉及其他概念的运算,通常为VALUE OBJECT.
声明式设计:指将程序或者程序的一部分写成一种可执行的规格(SPECIFICATION),e.g….逻辑运算符进行封装AndOperation,OrOperation…使用非常精确的描述.
CP11:分析模式的应用
分析模式:一种概念集合，用来表示业务建模中的常见构造.分析模式的最大作用是借鉴其他项目的经验，把那些项目中所作的广泛的设计方向讨论和实现结果的经验与当前的模型结合起来.
本章实例演示分析模式在建模过程中的应用.
CP12:将设计模式应用于模型
并非所有的设计模式适用于领域模式,本章使用COMPOSITE/STRATEGY演示设计模式来解决领域问题
模式:STRATEGY-定义一组算法,将每个算法封装起来,并使他们可以互相替换,STRATEGY允许算法独立于使用它的客户而变化.
在领域建模的过程中可以使用STARTEGY对业务策略进行建模
模式COMPOSITE-将对象组织为树结构来表示部分-整体的层次结构，利用COMPOSITE客户可以对单独的对象和对象组合进行同样的处理。
嵌套容器…透明的放映他们的构成情况.
CP13:通过重构得到更深层的理解
通过重构得到更深层次的理解需要做的三件事请:以领域为本，用一种不同的方式来看待事物，始终坚持与领域专家对话
重构的原因:模型与领域专家的不一致，新的需求不能很自然的添加到模型中.
持续重构,通过重构得到更深层的理解是一个持续不断的过程.
PART4战略设计
战略设计的原则:减少各部分的互相依赖，提高清晰度，而不丢失关键的互操作性和协同性。
战略设计的原则必须把模型的重点放在捕获系统的概念核心-系统的“远景”.
本章主要关注:上下文，精炼，大比例结构
通过上下文理清模型的关系，通过精炼减少混乱，将注意力集中在正确的地方，通过大比例结构来描述整体系统.
CP14:保持模型的完整性
使用BOUNDED CONTEXT定义每个模型的应用范围，CONTEXT MAP则给出项目上下文以及它们之间的总体视图
模式:BOUNDED CONTEXT-明确的定义上下文，在边界中严格保持模型的一致性.
模式:CONTINOUS INTEGRATION-将上下文中的所有工作足够频繁的合并到一起，并使他们保持一致.主要有两个级别的操作:模型概念的集成，实现的集成
模式:CONTEXT MAP-描述模型间的接触点，明确每次交流所需的转换，并突出任何共享的内容.明确上下文的各自区域，并且将它们的交互使用CONTEXT MAP进行映射.ORACLE ADF架构中使用BINDING进行上下文的转换-模块间的耦合.http://www.west263.com/info/html/chengxusheji/Javajishu/20080225/45537.html
BOUNDED CONTEXT之间的关系
模式:SHARED KERNEL-CORE DOMAIN,团队间共享领域
模式:CUSTOMER/SUPPLIER(客户/供应商关系)-上下游团队间的关系
模式:CONFIRMIST(跟随者)-严格遵守上游团队的模型
模式:ANTICORRUPTION LAYER-创建一个隔离的层，根据自己的领域模型来为客户提供相关的功能.FACADE/ADAPTER+转换器
模式:SEPARATER WAY-严格规定需求反问,如果两组功能间的关系非必不可少,那么而这可以完全独立.
模式:OPEN HOST SERVICE-定义一个协议，把你的子系统作为一组Service供其他系统访问.WEB SERVICE,SOA
模式:PUBLISHED LANGUAGE-利用公开发布的语言作为通信媒介进行交互.XML
14.12:将各个模式在项目中进行应用的一些指导和说明.
CP15精炼
模型是知识的精炼，但是精炼的动机是把最有价值的那部分提取出来，正是这部分使我们的软件区别于其他的软件(CORE DOMAIN)
模式:CORE DOMAIN-核心领域
模式:GENERIC SUBDOMAIN-通用领域
模式:DOMAIN VISION STATEMENT(领域前景说明)
模式:HIGHLIGHITED CORE(突出的核心)
模式:COHESIVE MECHANISM（内聚机制）-分离到一个单独的轻量级框架中，注意公式算法
模式:SEGREGATED CORE（隔离的领域）
模式:ABSTRACT CORE（抽象的内核）
集中注意力在CORE DOMAIN中，完善对CORE的隔离，把支持性的子领域提炼为通用领域
CP16:大比例结构
模式:EVOLVING ORDER
模式:SYSTEM METAPHOR(系统隐喻)
模式:RESPONSIBILITY LAYER:作业,职责
潜能层，作业层，决策支持层，策略层，承诺层
模式:KNOWLEDGE LEVEL(知识级别)一组描述另一组对象应该有哪些行为的对象
模式:PLUGGABLE COMPONENT FRAMEWORK(可插入式组件框架)
CP17:综合运用
