共计 2329 个字符，预计需要花费 6 分钟才能阅读完成。
- 文章内容全副来自张逸《畛域驱动设计实际（策略 + 战术）》
上文 畛域驱动实际
演进后的分层架构代码模型
需要：创立订单，发送邮件告诉，异步音讯告诉仓储零碎。
controller 是北向网关，承当与用户界面的交互，同理，如果是 dubbo，那么 dubbo 的 api 也能够视作是北向网关。
南向网关是零碎拜访里面资源用于撑持业务零碎的适配。
- 畛域层：蕴含 PlaceOrderService、Order、Notification、OrderConfirmed 与形象的 OrderRepository，封装了纯正的业务逻辑，不掺杂任何与业务无关的技术实现。
- 应用层：蕴含 OrderAppService 以及形象的 EventBus 与 NotificationService，提供对外体现业务价值的对立接口，同时还蕴含了基础设施性能的形象接口。
- 基础设施层：蕴含 OrderMapper、RabbitEventBus 与 EmailSender，为业务实现提供对应的技术性能撑持，但真正的基础设施拜访则委派给零碎边界之外的内部框架或驱动器。
限界上下文与架构
意识限界上下文
限界上下文体现的是一个垂直的架构边界，次要针对后端架构档次的垂直切分。对基础设施，框架的技术选型属于架构设计的考量范畴，但 不属于 限界上下文的代码模型，但这些基础设施，框架的抉择仍要思考他们与限界上下文代码模型的集成、构建与部署。
限界上下文之间应该严格谨守边界，防腐层（ACL）是抵挡内部限界上下文变动的最佳场合。
内部资源拜访的两种架构格调：
1: 数据库共享架构
防止不同限界上下文关联表之间的外键束缚。
应该依据畛域逻辑常识去辨认限界上下文，防止从数据库层面建模。
2: 零共享架构
将两个限界上下文共享的内部资源彻底拆散。
须要思考通信的健壮性。
须要保证数据的一致性。
运维和监控的复杂度也会回升。
代码构造
看下面这个图，applicationService 是能够不通过 domainService 间接拜访 repositories，这就阐明了 domainService 这一层更多的职责应该是畛域对象的业务编排，如果一个业务只是简略的长久化一个对象，能够不必通过 domainService，这样代码更简洁，防止通过无谓的代码档次，升高可读性。
ordercontext
- gateways
- controllers 北向网关
- OrderController
- messages dto
- CreateOrderRequest
- persistence 南向网关（长久化实现）- OrderMapper
- client 南向网关（其余微服务 / 内部服务）- NotificationClient
- mq mq 实现
- RabbitEventBus
- application 业务 service
- OrderAppService
- interfaces 基础设施，南向网关的形象
- client
- NotificationService
- SendNotificationRequest
- mq
- EventBus
- domain 畛域服务
- PlaceOrderService
- Order
- OrderConfirmed
- Notification
- NotificationComposer
- repositories 长久化的形象（长久化也是南向网关的一种，但比拟非凡，所以独立进去）- OrderRepository不同的上下文之间的通信须要进行隔离
架构格调剖析
微服务架构格调
将限界上下文视为微服务。包含用户和内部零碎在内的客户端须要通过 api Gateway 实现微服务的调用。
一个限界上下文未必肯定要部署为一个微服务，如果是提供整个零碎的公共根底性能，应该定义为公共组件。
微服务架构格调能够保障技术抉择，公布节奏的自在，但也会有分布式系统的复杂度，数据一致性和运维部署的挑战。
事件驱动架构格调
将上下文合作模式形象为公布 / 订阅事件。零碎与内部零碎之间须要引入消息中间件，以便于事件音讯的传递
CQRS 架构格调
在限界上下文层面将查问与命令分为两种不同的实现模式。零碎裸露的 API 接口须要合成为命令接口和查问接口，接口类型不同，解决模式和执行形式都不雷同。能够为 command 和 query 别离建设 module（畛域驱动设计中的设计因素），使得它们的代码模型能够单独演变，毕竟命令和查问的畛域模型是齐全不同的。甚至能够为同一个畛域的 command 和 query 各自建设专有的限界上下文。
BFF
Backends For Frontends，为前端提供的后端。能够看作是业务的聚合，用于承接 ui 和后端代码。
案例剖析
前提：不要以一个码农的视角来对待 DDD，不要以一个码农的视角来看我的项目。
如何主导一个我的项目的开发
1: 分明我的项目背景
2: 先启阶段：确定零碎范畴，明确开发指标，预感开发危险，对立技术架构，制订迭代打算。
确定零碎范畴：包含哪些做，哪些不做；有哪些利益相干方参加。
明确开发指标：包含业务指标，零碎性能指标等。
预感开发危险：包含人力资源危险，第三方反对危险，内部政策变动危险等。
对立技术架构：次要指技术架构选型，技术计划制订等。
制订迭代打算：须要有一个明确可执行的迭代打算。
先启阶段最好能有一个 mvp 打算，明确第一个正式提交版本内容。否则容易迷失在细枝末节的性能需要中。
辨认问题域：外围子畛域，通用子畛域，撑持子畛域
对立语言
编写无效用例：分为概要指标，用户指标和子性能
辨认参与者，参与者可能是人，也可能是零碎、服务或模块。
通过参与者辨认用例
应用事件风暴辨认限界上下文，防止限界上下文边界过大（2PTs 准则）
辨认上下文映射（联合用例），防止循坏依赖，如果呈现循坏依赖，可能是脱漏了限界上下文，或者上下文之间职责不清
上游调用上游
代码组织架构
