领域驱动设计的构造快
分离领域
- LAYERED ARCHITECTURE 的基本原则是层中的任何元素都仅依赖于本层的其他元素或其下层的元素。分层的价值在于每⼀层都只代表程序中的某⼀特定⽅⾯。这种限制使每个⽅⾯的设计都更具内聚性，更容易解释。分层的价值在于每⼀层都只代表程序中的某⼀特定⽅⾯。 这种限 制使每个⽅⾯的设计都更具内聚性，更容易解释
- 用户界面层：负责向用户显示信息和解释用户指令。这里指的用户可以是另一个计算机系统，不一定是使用用户界面的人。
- 用户界面层：定义软件要完成的任务，并且指择表达领域概念的对象来解決问题。这一层所负责的工作对业务来说意义重大，也是与其他系统的应用层进行交互的必要渠道应用层要尽量简单，不包含业务规则或者知识，而只为下一层中的领域对象协调任务，分配工作，使它们互相协作。它没有反映业务情况的状态，但是却可以具有另外一种状态，为用户或程序显示某个任务的进度。
- 应用层：负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的，但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心。
- 基础设施层：为上面各层提供通用的技术能力，为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏慕组件，等等。基础设施层还能够通过架构框架来支持 4 个层次间的交互模式。
- 给复杂的应⽤程序划分层次。在每⼀层内分别进⾏设计，使其具有内聚性并且只依赖于它的下层。采⽤标准的架构模式，只与上层进⾏松散的耦合。将所有与领域模型相关的代码放在⼀个层中，并把它与⽤户界⾯层、应⽤层以及基础设施层的代码分开。领域对象应该将重点放在如何表达领域模型上，⽽不需要考虑⾃⼰的显⽰和存储问题，也⽆需管理应⽤任务等内容。这使得模型的含义⾜够丰富，结构⾜够清晰，可以捕捉到基本的业务知识，并有效地使⽤这些知识。
- 各层之间是松散连接的，层与层的依赖关系只能是单向的。 上层可以直接使⽤或操作下层元素，⽅法是通过调⽤下层元素的公共接口，保持对下层元素的引⽤（⾄少是暂时的），以及采⽤常规的交互⼿段。⽽如果下层元素需要与上层元素进⾏通信（不只是回应直接查询），则需要采⽤另⼀种通信机制，使⽤架构模式来连接上下层，如回调模式或 OBSERVERS 模式。
- 通常，基础设施层不会发起领域层中的操作，它处于领域层“之下”，不包含其所服务的领域中的知识。 事实上这种技术能⼒最常以 SERVICE 的形式提供。例如，如果⼀个应⽤程序需要发送电⼦邮件，那么⼀些消息发送的接⼜可以放在基础设施层中，这样，应⽤层中的元素就可以请求发送消息了。这种解耦使程序的功能更加丰富。消息发送接⼜可以连接到电⼦邮件发送服务、传真发送服务或任何其他可⽤的服务。但是这种⽅式最主要的好处是简化了应⽤层，使其只专注于⾃⼰所负责的⼯作：知道何时该发送消息，⽽不⽤操⼼怎么发送。
- 应⽤层和领域层可以调⽤基础设施层所提供的 SERVICE。如果 SERVICE 的范围选择合理，接口设计完善，那么通过把详细⾏为封装到服务接⼜中，调⽤程序就可以保持与 SERVICE 的松散连接，并且⾃⾝也会很简单。
- 不妄求万全之策，只要有选择性地运⽤框架来解决难点问题，就可以避开框架的很多不⾜之处。明智⽽审慎地选择框架中最具价值的功能能够减少程序实现和框架之间的耦合，使随后的设计决策更加灵活。更重要的是，现在许多框架的⽤法都极其复杂，这种简化⽅式有助于保持业务对象的可读性，使其更富有表达⼒。
- 领域模型是⼀系列概念的集合。“领域层”则是领域模型以及所有与其直接相关的设计元素的表现，它由业务逻辑的设计和实现组成。在 MODEL-DRIVEN DESIGN 中，领域层的软件构造反映出了模型概念。
- 领域驱动设计只有应⽤在⼤型项⽬上才能产⽣最⼤的收益，⽽这也确实需要⾼超的技巧。不是所有的项⽬都是⼤型项⽬；也不是所有的项⽬团队都能掌握那些技巧。
- 如果⼀个架构能够把那些与领域相关的代码隔离出来，得到⼀个内聚的领域设计，同时又使领域与系统其他部分保持松散耦合，那么这种架构也许可以⽀持领域驱动设计。
软件中所表示的模型
领域对象的生命周期
使用语言：一个扩展的示例