DDD(领域驱动设计)分层架构

简介: DDD(领域驱动设计)分层架构

一、分层架构的模型



DDD全称为(Domain-Driven Design,简称DDD),领域驱动设计

c665fe499a2745c1ab318db01da6917e.png


主要分为四层:


  • 展现层:它负责向用户显示信息和解释用户命令,完成前端界面逻辑。这里的用户不一定是使用用户界面的人,也可以是另一个计算机系统
  • 应用层:它是很薄的一层,负责展现层与领域层之间的协调,也是与其它系统应用层进行交互的必要渠道。应用层要尽量简单,不包含业务规则或者知识,不保留业务对象的状态,只保留有应用任务的进度状态,更注重流程性的东西。它只为领域层中的领域对象协调任务,分配工作,使它们互相协作
  • 领域层:它是业务软件的核心所在,包含了业务所涉及的领域对象(实体、值对象)、领域服务以及它们之间的关系,负责表达业务概念、业务状态信息以及业务规则,具体表现形式就是领域模型。领域驱动设计提倡富领域模型,即尽量将业务逻辑归属到领域对象上,实在无法归属的部分则以领域服务的形式进行定义
  • 基础设施层:它向其他层提供通用的技术能力,为应用层传递消息(API 网关等),为领域层提供持久化机制(如数据库资源)等。


二、分层架构的优点



分层架构的一个重要原则是每层只能与位于其下方的层发生依赖。它的好处是显而易见的:


首先,由于层间松散的耦合关系,使得我们可以专注于本层的设计,而不必关心其他层的设计,也不必担心自己的设计会影响其它层,对提高软件质量大有裨益。其次,分层架构使得程序结构清晰,升级和维护都变得十分容易,更改某层的代码,只要本层的接口保持稳定,其他层可以不必修改。即使本层的接口发生变化,也只影响相邻的上层,修改工作量小且错误可以控制,不会带来意外的风险。


关于分层架构的权威观点,Martin Fowler 在《Patterns of Enterprise Application Architecture》一书中给出了答案:


  1. 开发人员只关注整个架构中的某一层;
  2. 很容易的用新的方法来替换原有层次的方法;
  3. 降低层与层之间的依赖;
  4. 有利于标准化;
  5. 利于各层逻辑的复用。

     

要保持程序分层架构的优点,就必须坚持层间的松耦合关系。设计程序时,应先划分出可能的层次,以及此层次提供的接口和需要的接口。设计某层时,应尽量保持层间的隔离,仅使用下层提供的接口。


三、合理的架构分层


       

不要把与领域无关的业务逻辑放在领域层,避免领域业务逻辑被污染,保证领域层的纯洁,只有这样才能降低领域逻辑受外部变化的影响。在领域和架构模型建立后,代码模型的逻辑分层和微服务拆分要具体情况具体分析,根据自身研发和运维能力综合考虑。


3.1 项目级单应用

       

对于单应用系统的分层,遵循上述分层架构模型即可,核心领域逻辑在领域层实现,服务的组合和编排在应用层实现,两者组合形成中台,通过 API 对前台应用提供服务。


从部署和微服务拆分来讲,领域层代码部署时可能是一个微服务,也可能会根据限界上下文被拆分为多个微服务部署。应用层代码如果逻辑复杂,含较多个性业务逻辑,可以根据需要独立为微服务部署;如果逻辑简单,且领域层是一个微服务,在划分好应用层和领域层代码逻辑边界的情况下,如果符合微服务拆分原则,也可以考虑将应用层与领域层代码合并为一个微服务部署。


3.2 企业级多中台应用


对于企业级多中台应用,多个中台应用通过 API 网关对外发布 API 服务。核心域业务中台在调用支撑域和通用域中台服务时通过核心域应用层完成多中台服务的组合和编排,为前台应用提供 API 服务。核心域中台的应用层是否独立成微服务部署,需考虑的情况与单应用系统相似。


四、分析和设计模式的演进



在单机和集中式架构时代,系统分析和设计往往都是分阶段割裂进行的,容易导致需求、设计与代码实现的不一致,软件上线后才发现很多功能不是自己想要的,而且在这种模式下,软件也不能快速响应需求和业务变化。


领域驱动设计(DDD)打破了这种隔阂,它提出了领域模型概念,统一了分析、设计和开发语言和过程,使得软件能够更灵活快速响应需求变化。


软件分析和设计方法经历了三个阶段的演进:


第一阶段是单机架构时代:采用面向过程的设计方法,系统包括 UI 层和数据库两层,采用 C/S 架构模式,整个系统围绕数据库驱动设计和开发,新项目总是从设计数据库及其字段开始。


