第四章 分离领域

分层架构

用户界面层：负责向用户显示信息和解释用户指令

应用层：要尽量简单，不包含业务规则或者知识，只为下一层领域对象协调任务，分配工作。

领域层：负责表达业务概念，业务状态信息以及业务规则，反映业务情况的状态由本层控制且使用的。

基础设施层：为上面各层提供通用的技术能力，为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件。

将各层级关联起来

上层可以直接使用或操作下层元素，方法是通过调用下层元素的公共接口，保持对下层元素的引用。如果下层元素需要与上层元素进行通信，则需要采用另一种通信机制，使用架构模式来连接上下层，如回调模式或者观察者模式或者MVC。应用层和领域层可以调用基础设施层所提供的service。如果service的范围选择合理，接口设计完善，那么通过把详细行为封装到服务接口中，调用程序就可以保持与service的松散连接。

反模式

如果一个经验不丰富的项目团队要完成一个简单的项目，却决定使用model-drive-disgn以及layered architecture,那么项目组要经历艰难的学习过程。团队不得不去掌握复杂的新技术，艰难的学习对象建模。再考虑到时间成本。所以不是所有的都适合领域驱动设计。优点：效率高，短时间内实现简单的应用程序。对开发人员要求低。程序之间彼此独立可以准确安排小模块交付。额外扩展简单的功能也很容易。缺点：不通过数据库很难继承应用模块。没有对行为的抽象，当操作用到业务规则时，都必须重复这些规则。抽象的缺乏限制了重构的选择。没有很好的办法来实现复杂的功能。

如果一个架构能够把那些与领域相关的代码隔离出来，得到一个内聚的领域设计，同时又使领域与其他部分保持松散耦合，那么这种架构也许可以支持领域驱动设计。

ps:java天生可以应对大型的复杂的工程项目，所以应该尽可能使用领域驱动设计！