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精选文章


相关文章
|
2月前
|
人工智能 前端开发 JavaScript
前端架构思考 :专注于多框架的并存可能并不是唯一的方向 — 探讨大模型时代前端的分层式微前端架构
随着前端技术的发展,微前端架构成为应对复杂大型应用的流行方案,允许多个团队使用不同技术栈并将其模块化集成。然而,这种设计在高交互性需求的应用中存在局限,如音视频处理、AI集成等。本文探讨了传统微前端架构的不足,并提出了一种新的分层式微前端架构,通过展示层与业务层的分离及基于功能的横向拆分,以更好地适应现代前端需求。
|
24天前
|
前端开发 测试技术 数据库
DDD架构中assembler和converter的区别
在 DDD 四层架构模式中,assembler 和 converter 常用于对象转换,但两者在实际项目中的使用较为随意。本文从英文释义、语义区分和模型层区分三个方面探讨了两者的区别,建议按模型层区分,即 Interface 和 Application 层使用 assembler,Infrastructure 层使用 converter,以避免混淆和随意使用。此外,将转换代码抽离为独立方法有助于保持代码整洁和可测试性。
58 1
|
2月前
|
消息中间件 监控 NoSQL
驱动系统架构
【10月更文挑战第29天】
27 2
|
2月前
|
JSON 前端开发 Java
Spring Boot框架中的响应与分层解耦架构
在Spring Boot框架中,响应与分层解耦架构是两个核心概念,它们共同促进了应用程序的高效性、可维护性和可扩展性。
54 3
|
2月前
|
存储 前端开发 API
DDD领域驱动设计实战-分层架构
DDD分层架构通过明确各层职责及交互规则,有效降低了层间依赖。其基本原则是每层仅与下方层耦合,分为严格和松散两种形式。架构演进包括传统四层架构与改良版四层架构,后者采用依赖反转设计原则优化基础设施层位置。各层职责分明:用户接口层处理显示与请求;应用层负责服务编排与组合;领域层实现业务逻辑;基础层提供技术基础服务。通过合理设计聚合与依赖关系,DDD支持微服务架构灵活演进,提升系统适应性和可维护性。
|
17天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
15天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
16天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
35 1
服务架构的演进:从单体到微服务的探索之旅
|
14天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
37 8
|
15天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
42 5