领域驱动设计，读书笔记：5 分离领域

     构造块指一些设计中常用的一些标准模式，公用这些标准模式有助于设计的有序进行，也是项目组成员能够方便理解。同时，标准模式也让通用语言的基础更加丰富。

     领域设计中根据特征来定义模型元素则会让元素更加明确和鲜明，而对元素使用已经验证的模式，则有助于创建和实现这些元素。

第四章 分离领域

     通常，专门用于解决领域问题那部分在系统中只占很小一部分，但是却是系统价值的核心。要想实践DDD，就一定要识别这些领域问题并将其和其他部分隔离开来，而不是需要从一堆混杂的对象种查找，甚至混杂了模型和支持性的组件，这样查看、理解、改进领域模型变得非常困难。

     对系统的任意改造都可能造成业务逻辑的改动，这对维护领域模型带来了困难。

     此外，混杂的系统对自动化测试也带来困难。

     

模式：Layered Architecture 分层架构

     要想创建出能够处理复杂任务的程序，需要做到关注点分离，是这几种每个部分得到单独关注。根据行业的惯例，普遍采用分层架构，其中有几层实际上已经变成了标准层。

     分层的价值在于每一层都表程序中的特定方面，这样每个方面的设计就更具有内聚性也更加清晰。大多数分层架构都是下面这四种概念或者其变体组成：

     1：用户界面层

     2：应用层

     3：领域层|模型层

     4：基础设施层

     其中，将领域层分离出来才是实现DDD的关键。领域对象应该将重点放在如何表达领域模型上，而不需要考虑如何显示和存储，也不需要考虑任务管理等内容。这让模型本身含义丰富结构清晰，能够捕捉和表达核心的领域知识。

     独立的分层更加容易维护，可以以不同速度发展和修改以满足不同需求。分离的层也更加适用于分布式系统的部署。

---

分层架构的关联和架构框架

     分层架构的基本原则是，每一层都依赖于本层其他元素或者下层元素。依赖的方式为调用下层公共接口或者是保持对下层的直接引用。

    下层元素所提供的能力通常以Service的形式提供，让上层元素只需要关注做什么什么条件做，而不是怎么做。

    此外，下层元素也可以作为上层元素的基础，例如共同的抽象基类等。

     向上的通信必须通过间接的方式进行，比如回调或者发布订阅等。因为下层的元素实际上不知道上层的逻辑，所以也就无法知道上层元素该如何工作。因此也就无法直接调用执行。

     

    项目中为了完成层与层的关联，往往是需要总体性框架的，比如MVC框架。这些框架往往带有使用条件，例如特定的方法签名，或者框架基类的子类。因此，框架可能对项目带来额外的限制，也可能增加项目复杂度因为要实现很多方法和配置。

    但是，始终要记住框架是用是为了领域建模服务的，为了更好的抽象出领域层。那么一旦框架本身有悖于这个目标，视图干扰领域的建模，那么宁愿抛弃框架的部分功能甚至换框架。典型的例子是J2EE中的实体Bean。

    如果谨慎选择框架，或者对框架做合理取舍，会让开发和设计人员更加关注于核心业务建模，从而提高开发效率和程序质量。

---

The Smart UI <==> 反DDD模式

    Smart UI就是以UI来驱动设计和实现，不采取非常明确的分层和领域设计，系统的开发过程是以尽快实现业务需求为导向的。比如早期的JSP或者PHP系统，大量的将业务逻辑放在页面中，甚至直接在页面中操作数据持久化。

    Smart UI是应对简单需求和项目的一种方式，这种方式和DDD是相悖的完全不可兼容。事实上，不拆分界面和领域层，则不可能完成领域建模，这也是两者不兼容的原因。所以在使用了Smart UI之后，除非完全重写，否则不能改成其他模式。

    因此，如果选择DDD，那么一开始就要坚定的执行DDD的过程，即使最初的试探性工作，也是通过建立独立领域层开始的。

    项目团队常见的失误在于采用复杂的建模方法，却不能从一而终最终导致项目混乱难以维护。

    事实上，领域驱动设计只有在大型项目和复杂需求上才能发挥最大作用，而且不是每个团队都能掌握DDD的设计方法。

    如果一个经验不丰富的团队完成一个简单项目却选择DDD，那么这个项目组将经历困难的学习过程，艰难的进行建模。同时，项目简单时间也比较短，最终出来的东西也不会很复杂，因此无论是时间还是深度上都无法支持去深度体验DDD。

    项目的另一个常见错误在于，为简单项目选择了父爱在基础设施和工业级工具，但是项目根本不需要这么复杂。

    Smart UI有自己的优势：

• 效率高
• 简单，不需要专门学习培训
• 甚至不需要专门的深入分析需求，直接出原型然后根据用户反馈来直接修改
• 相对独立，可以独立发布，扩展功能也不用考虑很多
• 没有复杂数据处理，数据库的CRUD通常就够用了
• 迅速而无副作用的重构
• 第四代语言支持

4GL以数据库管理系统所提供的功能为核心，进一步构造了开发高层软件系统的开发环境，如报表生成、多窗口表格设计、菜单生成系统、图形图象处理系统和决策支持系统，为用户提供了一个良好的应用开发环境。它提供了功能强大的非过程化问题定义手段，用户只需告知系统做什么，而无需说明怎么做，因此可大大提高软件生产率。

    缺点：

• 很难重用
• 没有抽象，复杂度会很快达到瓶颈
• 大部分灵活的语言如Java，对于小型项目来说是大材小用。而使用开销很大。

    我们讨论Smart UI，不是为了扩展DDD，而是为了引导明白DDD的应用场景。

---

除了分层模式

    除了基础框架和界面，还有一些因素会破坏领域模型，这在14章中讨论。会讨论其他模式，例如：Bounded, Contextde, Anticorruption Layer。

    非常复杂的模型本身也是很难用的，15章会讨论如何进一步拆分复杂模型。