DDD领域驱动实现概要设计

领域驱动实现架构
1.1 整洁架构

1.2 清晰架构

1.3 架构概述
不管是六边形架构、洋葱架构还是整洁架构，它们都通过将软件划分为层实现了关注点分离。每个都有至少一层用于业务规则，另一层用于接口。
这些架构中的每一个都产生了具有以下特性的系统：

框架无关
该架构不依赖于某些功能负载软件库的存在。这允许您将此类框架用作工具，而不必将您的系统塞入其有限的约束中。
可测试
可以在没有 UI、数据库、Web 服务器或任何其他外部元素的情况下测试业务规则。
用户界面（客户端）无关
用户界面可以轻松更改，而无需更改系统的其余部分。例如，Web UI 可以替换为控制台 UI，而无需更改业务规则。
数据库无关
您可以将 Oracle 或 SQL Server 换成 Mongo、BigTable、CouchDB 或其他东西。您的业务规则未绑定到数据库。
外部媒介（中间件）无关
事实上，您的业务规则根本不了解外部世界。

参考文章
2.1 洋葱架构介绍
原文：https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
翻译：https://blog.csdn.net/zeal27/article/details/75123611
2.2 清晰架构，融合DDD、整洁架构、CQRS
原文：https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/
翻译：https://www.jianshu.com/p/d3e8b9ac097b?u_atoken=c4771b22-159e-4aec-914b-fb690977cc5e&u_asession=01_Ho7-OD9n2EKaZqau0SFS_st5lCG5irENO8ktyPKbIrdZzMGt5yfuT3S1kQ6cvWKX0KNBwm7Lovlpxjd_P_q4JsKWYrT3W_NKPr8w6oU7K_3Y_59AtRkLjfiWVZgUOxWMKWrbBzYAhXhkL4v5_cjQmBkFo3NEHBv0PZUm6pbxQU&u_asig=05bMIvyBb_Ao9RS7k9PNPI-1uQ4oS_fhZS056fDlv9NcdR0NBXvRzeoL43PMD2zFSicNh14-pTLpBIwcr-XPDG4jW-RYQR_vtNYvKRgPRgyJPGGYGhbnYzfNgWCXwW_jlj7uuqH7vkD5hw4OlIEv5tc72_U2S0Fas6VoDjbQ2tLHb9JS7q8ZD7Xtz2Ly-b0kmuyAKRFSVJkkdwVUnyHAIJzWojtsFH2zKGprb3nC0ppd7e8EgbiQW8gByiSe6M9ovYdf9JIAkyKervFWgmMgV8j-3h9VXwMyh6PgyDIVSG1W8sNCoUo6NllZITOjRMJ7FTzONyJJJzAdPaC5tEw5I_912_k3P3uZiINLOhtTWx1KmAzO7mx0yt_OIQbELzc-IkmWspDxyAEEo4kbsryBKb9Q&u_aref=sGbiCN3XcFOE%2B7zB3TjH7rkHB9I%3D
2.3 领域驱动设计和CQRS落地
https://www.jianshu.com/p/Tozpp3
3. 概念
3.1 系统的基本构建块
用户接口（主动适配器）
运行用户界面所需的构建块，无论是哪种用户界面。
应用核心（用例）
系统的业务逻辑，用户界面要使用这个构建块达成目的。
基础设施（被动适配器）
这个构建块将我们的应用核心和诸如数据库、搜索引擎或第三方 API 这样的工具连接起来。
3.2 工具
远离我们系统中最重要的代码-应用核心，一些应用会用到的工具，例如数据库引擎、搜索引擎、Web 服务器或者命令行控制台(虽然最后两种工具也是传达机制)。
3.3 将传达机制和工具连接到应用核心
连接工具和应用核心的代码单元被称为适配器(端口和适配器架构)。适配器是有效地实现了让业务逻辑和特定工具之间可以相互通信的代码。
端口
在大多数语言里最简单的形式就是接口，但实际上也可能由多个接口和 DTO 组成。
主动适配器
告知我们的应用应该做什么的适配器被称为主动适配器。
被动适配器
而那些由我们的应用告知它该做什么的适配器被称为被动适配器。
4.设计总览
4.1 分层结构

4.2 依赖关系
采用依赖倒置原则
高层模块不应该依赖于低层模块，两者都应该依赖于抽象；抽象不应该依赖于细节（具体实现），细节应该依赖于抽象。

4.3 代码结构
4.3.1 领域服务

