四 领域驱动设计-分离领域
模型驱动设计的构造块-分离领域
在软件中，虽然专门用于解决领域问题的那部分通常只占整个软件系统的很小一部分，但其却出乎意料的重要。我们需要着眼于模型中的元素并且将它们视为一个系统。绝不能像在夜空中辨认星座一样，被迫从一大堆混杂的对象中将领域对象挑选出来。我们需要将领域对象与系统中的其他功能分离，这样就能够避免将领域概念和其他只与软件技术相关的概念搞混了，也不会在纷繁芜杂的系统中完全迷失了领域。
分离领域的复杂技术早已出现，而且都是我们耳熟能详的，但是它对于能否成功运用领域建模原则起着非常关键的作用，所以我们要从领域驱动的视角对它进行简要的回顾。
LAYERED ARCHITECTURE
在一个运输应用程序中，要想支持从城市列表中选择运送货物目的地这样的简单用户行为，程序代码必须包括：(1) 在屏幕上绘制一个屏幕组件（widget）；(2) 查询数据库，调出所有可能的城市；(3) 解析并验证用户输入；(4) 将所选城市与货物关联；(5) 向数据库提交此次数据修改。上面所有的代码都在同一个程序中，但是只有一小部分代码与运输业务相关。
软件程序需要通过设计和编码来执行许多不同类型的任务。它们接收用户输入，执行业务逻辑，访问数据库，进行网络通信，向用户显示信息，等等。因此程序中的每个功能都可能需要大量的代码来实现。
在面向对象的程序中，常常会在业务对象中直接写入用户界面、数据库访问等支持代码。而一些业务逻辑则会被嵌入到用户界面组件和数据库脚本中。这么做是为了以最简单的方式在短期内完成开发工作。
最早期的jsp就是这样干的，jsp页面直接写后端代码。现在php也可以这样干，所以开发特别快
如果与领域有关的代码分散在大量的其他代码之中，那么查看和分析领域代码就会变得异常困难。对用户界面的简单修改实际上很可能会改变业务逻辑，而要想调整业务规则也很可能需要对用户界面代码、数据库操作代码或者其他的程序元素进行仔细的筛查。这样就不太可能实现一致的、模型驱动的对象了，同时也会给自动化测试带来困难。考虑到程序中各个活动所涉及的大量逻辑和技术，程序本身必须简单明了，否则就会让人无法理解。
要想创建出能够处理复杂任务的程序，需要做到关注点分离——使设计中的每个部分都得到单独的关注。在分离的同时，也需要维持系统内部复杂的交互关系。
软件系统有各种各样的划分方式，但是根据软件行业的经验和惯例，普遍采用LAYERED ARCHITECTURE（分层架构），特别是有几个层基本上已成了标准层。分层这种隐喻被广泛采用，大多数开发人员都对其有着直观的认识。LAYERED ARCHITECTURE的基本原则是层中的任何元素都仅依赖于本层的其他元素或其下层的元素。向上的通信必须通过间接的方式进行。
分层的价值在于每一层都只代表程序中的某一特定方面。这种限制使每个方面的设计都更具内聚性，更容易解释。当然，要分离出内聚设计中最重要的方面，选择恰当的分层方式是至关重要的。在这里，经验和惯例又一次为我们指明了方向。尽管LAYERED ARCHITECTURE的种类繁多，但是大多数成功的架构使用的都是下面这4个概念层的某种变体。
给复杂的应用程序划分层次。在每一层内分别进行设计，使其具有内聚性并且只依赖于它的下层。采用标准的架构模式，只与上层进行松散的耦合。将所有与领域模型相关的代码放在一个层中，并把它与用户界面层、应用层以及基础设施层的代码分开。领域对象应该将重点放在如何表达领域模型上，而不需要考虑自己的显示和存储问题，也无需管理应用任务等内容。这使得模型的含义足够丰富，结构足够清晰，可以捕捉到基本的业务知识，并有效地使用这些知识。
将领域层与基础设施层以及用户界面层分离，可以使每层的设计更加清晰。彼此独立的层更容易维护，因为它们往往以不同的速度发展并且满足不同的需求。层与层的分离也有助于在分布式系统中部署程序，不同的层可以灵活地放在不同服务器或者客户端中，这样可以减少通信开销，并优化程序性能。
架构框架和其他工具都在不断的发展。新框架将越来越多的应用技术问题变得自动化，或者为其提供了预先设定好的解决方案。如果框架使用得当，那么程序开发人员将可以更加专注于核心业务问题的建模工作，这会大大提高开发效率和程序质量。但与此同时，我们必须要保持克制，不要总是想着要寻找框架，因为精细的框架也可能会束缚住程序开发人员。
个人理解：现在的软件开发一般都是前后端分离，后端使用springmvc或者springboot和服务加数据持久化层，通用的就是springboot+mybatis+mysql这一套。这个对于程序开发人员来说非常好理解，业务人员不理解也没关系。以上内容现在已经是通用的开发架构模式，所以，这篇不用看也可以的。
