福田外贸网站建设,安徽省青年企业家协会通报,酒店 网站建设 中企动力,站长工具ip地址1 背景
不同团队落地DDD所采取的应用架构风格可能不同#xff0c;并没有统一的、标准的DDD工程架构。有些团队可能遵循经典的DDD四层架构#xff0c;或改进的DDD四层架构#xff0c;有些团队可能综合考虑分层架构、整洁架构、六边形架构等多种架构风格#xff0c;有些在实…1 背景
不同团队落地DDD所采取的应用架构风格可能不同并没有统一的、标准的DDD工程架构。有些团队可能遵循经典的DDD四层架构或改进的DDD四层架构有些团队可能综合考虑分层架构、整洁架构、六边形架构等多种架构风格有些在实践中可能引入CQRS解决读模型与写模型的差异化等等。即使无法制定通用的、标准的工程应用架构但为团队制定一个遵循领域驱动设计思想的参考架构依然有价值。基于以下原因
为团队实践DDD的战术设计提供可以快速开始的工程参考参考工程大量的命名和结构决策显式的体现DDD的相关理念有利于团队对DDD的战术实现达成一致认知
同时参考架构有助于沉淀团队对领域驱动设计的一些思考和最佳实践
2 参考架构的考量因素
虽然无法制定完全通用的DDD参考架构但制定某个特定上下文下的参考架构却具有可行性和实践价值。针对于上下文的选择要尽量贴合实际的工程实践场景并考虑多维度的因素。
本文所述参考工程架构遵循以下原则
遵循领域驱动设计的本质思想充分考虑业务系统建设特点依赖最小化保持轻量
希望工程参考架构能涵盖以下范围
分离业务域与技术域 参考架构要遵循技术和业务隔离的特性可以参考多种架构风跟。业务与技术关注点的分离并不是DDD独有的特点在六边形、整洁架构、洋葱架构中都遵循了这一重要原则。多限界上下文场景 大多数团队基于DDD进行微服务拆分的时候特别是系统建设初期对单个微服务应用内的限界上下文的粒度需要权衡。由于团队组织架构因素及微服务成本问题单个应用容纳的限界上下文一般是多个(理想情况下是1:1)。这些限界上下文随着后续的逐步迭代有可能会迁移至独立应用。因此参考架构要考虑的多上下文应用场景。明确的组件、职责边界及依赖关系
支持领域报表场景 报表场景在业务系统较为常见DDD并没有体现该场景的处理方式。作为工程参考架构还是希望能够从实际业务触发体现对写模型和报表模型的显示支持
外部依赖最小化 作为一个参考架构需要排除不必要的依赖保持工程架构的轻量化
3 参考架构剖析
3.1 应用的多上下文结构 基于以上原则参考工程考虑单个应用内多上下文的场景以期在模块化和服务粒度及成本间进行权衡折衷。应用架构对多上下文的支持的逻辑示意图如下所示在解决方案域对限界上下文进行识别和划分之后基于其业务内聚性和关联性把多个上下文是现在某单个工程应用中。单个应用内的多个限界上下文间可能存在交互交互的形式可以是基于事件驱动也可以是基于进程内调用。采用事件驱动的方式上下文间的耦合性对低一些但一般需要引入事件总线的支持额外组件的引入必然会导致复杂性的上升。进程内调用则耦合性会高一些但从实现角度复杂度会低一些。具体选择哪种方式开发人员可以基于实际情况进行权衡。 需要再次说明的是这种应用架构决策是一种多因素的权衡可能与我们所了解的子域与限界上下文1:1的理想化实践不一致。但从特定的架构决策上下文来整体考量依然具有实际应用价值。
从上图的逻辑示意图我们再深入一层从分层的维度去剖析一下详细的应用架构的展现形式如下图所示 3.2 分层关注点
客户端
客户端与应用处于不同的进程是应用能力的消费端在实际项目中可能是APP端、PC端、小程序端、公众号端或三方的业务调用端等等。
接入层
接入层是外部系统与应用内部业务能力的中间层接入层是应用层对外的门面是当前应用对外暴露业务能力的入口。该层的组成可能是对外提供的HTTP接口声明、分布式定时任务调度、消息监听器、RPC服务等等。其重要职责包括对外部系统的请求进行基础的参数校验、入参适配和服务路由(转发至系一层的应用服务)以及响应数据的适配。
业务层:
该层是应用的业务逻辑所在层整个架构风格采用模块化单体风格在该层不同的限界上下文体现为不同的模块。在每个限界上下文内采用分层架构独立划分为应用层、领域层和网关层。
应用层
协调领域对象、领域服务或外部依赖服务完成业务用例该层只做能力协调不处理任何领域逻辑。
领域层
领域层是整个分层的核心与技术实现无关主要负责领域模型、领域事件、领域服务定义以及业务相关外部服务的接口抽象以及仓库的接口抽象等。
领域层与应用服务的本质区别是应用层不包含领域逻辑领域逻辑全部下沉到领域层实现。
网关层
网关层定位是应用的出口网关是应用与外部基础设施交互的适配层处理所有技术相关实现。
该组件的命名有多种方式比如有些团队将其命名为 “rpc”也有些团队将其命名为 “infrastructure”不同的命名体现了团队对其背后所表达的隐喻的决策选择。在本文的参考架构中选择了 网关-Gateway这一命名决策原因是限界上下文自身是高内聚的其与外部的交互需要统一出口Gateway所表达的网关的含义恰当的表现了这种统一出口的理念。如果Facade层是应用的北向网关则此时的Gateway则表达的是限界上下文的南向网关。
3.3 组件及依赖 从宏观的分层我们再深入一层看下每层的组件划分。如下图所示 Start组件
整个应用的启动入口、加载应用配置信息等等。
Common组件
提供在不同的限界上下文间复用的领域模型元素的抽象比如对Command、Query、Event、Entity、ValueObjec通用抽象t等。当然领域模型的通用抽象不是必须在Common组件内以提供复用也可以作为一个独立的限界上下文并以共享内核方式与其它上下文进行共享或者也可以实现为独立的jar包组件。
API 组件
RPC类型服务的接口声明组件以公司内部使用的JSF为例该组件是应用对外部系统暴露的JSF API的组件。该组件可以是独立的工程当然有些团队会将其作为一个Module放入应用工程中。
统一门面组件Facade
外部客户端触达应用系统的入口也是内部应用服务的统一门面类似于六边形架构风格下的适配器。参考架构中基于不同场景划分为 provider(RPC服务)、task(定时任务)、listener(MQ监听)、rest(http接口)等几个子包。外部请求进入系统后由Facade组件完成入参基本校验、入参转换、服务路由以及出参转换等操作。同时还可以承担处理登录态、鉴权以及日志等相关能力。
应用服务组件Application Service
应用服务代表着用例以及系统行为其通过委托到领域层和基础设施层参考架构中的Gateway组件完成用例的应用逻辑逻辑处理可以理解为应用服务是领域层的客户端。该组件典型的职责
从存储层加载领域对象、委托领域对象执行领域逻辑、保存领域对象重要事件通知到外部出入参转化适配事务处理外部非领域逻辑的服务调用
External API
应用服务的逻辑不仅仅需要协调领域层有时还需要依赖于外部的三方服务。External API 组件负责对这些外部服务进行接口声明定义不做具体实现。
应用服务组件不直接依赖这些外部服务实现而是依赖其接口抽象。同时此处的模型定义是基于该限界上下文的语义是一种对外部模型的适配。
该组件不依赖其它组件且仅被应用服务组件和Gateway组件依赖。网关组件依赖External API 组件的接口声明并提供底层技术实现应用服务组件依赖其接口并通过IOC方式将具体实现注入完成服务调用。
注意该组件所依赖的服务不涉及领域概念只是用于支撑应用服务的编排。如果是涉及了领域逻辑则对外部服务依赖的接口定义需要下沉到Domain层。
Query
Query组件解决领域相关的报表查询场景在限界上下文内作为与应用服务对等的组件存在两个组件分别负责业务的查询和命令逻辑。
虽然引入了Query组件对报表场景提供支持但没有完全的引入CQRS这一模式。在很多资料中CQRS与DDD同时提及的概率比较高因为在DDD下我们解决了复杂的面向领域的写侧模型但在报表场景下这种富领域模型有可能并不是最佳选择。如果读侧和写侧都基于统一的领域模型一般会导致领域模型的折衷设计。为了满足查询侧诉求领域模型不得不引入额外的、领域无关的属性由此造成领域模型的污染。
Domain
Domain组件是领域逻辑核心承担整个系统领域逻辑的实现其定义了领域模型、领域服务、领域事件以及仓储层的抽象。该组件不依赖其它组件(除了通用的领域模型抽象组件Common之外。
上图所体现的参考架构使用了DDD的战术设计的经典建模元素比如聚合、实体、值对象、仓储、工厂以及领域事件等。在实际落地过程中这些设计元素的抽象具有一定的挑战设计过程中需要经过不断分析、权衡和重构以完成建模这正是核心设计所在。
Gateway
网关层(有些架构下可能成为基础设施层Infrastructure)承担整个技术相关性的实现是内部应用的出口网关。
技术相关性是网关组件区别于其它组件的根本特性。在该组件内要处理技术实现的所有细节比如与外部服务、中间件、DB的交互等。同时其与Domain组件以及External API组件的接口抽象协作共同承担了系统与外部依赖间(包括外部服务以及应用依赖的中间件、DB等基础设施)的防腐层职能负责内部模型到外部模型转化、外部模型到内部模型转化以及具体交互。基于网关组件的特性也非常适合在该层做统一的外部服务数据缓存及降级熔断处理。
网关层依赖于Domain、Application Service、External API和Query组件负责上述四个组件定义的接口实现。在Gateway组件通过子包对实现进行隔离
query查询服务组件的实现externalExternal API 组件中依赖外部服务的接口实现repository仓储接口的实现
4 结语 应用架构模式是架构的重要维度之一结构不仅仅是简单的包结构和命名其传达的是一种顶层抽象背后包含了大量的实践和知识。制定符合团队情况的工程参考架构并在团队成员间达成共识非常重要。领域驱动设计并没有统一的、通用的架构试图定义标准架构是不切实际的。本文描述的工程架构只是一个参考实践过程中应该基于团队特定情况而有所差异但原则上都应该遵循业务域与技术域分离的核心理念。
关注微信公众号获取参考工程代码
