六边形/洋葱/DDD

订阅

其他上下文

Mysql

特点：1.外层依赖内层使得依赖更合理。端口就是接口，依赖接口变成。保证了应用和实现之间的隔离。2.可测试更好。

2）应用层

值对象

基础服务

数据发送

4）基础设施层

业务DB

Infrustructure

身份认证

事件表

面向用户访问的数据入向接口，可按照不同场景提供不一样的用户接口实现。面向Web的可使用http restful的方式提供服务，可增加安全认证、权限校验，日志记录等功能；面向微服务的可使用RPC方式提供服务，可增加限流、熔断等功能。

事件处理

DDD架构

File System

聚合

事件发布

消息中间件

webService

领域事件

假设我们正在开发一个电子商务网站，名为“ShopX”。我们的目标是创建一个高度可扩展的应用程序，能够处理成千上万的并发用户和巨大的交易量。以下是一些可能的领域概念和业务规则：订单(Order)：代表客户提交的订单，包括订单号、订单日期、总金额等信息。商品(Product)：代表商店销售的商品，包括名称、描述、价格等信息。库存(Inventory)：代表现有库存，包括每个产品的数量和所在位置。购物车(Shopping Cart)：客户将要购买的商品列表，包括每件商品的数量。支付(Payment)：代表客户的支付方式和支付状态。用户(User)：代表网站上注册的用户，包括用户名、密码、地址等信息。根据以上概念和规则，我们可以按照DDD的思想进行以下设计：领域对象：Order：代表一个订单，包括OrderLine(订单行项目)对象列表。OrderLine：代表一个订单项，包括Product(商品)对象和数量属性。Product：代表一个商品，包括Price(价格)和Description(描述)属性。Inventory：代表一个库存，包括ItemId和Quantity(数量)属性。ShoppingCart：代表一个购物车，包括CartItem(购物车项)对象列表。CartItem：代表一个购物车项，包括Product对象和数量属性。Payment：代表一个支付，包括PaymentMethod(支付方式)和Status(状态)属性。User：代表一个用户，包括Username(用户名)、Password(密码)、Address(地址)等属性。领域服务：ProductService：提供商品相关的服务，如查询商品信息、更新库存等。OrderService：提供订单相关的服务，如创建订单、更新订单状态等。PaymentService：提供支付相关的服务，如处理支付请求、更新支付状态等。领域事件：OrderCreatedEvent：表示一个订单被创建的事件。OrderUpdatedEvent：表示一个订单被更新的事件。PaymentCreatedEvent：表示一个支付被创建的事件。PaymentUpdatedEvent：表示一个支付被更新的事件。数据持久化：OrderRepository：负责保存和检索Order对象。ProductRepository：负责保存和检索Product对象。InventoryRepository：负责保存和检索Inventory对象。ShoppingCartRepository：负责保存和检索ShoppingCart对象。PaymentRepository：负责保存和检索Payment对象。UserRepository：负责保存和检索User对象。以上是一个简单的示例，实际上在实现中还需要进行更多的细节设计和优化，但这个模型可以为您提供一个基本的方向。在DDD中，应该专注于业务规则和领域概念，并将其转化为面向对象的设计模型。

应用服务

事件监听

应用层

用户接口层

事件总线

微服务协议适配器

DTO转换

ApplicationServices

1.共享事件库

DBRepository

远程接口

三方工具

事件数据发送

领域层的上层，依赖领域层，是各聚合的协调和编排。原则上不包括任何业务逻辑，以较粗粒度的封闭为前端接口提供支持。除了提供上层调用外，还可以包括时间和消息的订阅

共享资源

外部服务接口

外部微服务B

           聚合

3）用户接口层

DB

Applicationi Core

领域服务

User Interface

消息适配器

Tests

...

测试XML等

外部微服务A

Framework

基础设施层

六边形架构

微服务内部

实体

入口适配器

出口适配器

MockRepository

2.共享业务库

QAAPI

缓存

洋葱架构

数据库

领域层

MQ

又称为“端口和适配器模式”

消息监听

数据的出向接口，封装数据调用的技术细节。可为其它任意层提供服务，但为了解决耦合的问题采用了依赖倒置原则。其它层只依赖基础设施的接口，于具体实现进行分离

聚合B

业务表

DomainModel

Web API

Http协议适配器

先从业务逻辑开始。设计时不考虑数据库的实现。领域层聚焦业务对象的业务逻辑实现，用于表达业务概念、业务状态和业务规则。

Redis

领域事件=事件发布+事件存储+事件分发+事件处理

消息队列

发布

聚合A

事件DB

聚合根

防腐层

CacheRepository

1）领域层

外部微服务N

特点：1.围绕独⽴的领域模型构建应⽤2.内层定义接⼝，外层实现接⼝3.依赖的⽅向指向圆⼼（注意：洋葱架构提倡不破坏耦合⽅向的依赖都是合理的，外层可以依赖直接内层，也可以依赖更⾥⾯的层）4.所有的应⽤代码可以独⽴于基础设施编译和运⾏

用户界面

Domain Services

搜索引擎