# Model 为依赖包，Project 为服务demo-api [Model] SDK
└─demo.sdk  # 领域名称.层级名称├─xxx  # 模块名称│  ├─api    # 领域api│  ├─fallback│  └─model # 接口模型│     ├─dto│     └─vo└─... demo-interface [Model] 接口层
└─demo.interfaces  # 领域名称.层级名称├─controller  # Controller│  ├─xxx        # 模块名│  └─... ├─convert     # 模型转换器（接口模型 <=> 外观模型）│  ├─xxx        # 模块名│  └─... ├─consumer    # 领域事件消费者实现│  ├─xxx        # 模块名│  └─... ├─job         # 定时任务└─... demo-facade [Model] 应用外观接口
└─demo.facade  # 领域名称.层级名称├─xxx         # 模块名称│  ├─api        # facade接口│  │  ├─command   # 命令外观│  │  └─query     # 查询外观│  ├─enums      # 枚举│  ├─event  # 领域事件接口│  │  └─xxxEventFacade.java    # xxx领域事件外观│  └─model      # facade接口模型│     ├─dto│     ├─event     # 事件模型│     └─vo└─... demo-application [Model] 应用层
└─demo.application  # 领域名称.层级名称├─service  # │  ├─xxx     # 模块名称│  │  └─xxxCmdService.java    # xxx用例服务│  └─... └─... demo-domain [Model] 领域层
└─demo.domain  # 领域名称.层级名称├─convert     # 实体转换器（外观模型 <=> 领域实体）├─entity  # 领域实体│  ├─xxx        # 子域名称（限界上下文）│  └─...├─enums   # 枚举│  └─exception  # 异常枚举├─repository  # 存储操作接口（领域模型持久化）│  ├─xxx        # 模块名称│  └─...└─... demo-query [Model] 查询层
└─demo.query  # 领域名称.层级名称├─service    # 命令│  ├─xxx       # 模块名称│  │  └─xxxQueryService.java    # xxx查询服务│  └─... ├─enums      # 枚举│  └─exception  # 异常枚举└─... demo-infrastructure [Model] 基础设施层
└─demo.infrastructure  # 领域名称.层级名称├─cache       # 缓存│  ├─xxx        # 模块名称│  └─...├─common      # 公共代码├─config      # 配置代码├─convert     # 模型转换器（存储模型 <=> 领域实体）│  ├─xxx        # 模块名称│  └─...├─db          # 数据库│  ├─xxx        # 模块名称│  │  ├─dao         # 单表数据访问封装（继承BaseService）│  │  │  ├─xxxDao.java│  │  │  └─...│  │  ├─mapper      # 数据表操作映射│  │  │  ├─xxxMapper.java│  │  │  └─...│  │  ├─po          # PO│  │  │  ├─xxxPo.java│  │  │  └─...│  │  └─...│  └─...├─enums       # 枚举│  └─exception  # 异常枚举├─publisher   # 领域事件发布者实现│  ├─xxx        # 模块名称│  └─...├─repository  # 存储操作实现│  ├─command        # 模块名称│  │  ├─xxx        # 模块名称│  │  └─... │  └─query │     ├─xxx        # 模块名称│     └─... ├─rpc         # 远程调用实现│  ├─xxx        # 模块名称│  └─... └─... demo-po [Model] 数据库模型(可包含在infrastructure基础设施层)
└─demo.infrastructure.db.po  # 领域名称.层级名称├─xxx  # 模块名称│  ├─xxxPo.java  # PO│  └─...└─...demo-service [Project] 领域服务
└─demo  # 领域名称├─config # 项目配置└─DomainxxxApplication.java  # 服务启动类

4.3.2 应用服务

app-demo [Project] 应用服务
└─demo  # 应用名称├─controller  # 接口│  ├─xxx  # 模块名│  └─... ├─model  # api模型│  ├─xxx  # 模块名│  │  ├─dto│  │  └─vo│  └─...├─service  # 服务接口│  ├─xxx  # 模块名│  └─...└─AppxxxApplication.java     # 服务启动类

DDD领域驱动实现概要设计相关推荐

DDD领域驱动设计之聚合、实体、值对象
关于具体需求,请看前面的博文:DDD领域驱动设计实践篇之如何提取模型,下面是具体的实体.聚合.值对象的代码,不想多说什么是实体.聚合等概念,相信理论的东西大家已经知晓了.本人对DDD表示好奇,没有在真 ...
DDD领域驱动设计 — 贫血模型与充血模型
文章转载来源:https://juejin.cn/post/6917125801460629518 | 前言要想深入掌握和了解 DDD 领域驱动设计的核心,那无论如何也绕不开两大较为抽象的概念-- ...
DDD 领域驱动设计：贫血模型、充血模型的深入解读！
作者:JavaEdge在掘金链接:https://juejin.cn/post/6917125801460629518 - 前言 - 要想深入掌握和了解 DDD 领域驱动设计的核心, ...
浅谈我对DDD领域驱动设计的理解
从遇到问题开始当人们要做一个软件系统时,一般总是因为遇到了什么问题,然后希望通过一个软件系统来解决. 比如,我是一家企业,然后我觉得我现在线下销售自己的产品还不够,我希望能够在线上也能销售自己的产品 ...
C#进阶系列——DDD领域驱动设计初探（五）：AutoMapper使用
前言:前篇搭建了下WCF的代码,就提到了DTO的概念,对于为什么要有这么一个DTO的对象,上章可能对于这点不太详尽,在此不厌其烦再来提提它的作用: 从安全上面考虑,领域Model都带有领域业务,让Cl ...
DDD 领域驱动设计：贫血模型、充血模型的深入解读
点击上方"朱小厮的博客",选择"设为星标" 后台回复"书",获取后台回复"k8s",可领取k8s资料 - 前言 ...
[转]浅析DDD(领域驱动设计)
最近在做一些微服务相关的设计,内容包括服务的划分,Restful API的设计等.其中比较棘手的就是Service的职责划分:如何抽象具有统一业务范畴的Model,使其模块化,又如何高度提炼并组合多模 ...
浅析DDD(领域驱动设计)
最近在做一些微服务相关的设计,内容包括服务的划分,Restful API的设计等.其中比较棘手的就是Service的职责划分:如何抽象具有统一业务范畴的Model,使其模块化,又如何高度提炼并组合多模 ...
DDD 领域驱动设计落地实践：六步拆解 DDD
引言相信通过前面几篇文章的介绍,大家对于 DDD 的相关理论以及实践的套路有了一定的理解,但是理解 DDD 理论和实践手段是一回事,能不能把这些理论知识实际应用到我们实际工作中又是另外一回事,因此本 ...

DDD领域驱动实现概要设计

DDD领域驱动实现概要设计相关推荐

最新文章

热门文章