第二阶段是集中式架构时代:采用面向对象的设计方法,系统包括 UI 层、业务逻辑层和数据库层,采用经典的三层架构,也有部分应用采用传统的 SOA 架构,这种架构易使服务变得臃肿,难于维护拓展,伸缩性能差。这个阶段系统分析、软件设计和开发大多是分阶段进行的。


第三阶段是分布式架构时代:由于微服务架构的流行,采用领域驱动设计方法,应用系统包括 UI 层、应用层、领域层和基础层。这个阶段融合了分析和设计阶段,通过建立领域模型,划分领域边界,做到领域模型既设计,代码与设计保持一致。


领域驱动设计主要优势:1.业务导向。2.业务逻辑内聚,应用边界清晰。3.建立领域模型优先。4.分析、设计、代码和数据有机结合。5.代码即设计。6.扩展性好。


参考:当中台遇上DDD,我们该如何设计微服务?_架构_欧创新_InfoQ精选文章


相关文章
|
9月前
|
人工智能 运维 安全
配置驱动的动态 Agent 架构网络:实现高效编排、动态更新与智能治理
本文所阐述的配置驱动智能 Agent 架构,其核心价值在于为 Agent 开发领域提供了一套通用的、可落地的标准化范式。
4929 118
|
9月前
|
人工智能 安全 数据可视化
配置驱动的动态Agent架构网络:实现高效编排、动态更新与智能治理
本文系统性地提出并阐述了一种配置驱动的独立运行时Agent架构,旨在解决当前低代码/平台化Agent方案在企业级落地时面临困难,为Agent开发领域提供了一套通用的、可落地的标准化范式。
712 18
配置驱动的动态Agent架构网络:实现高效编排、动态更新与智能治理
|
资源调度 前端开发 算法
鸿蒙OS架构设计探秘:从分层设计到多端部署
本文深入探讨了鸿蒙OS的架构设计,从独特的“1+8+N”分层架构到模块化设计,再到智慧分发和多端部署能力。分层架构让系统更灵活,模块化设计通过Ability机制实现跨设备一致性,智慧分发优化资源调度,多端部署提升开发效率。作者结合实际代码示例,分享了开发中的实践经验,并指出生态建设是未来的关键挑战。作为国产操作系统的代表,鸿蒙的发展值得每一位开发者关注与支持。
|
11月前
|
数据可视化 IDE Java
OneCode图生代码技术深度解析:从可视化设计到注解驱动实现的全链路架构
OneCode图生代码技术通过可视化设计与Java注解驱动,实现UI到代码的高效转换,支持设计即开发、组件复用与动态加载,提升企业应用开发效率与协作能力。
OneCode图生代码技术深度解析:从可视化设计到注解驱动实现的全链路架构
|
人工智能 前端开发 Java
DDD四层架构和MVC三层架构的个人理解和学习笔记
领域驱动设计(DDD)是一种以业务为核心的设计方法,与传统MVC架构不同,DDD将业务逻辑拆分为应用层和领域层,更关注业务领域而非数据库设计。其四层架构包括:Interface(接口层)、Application(应用层)、Domain(领域层)和Infrastructure(基础层)。各层职责分明,避免跨层调用,确保业务逻辑清晰。代码实现中,通过DTO、Entity、DO等对象的转换,结合ProtoBuf协议,完成请求与响应的处理流程。为提高复用性,实际项目中可增加Common层存放公共依赖。DDD强调从业务出发设计软件,适应复杂业务场景,是微服务架构的重要设计思想。
|
调度 决策智能 知识图谱
腾讯云大模型知识引擎驱动 DeepSeek 满血版能源革命大模型:架构、优势与产业变革
腾讯云大模型知识引擎驱动的DeepSeek满血版能源革命大模型,融合了超大规模知识、极致计算效能和深度行业理解,具备智能预测、优化调度、设备健康管理和能源安全预警等七大功能模块。该模型通过分布式计算和多模态融合,提供精准的能源市场分析与决策支持,广泛应用于智慧风电场管理、油气田开发、能源市场交易等十大场景,助力能源行业的数字化转型与可持续发展。
|
数据库
分层架构
表现层(Presentation Layer):处理用户界面和用户交互逻辑。 业务逻辑层(Business Logic Layer):处理业务相关的逻辑和规则。 数据访问层(Data Access Layer):负责与数据库或其他数据源进行 [Something went wrong, please try again later.]。
|
8月前
|
Cloud Native Serverless API
微服务架构实战指南:从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic,代码为舟的星际旅人。深耕微服务架构,擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验,探索技术演进的无限可能。
微服务架构实战指南:从单体应用到云原生的蜕变之路