ToB企服应用市场:ToB评测及商务社交产业平台

标题: DDD架构 [打印本页]

作者: 不到断气不罢休 时间: 2024-6-13 21:14
标题: DDD架构
一、DDD架构相干概念

来自小张的博客
1.1什么是DDD

范畴驱动设计，即Domain Driven Design（DDD）。
DDD是一套完整而系统的设计理论与方法，使得你的设计思路能够更加清楚，设计过程更加规范。
DDD 善于处理与范畴相干的拥有高复杂度业务的产品开发
总之,DDD是专门为办理复杂性而诞生一套完整的理论方法
DDD落地实现离不开Clean架构、六边形架构、CQRS、Event Source等思想。
1.2 DDD相干概念

范畴：用来限定业务界限和范围
子域：范畴进一步分别就是子域
焦点域：焦点域应该就是公司的重要业务，简单来说就是公司最盈利的业务。
通用域：见明知意，就是不管什么业务，都会涉及到比较通用的范畴，例如登录、授权、网关等。随着业务的发展也可能发展成为焦点域。
支持域：支持业务系统正常运行的业务，但是不处于焦点地位。优先级较低，固然随着业务的发展也可能发展成为焦点域；例如：物流对于淘宝来说一开始就是支持域，厥后发展成为了焦点域
通用语言：在事件风暴过程中，通过团队交流告竣共识的，能够简单、清楚、准确描述业务涵义和规则的语言
限界上下文：通用语言和范畴对象，提供的上下文环境，包管在范畴之内的一些术语、业务相干对象等（通用语言）只有唯一一个确切的寄义。范畴界限就是通过限界上下文来定义的，是分别微服务的重要依据。
聚合：由业务和逻辑紧密关联的实体和值对象组合而成的。聚合是数据修改和恒久化的基本单位，每一个聚合对应一个仓储，实现数据的恒久化特点：高内聚、低耦合，它是范畴模子中最底层的界限，可以作为拆分微服务的最小单位
聚合根：如果把聚合比作组织，聚合根则是组织的负责人，聚合根也叫做根实体，它不仅仅是实体，还是聚合的管理者
实体：有 ID 标识，通过 ID 判断相等性，ID 在聚合内唯一即可。
值对象：无 ID，不可变，无生命周期，用完即扔
范畴事件：范畴事件是范畴模子中非常重要的一部分，用来表示范畴中发生的事件。一个范畴事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环，可以通过event，mq等实现，达到终极同等性，和解耦目的

跨多个实体的业务逻辑通过范畴服务来实现，跨多个聚合的业务逻辑通过应用服务来实现
二、DDD架构

DDD 分层架构就是优化后的四层架构。从上到下依次是：用户接口层、应用层、范畴层和根本层。
2.1 DDD分层架构：

2.1.1 DDD封层架构

用户接口层：负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化测试和批处理脚本等等。
应用层：很薄的一层，理论上不应该有业务规则或逻辑，重要面向用例和流程相干的操作。但应用层又位于范畴层之上，因为范畴层包罗多个聚合，所以它可以协调多个聚合的服务和范畴对象完成服务编排和组合，协作完成业务操作。此外，应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。
范畴层：是实现企业焦点业务逻辑，通过各种校验手段包管业务的正确性。范畴层重要体现范畴模子的业务能力，它用来表达业务概念、业务状态和业务规则。范畴层包罗聚合根、实体、值对象、范畴服务等范畴模子中的范畴对象
根本层：是贯穿所有层的，它的作用就是为其它各层提供通用的技能和根本服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。比较常见的功能还是提供数据库恒久化。

DDD 分层架构有一个重要的原则：每层只能与位于其下方的层发生耦合。
2.1.2 DDD架构与MVC架构

DDD 分层架构中的要素实在和三层架构类似，只是在 DDD 分层架构中，这些要素被重新归类，重新分别了层，确定了层与层之间的交互规则和职责界限

2.2 整齐架构(洋葱架构)

在整齐架构里，同心圆代表应用软件的不同部分，从里到外依次是范畴模子、范畴服务、应用服务和最外围的容易变化的内容，比如用户界面和根本办法。
整齐架构最重要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是焦点能力。外圆代码依赖只能指向内圆，内圆不必要知道外圆的任何环境。

在洋葱架构中，各层的职能分别：
范畴模子实现范畴内焦点业务逻辑，它封装了企业级的业务规则。范畴模子的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。
范畴服务实现涉及多个实体的复杂业务逻辑。应用服务实现与用户操作相干的服务组合与编排，它包罗了应用特有的业务流程规则，封装和实现了系统所有用例。
最外层重要提供适配的能力，适配能力分为自动适配和被动适配。自动适配重要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配重要是实现焦点业务逻辑对根本资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。
红圈内的范畴模子、范畴服务和应用服务一起组成软件焦点业务能力。

2.3 CQRS架构(更改查询隔离架构)

CQRS — Command Query Responsibility Segregation，故名思义是将 command 与 query 分离的一种模式。
command ：命令则是对会引起数据发生变化操作的总称，即我们常说的新增，更新，删除这些操作，都是命令。
Query：查询则和字面意思一样，即不会对数据产生变化的操作，只是按照某些条件查找数据。

实用场景：
查询数据复杂
– 写入数据通常聚焦在一个范畴或聚合内
– 查询的数据结构复杂，跨域多个聚合的数据组合
读写分离
– 读数据比写数据频繁的多
– 通过读写分离进步系统的性能，可以机动的使用不同的数据库技能实
缺点：
数据同等性
– 数据的写入与事件触发更新不在同一个事件
– 两份数据可能异构存储怎样包管终极同等性
根本实行不成熟
– CQRS大多是通过手工的读写分离实现
– 缺少具有统治地位的成熟框架

2.4 六边形架构(端口适配器架构)

六边形架构的焦点理念是：应用是通过端口与外部举行交互的
下图的红圈内的焦点业务逻辑（应用程序和范畴模子）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器举行交互。它办理了业务逻辑与用户界面的代码交织题目，很好地实现了前后端分离。六边形架构各层的依赖关系与整齐架构一样，都是由外向内依赖。

六边形架构将系统分为内六边形和外六边形两层，这两层的职能分别如下：红圈内的六边形实现应用的焦点业务逻辑；外六边形完成外部应用、驱动和根本资源等的交互和访问，对前端应用以 API 自动适配的方式提供服务，对根本资源以依赖倒置被动适配的方式实现资源访问。六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换。这就使得应用程序能够以同等的方式被用户、程序、自动化测试和批处理脚本使用。

这三种架构模子的设计思想微服务架构高内聚低耦合原则的完美体现，而它们身上闪耀的正是以范畴模子为中心的设计思想，将焦点业务逻辑与外部应用、根本资源举行隔离。

红色框内部重要实现焦点业务逻辑，但焦点业务逻辑也是有差异的，有的业务逻辑属于范畴模子的能力，有的则属于面向用户的用例和流程编排能力。按照这种功能的差异，我们在这三种架构中分别了应用层和范畴层，来承担不同的业务逻辑。
范畴层实现面向范畴模子，实现范畴模子的焦点业务逻辑，属于原子模子，它必要保持范畴模子和业务逻辑的稳定，对外提供稳定的细粒度的范畴服务，所以它处于架构的焦点位置。
应用层实现面向用户操作相干的用例和流程，对外提供粗粒度的 API 服务。它就像一个齿轮一样举行前台应用和范畴层的适配，接收前台需求，随时做出响应和调整，尽量避免将前台需求传导到范畴层。应用层作为配速齿轮则位于前台应用和范畴层之间。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)