Domain Driven Design -- 一页写完的笔记
Model是什么：
1.业务知识的提炼
2.团队内部良好沟通的基础
===================================================
Ubiquitous Language: 用同一套语言，减少不必要的翻译和误会，促进沟通效率
1.讨论需求时，开发人员与业务人员之间、开发人员与开发人员之间用同一套术语进行交流
2.代码中的元素如类、变量，也要用需求中的术语来命名
===========================
设计中的基本元素：
五个基础要素：
1.Entity
2.Value Object
3.Service
4.Factory
5.Repository
注意Aggregation的概念：一个Agrregation代表一个由多个对象组成的整体，它有一个根对象作为外部访问它的入口。
===========================
使Model更精炼：
1.使Implicit Concepts变得Explicit，比如从“下载一个文件，并记录开始时间和结束时间”可以挖掘出“任务”的概念
2.使用Strategy模式，把算法作为概念
3.应用Analysis Patterns
===============================
多个Model之间的一致性问题：每个团队都有自己的domain model(一个model称作一个bounded coontext)，如何让它们协作？
（这一部分对SOA实践者可以有帮助）
bounded context之间的关系有以下几种模式：
1.Shared Kernel: 共享一部分核心Model, 好处是避免重复开发，提高效率；坏处是一方改变Kernel时可能会对另一方造成较大影响
2.Customer/Supplier模式：Supplier按Customer的要求开发出所需的domain，适用于两个团队同属一个经理的情形
3.Conformist: 如果customer影响不了supplier，干脆屈从于supplier好了。supplier用什么model, customer就用什么，Open API就是一个典型的例子
4.Anti-corruption Layer: 做一个Adapter层。各自用适合自己的domain，交互时再通过adapter进行domain translation. 好处是大家都有各自精炼的模型，坏处是adapter层的开发可能需要比较多的投入
5.Separate Ways: 各走各的路。适用于Integration没什么用的情形
=======================================
进一步精炼Model: 分离出Sub-Domain
Sub-domain仍是domain,但它不属于你的核心业务逻辑。比如你的销售系统里有组织架构层级的概念，如果这个架构层级跟别人没什么区别，就可以把它定义为Generic Sub-domain. 这类逻辑可以通过第三方软件包或者外包实现。
