1.分层架构的背景

为什么要分层

在软件中，虽然专门用于解决领域问题的那部分通常只占整个软件系统的很小一部分，但其却出乎意料的重要。我们需要将领域对象与系统中的其他功能分离，这样就能避免将领域概念和其他只与软件技术相关的概念搞混了，也不会再纷繁芜杂的系统中完全迷失了领域。

分离领域的复杂技术早已出现，而且都是我们耳熟能详的

软件系统有各种各样的划分方式，但是根据软件行业的经验和惯例，普遍采用LAYERED ARCHITECTURE(分层架构)，特别是有几个层基本上已成了标准层。分层这种隐喻被广泛采用， 大多数开发人员都对其有着直观的认识。许多文献对LAYERED ARCHITECTURE也进行了充分的讨论，有些是以模式的形式给出的。LAYERED ARCHITECTURE的基本原则是层中的任何元素都仅依赖于本层的其他元素或其下层的元素，向上的通信必须通过间接的方式进行。

四层架构的依据

分层的价值在于每一层都只代表程序中的某一特定方面。这种限制使每个方面的设计都更具 内聚性，更容易解释。当然，要分离出内聚设计中最重要的方面，选择恰当的分层方式是至关重要的。在这里，经验和惯例又一次为我们指明了方向。尽管LAYERED ARCHITECTURE的种类繁多， 但是大多数成功的架构使用的都是下面这4个概念层的某种变体。

（1）用户界面层（或表示层）

** **用户界面层的功能通常为用户展示应用信息，或者用户进行操作向应用层发起指令。

（2）应用层

** **应用层定义软件要完成的任务，并且通过与领域层的对象或服务进行交互，将对应问题进行解决。

应用层本身不包含业务规则或知识，逻辑需要尽量简单，对内主要与领域层或基础设施层进行衔接。

在Thrift后端服务中，应用层主要为对外提供的应用服务接口，该层的逻辑应该尽可能简单。

应用层本身不包含业务规则或知识，逻辑需要尽量简单，对内主要与领域层或基础设施层进行衔接。

在Thrift后端服务中，应用层主要为对外提供的应用服务接口，该层的逻辑应该尽可能简单。
应用层本身不包含业务规则或知识，逻辑需要尽量简单，对内主要与领域层或基础设施层进行衔接。

在Thrift后端服务中，应用层主要为对外提供的应用服务接口，该层的逻辑应该尽可能简单。

（3）领域层

领域层是业务软件的核心，负责表达业务的相关概念、业务信息以及业务逻辑规则等。

领域层内部可以根据**限界上下文（Context）**进行划分，在领域层内，将领域组织层不同的package进一步划分各领域的限界上下文。

领域层是业务软件的核心，负责表达业务的相关概念、业务信息以及业务逻辑规则等。

领域层内部可以根据**限界上下文（Context）**进行划分，在领域层内，将领域组织层不同的package进一步划分各领域的限界上下文。
领域层是业务软件的核心，负责表达业务的相关概念、业务信息以及业务逻辑规则等。

领域层内部可以根据**限界上下文（Context）**进行划分，在领域层内，将领域组织层不同的package进一步划分各领域的限界上下文。

（4）基础设施层

** **基础设施层为应用层、领域层提供基础服务，如为应用层传递消息，为领域层提供持久化机制等。基础设施层也可以通过框架为各层的交互进行衔接。

有些项目没有明显划分出用户界面层和应用层，而有些项目则有多个基础设施层。但是将领域层分离出来才是实现MODEL-DRIVEN DESIGN的关键。

因此:

给复杂的应用程序划分层次。在每一层内分别进行设计，使其具有内聚性并且只依赖于它的下层。采用标准的架构模式，只与上层进行松散的耦合。将所有与领域模型相关的代码 放在一个层中，并把它与用户界面层、应用层以及基础设施层的代码分开。领域对象应该将 重点放在如何表达领域模型上，而不需要考虑自己的显示和存储问题，也无需管理应用任务 等内容。这使得模型的含义足够丰富，结构足够清晰，可以捕捉到基本的业务知识，并有效 地使用这些知识。

将领域层与基础设施层以及用户界面层分离，可以使每层的设计更加清晰。彼此独立的层更 容易维护，因为它们往往以不同的速度发展并且满足不同的需求。层与层的分离也有助于在分布式系统中部署程序，不同的层可以灵活地放在不同服务器或者客户端中，这样可以减少通信开销， 并优化程序性能

2.领域模型对象的哲学依据

领域模型设计就是对要解决的现实世界领域问题的一种描述，那么领域驱动设计以何为依据将其分为四类对象呢？在两千多年的古希腊时期，亚里士多德提出了第一个哲学的分类体系-范畴论，用于对所有存在的事物进行最广义的分类。提出了主-谓的描述框架。

亚里士多德将范畴分为十类：

• 实体（例如：人、马）
• 数量（例如：四尺、三斤）
• 性质（例如：白色的、合理的）
• 关系（例如：两倍、小于）
• 位置（例如：在人马星座、在菜市场）
• 时间（例如；昨天、去年）
• 姿态（例如：躺着、坐着）
• 状态（穿着袜子，身披铠甲）
• 行为（切菜、吃饭）
• 承受（被害、被烧毁）

在亚里士多德的哲学观中，实体是描述事物的主体，**其他范畴必须“内居”于一主体。**所谓“内居”，按亚里士多德自己的解释是指不能离开或独立于所属的主体。既然有这种“内居”的主从关系，整个范畴就有了两重划分。实体是现实世界的形而上学基础，而其它范畴则成为实体的属性，需要有某种实体作为属性的基础。

那么在软件领域，我们需要对要解决的问题域世界进行解释和演绎，从这个角度讲，二者有其相通之处。于是，我们可以利用软件术语来进一步阐释亚里士多德划分的这十个范畴。其中，实体可以理解为是我们要描绘事物的主体，数量、性质、关系、地点、时间与形态都是该主体的属性。

这样，我就为领域驱动设计中的四种领域模型对象找到了哲学依据：

• **实体：**实体范畴，是谓语描述的主体。它包含了其他范畴，包括引起属性变化和状态迁移的活动。
• **值对象：**为主体对象的属性，通常代表数量、性质、关系、地点、时间或形态。
• **领域事件：**封装了主体的状况，代表了因为主动活动导致的状态变迁产生的被动遭遇，即过去发生的事实。
• **领域服务：**如前所述，其他范畴必须“内居”于一主体，若活动与遭遇代表的业务行为无法找到一个主体对象来“内居”，就以领域服务作为特殊的主体来封装。

（图片来自《亚里士多德全集 · 范畴篇》）