认识达内从这里开始

随着互联网的不断发展，领域驱动设计也被广大程序员应用到不同软件开发项目之中，而本文我们就通过案例分析来简单了解一下，领域驱动设计分层关注点与常用组件。

客户端

客户端与应用处于不同的进程，是应用能力的消费端，在实际项目中可能是APP端、PC端、小程序端、公众号端或三方的业务调用端等等。

接入层

接入层是外部系统与应用内部业务能力的中间层，接入层是应用层对外的门面，是当前应用对外暴露业务能力的入口。该层的组成可能是对外提供的HTTP接口声明、分布式定时任务调度、消息监听器、RPC服务等等。其重要职责包括对外部系统的请求进行基础的参数校验、入参适配和服务路由(转发至系一层的应用服务)以及响应数据的适配。

业务层:

该层是应用的业务逻辑所在层，整个架构风格采用模块化单体风格，在该层不同的限界上下文体现为不同的模块。在每个限界上下文内采用分层架构，独立划分为应用层、领域层和网关层。

应用层：

协调领域对象、领域服务或外部依赖服务完成业务用例，该层只做能力协调，不处理任何领域逻辑。

领域层：

领域层是整个分层的核心，与技术实现无关，主要负责领域模型、领域事件、领域服务定义，以及业务相关外部服务的接口抽象以及仓库的接口抽象等。

领域层与应用服务的本质区别是：应用层不包含领域逻辑，领域逻辑全部下沉到领域层实现。

网关层：

网关层定位是应用的出口网关，是应用与外部基础设施交互的防腐层，处理所有技术相关实现。

该组件的命名有多种方式，比如有些团队将其命名为“rpc”，也有些团队将其命名为“infrastructure”，不同的命名体现了团队对其背后所表达的隐喻的决策选择。在本文的参考架构中选择了网关-Gateway这一命名，决策原因是：限界上下文自身是高内聚的，其与外部的交互需要统一出口，Gateway所表达的网关的含义恰当的表现了这种统一出口的理念。如果Facade层是应用的北向网关，是外部系统请求进入内部的入口。则此时的Gateway则表达的是限界上下文的南向网关，是内部应用连接外部的出口。

组件及依赖

从宏观的分层我们再深入一层看下每层的组件划分。如下图所示：

Start组件：

整个应用的启动入口、加载应用配置信息等等。

Common组件

提供在不同的限界上下文间复用的领域模型元素的抽象，比如对Command、Query、Event、Entity、ValueObjec通用抽象等。当然，领域模型的通用抽象不是必须在Common组件内以提供复用，也可以作为一个独立的限界上下文，并以共享内核方式与其它上下文进行共享，或者也可以实现为独立的jar包组件。

API组件

RPC类型服务的接口声明组件，以公司内部使用的JSF为例，该组件是应用对外部系统暴露的JSFAPI的组件。该组件可以是独立的工程，当然，有些团队会将其作为一个Module放入应用工程中。

统一门面组件：Facade

外部客户端触达应用系统的入口，也是内部应用服务的统一门面，类似于六边形架构风格下的适配器。参考架构中基于不同场景划分为provider(RPC服务)、task(定时任务)、listener(MQ监听)、rest(http接口)等几个子包。外部请求进入系统后，由Facade组件完成入参基本校验、入参转换、服务路由以及出参转换等操作。另外，还可以承担处理登录态、鉴权以及日志等相关能力。

应用服务组件：ApplicationService

应用服务代表着用例以及系统行为，其通过委托到领域层和基础设施层(参考架构中的Gateway组件)完成用例的应用逻辑逻辑处理，可以理解为应用服务是领域层的客户端。该组件典型的职责：

从存储层加载领域对象、委托领域对象执行领域逻辑、保存领域对象

重要事件通知到外部

出入参转化适配

事务处理外部

非领域逻辑的服务调用

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。