1.6 PhalApi 2.x Domain领域层和ADM模式

Domain领域业务层与ADM模式解说

PhalApi使用的是ADM分层模式，Domain是连接Api层与Model层的桥梁。

何为Api-Domain-Model模式？

在传统Web框架中，惯用MVC模式。可以说，MVC模式是使用最为广泛的模式，但同时也可能是误解最多的模式。然而，接口服务这一领域，与传统的Web应用所面向的领域和需要解决的问题不同，最为明显的是接口服务领域中没有View视图。如果把MVC模式生搬硬套到接口服务领域，不但会产生更多对MVC模式的误解，还不利于实际接口服务项目的开发和交付。

仔细深入地再思考一番，接口服务除了需要处理输入和输出，以及从持久化的存储媒介中提取、保存、删除、更新数据外，还有一个相当重要且不容忽视的任务——处理特定领域的业务规则。而这些规则的处理几乎都是逻辑层面上对数据信息的加工、转换、处理等操作，以满足特定场景的业务需求。对于这些看不见，摸不着，听不到的领域规则处理，却具备着交付有价值的业务功能的使命，与此同时也是最为容易出现问题，产生线上故障，引发损失的危险区。所以，在接口服务过程中，我们应该把这些领域业务规则的处理，把这些受市场变化而频繁变动的热区，单独封装成一层，并配套完备的自动化测试体系，保证核心业务的稳定性。

基于以上考虑，在MVC模式的基础上，我们去掉了View视图层，添加了Domain领域业务层。从而涌现了Api-Domain-Model模式，简称ADM模式。

简单来说，

• Api层 称为接口服务层，负责对客户端的请求进行响应，处理接收客户端传递的参数，进行高层决策并对领域业务层进行调度，最后将处理结果返回给客户端。

• Domain层 称为领域业务层，负责对领域业务的规则处理，重点关注对数据的逻辑处理、转换和加工，封装并体现特定领域业务的规则。

• Model层 称为数据模型层，负责技术层面上对数据信息的提取、存储、更新和删除等操作，数据可来自内存，也可以来自持久化存储媒介，甚至可以是来自外部第三方系统。

专注领域的Domain业务层

Domain领域业务层，主要关注的是领域业务规则的处理。在这一层，不应过多关注外界客户端接口调用的签名验证、参数获取、安全性等问题，也不应过多考虑数据从何而来、存放于何处，而是着重关注对领域业务数据的处理。

ADM职责划分与调用关系

传统的接口开发，由于没有很好的分层结构，而且热衷于在一个文件里面完成绝大部分事情，最终导致了臃肿漫长的代码，也就是通常所说的意大利面条式的代码。

在PhalApi中，我们针对接口领域开发，提供了新的分层思想：Api-Domain-Model模式。即便这样，如果项目在实际开发中，仍然使用原来的做法，纵使再好的接口开发框架，也还是会退化到原来的局面。

为了能让大家更为明确Api接口层的职责所在，我们建议：

Api接口服务层应该做：

• 应该：对用户登录态进行必要的检测
• 应该：控制业务场景的主流程，创建领域业务实例，并进行调用
• 应该：进行必要的日记纪录
• 应该：返回接口结果

• 应该：调度领域业务层

  Api接口服务层不应该做：

• 不应该：进行业务规则的处理或者计算
• 不应该：关心数据是否使用缓存，或进行缓存相关的直接操作
• 不应该：直接操作数据库

• 不应该：将多个接口合并在一起

  Domain领域业务层应该做：

• 应该：体现特定领域的业务规则
• 应该：对数据进行逻辑上的处理
• 应该：调度数据模型层或其他领域业务层

Domain领域业务层不应该做：

• 不应该：直接实现数据的操作，如添加并实现缓存机制

Model数据模型层应该：

• 应该：进行数据库的操作
• 应该：实现缓存机制

在明确了上面应该做的和不应该做的，并且也完成了接口的定义，还有验收测序驱动开发的场景准备后，相信这时，即使是新手也可以编写出高质量的接口代码。因为他会受到约束，他知道他需要做什么，主要他按照限定的开发流程和约定稍加努力即可。

如果真的这样，相信我们也就慢慢能体会到精益开发的乐趣。

至于调用关系，整体上讲，应根据从Api接口层、Domain领域层再到Model数据源层的顺序进行开发。

在开发过程中，需要注意不能越层调用也不能逆向调用，即不能Api调用Model。而应该是上层调用下层，或者同层级调用，也就是说，我们应该：

• Api层调用Domain层
• Domain层调用Domain层
• Domain层调用Model层

• Model层调用Model层

  如果用一张图来表示，则是：

为了更明确调用的关系，以下调用是错误的：

• 错误的做法1：Api层直接调用Model层
• 错误的做法2: Domain层调用Api层，也不应用将Api层对象传递给Domain层

• 错误的做法3: Model层调用Domain层

这样的约定，便于我们形成统一的开发规范，降低学习维护成本。比如需要添加缓存，我们知道应该定位到Model层数据源进行扩展；若发现业务规则处理不当，则应该进入Domain层探其究竟；如果需要对接口的参数进行调整，即使是新手也知道应该找到对应的Api文件进行改动。