DDD中的一些基础概念 & 观点摘录

TaiKuLaHa

已于 2024-11-08 11:04:43 修改

阅读量922

点赞数 28

文章标签：后端

于 2024-11-05 23:00:35 首次发布

本文链接：https://blog.csdn.net/JH_Zhai/article/details/143532498

版权

系统复杂度来源于哪？也就是DDD存在意义

涉众域、问题域、解决方案域

聚合根 (实体间的关联关系)

防腐层 (ACL， Anti-corruption layer)

贫血模型和充血模型

------------ 推荐文档:

系统复杂度来源于哪？也就是DDD存在意义

软件系统的复杂性主要体现在三个方面。

隐晦：一是抽象层面的隐晦，抽象系统时，每个人都有自己特定的视角，你需要站在对方的角度才能明白他为什么这么做；其次是实现层面的隐晦，代码是一种技术实现，通常与现实世界的业务概念脱节，无形中增加了理解成本。
耦合：代码层面的耦合扩大了修改范围；模块层面的耦合需要跨模块/服务交互；系统层面的耦合则需要跨团队协作。从代码到模块再到系统，耦合的影响逐渐扩大，成本随之增加。
变化：业务需求决定了系统功能，不同的用户需求不一样，不同的业务发展阶段需求在不断变化，系统功能要随着业务需求的变化不断调整，这时就涉及到系统改动的频次和范围。

涉众域、问题域、解决方案域

基于涉众域拆解：也就是按用户相关性进行拆解，不同的用户使用不同的系统功能，如：CRM由市场人员、销售人员、客服人员三类角色协同完成客户触达，签约合作，售后服务三大职能，针对这三个角色建设相应的系统能力。这种拆解方式比较简单，但也存在较大的局限性，可能导致功能的重复建设。
基于问题域拆解：不同角色/用户要解决的问题是相同/相似的，可基于问题域进行拆解，如营销系统的用户包括销售、商户、销运等角色，但它核心是要解决如何发券（活动），发给谁（人群），发什么（权益）的问题。基于问题域的拆解相较于基于涉众域的拆解更加抽象，但也可能复用性不够。
基于解决方案域拆解：不同的问题，可能有相同的解决方案，如HR域有请假审批、财务上有报销流程、CRM领域存在客户资质审批，三个领域各自需要解决审批流程的问题，可以构建通用的审批流引擎来统一解决，这是基于解决方案域进行拆解。基于解决方案域的拆解最抽象，也最贴合业务本质，但也容易陷入过度设计的陷阱。

聚合根 (实体间的关联关系)

继续之前的例子，我们丰富一下订单模型：客户购买产品会产生交易订单，一个交易订单下会关联多个订单项，一个订单项包含购买的产品及数量，交易订单完成支付后会创建一个物流单。

实体关联的极简设计能够帮助我们描述现实世界事物之间的关系，并且能在一定程度上限制关系的复杂度增长，但随着业务发展，实体间的关系会越来越复杂，我们依然需要将这种关系表达在模型里，但是如果还是将这种关联表达在实体中，实体就会因各种关系带来的复杂性而膨胀，开发者也无法关注到模型的核心。当多个实体之间在某些场景下需要保持更改的一致性时，除了使用对象关联外，还可以建立一个对象组，将有着紧密关系的实体和值对象封装在一起，这个对象组就是领域模型中的聚合。

package entity;

@Entity
class TradeOrder {
    private String id;
    private String customerId;
    private Address address;
    private BigDecimal ammount;
    private Status status;
}

@Entity
class OrderItem {
    private String id;
    private Order order;
    private Status status;
    private Product product;
    private int quantity;
    private BigDecimal amount;
}

@Entity
class Customer {
    private String id;
    private Address address;
}

@Entity
class LogisticsOrder {
    private String id;
    private Address address;
    private LogisticsStatus status;
}

@Entity
class Product {
    private String id;
    private String name;
    private BigDecimal price;
}


package aggregate;


@Aggregate
class TraderOrderAggregate{
    @Root
    private TradeOrder tradeOrder;
    private Customer customer;
    private LogisticsOrder logisticsOrder;
    private List<OrderItem> orderItems;
}

@Aggregate
class LogisticsOrderAggregate{
    @Root
    private LogisticsOrder logisticsOrder;
    private TradeOrder tradeOrder;
}

@Aggregate
class CustomerOrderAggregate{
    @Root
    private Customer customer;
    private List<TradeOrder> order;
}

@Aggregate
class ProductOrderAggregate{
    @Root
    private Product product;
    private List<OrderItem> orderItems;
}

一文详谈领域驱动设计实践

防腐层 (ACL， Anti-corruption layer)

防腐层（Anti-corruption Layer）：一个上下文通过一些适配和转换与另一个上下文交互。

防腐层是一种在不同应用间转换的机制。创建一个防腐层，以根据客户端自己的领域模型为客户提供功能。该层通过其现有接口与另一个系统进行通信，几乎不需要对其进行任何修改。

在不共享相同领域模型的不同子系统之间实施防腐层（或外观或适配器层），此层转换一个子系统向另一个子系统发出的请求。使用反腐层（Anti-corruption layer）模式可确保应用程序的设计不受限于对外部子系统的依赖。反腐层（Anti-corruption layer）模式最先由 Eric Evans 在 Domain-Driven Design（域驱动的设计）中描述。

DDD领域驱动设计架构模式：防腐层（Anti-corruption layer） - Rickie - 博客园

贫血模型和充血模型

DDD中的贫血模型和充血模型都是领域模型的表现形式，但是它们在设计和实现上有着显著的区别。

- 贫血模型（Anemic Domain Model）是面向过程编程的一种表现形式。贫血模型的实体只包含数据属性和对应的 getter 以及 setter，而具体的业务逻辑交由服务层或其他外部组件负责。贫血模型将数据与操作分离，其好处是模型足够简单，开发上手比较快。团队内多人协作时，设计不容易变形。比较适合轻量级应用。但坏处是贫血模型的实体无法直接体现对应的业务能力，在复杂业务中，梳理业务逻辑将变得非常困难，不利于项目后期的业务演进。(**贫血领域对象（Anemic Domain Object）是指仅用作数据载体，而没有行为和动作的领域对象**)

- 充血模型（Rich Domain Model）则是面向对象编程的一种表现形式。充血模型的实体通常包含了数据属性以及引起属性发生变化的核心业务动作。充血模型将数据与业务能力绑定在一起，非常符合业务人员的思考方式，因此其好处是对业务非常友好，有助于更好的封装和保护领域内部的业务规则，尤其适合业务复杂的应用场景。充血模型的坏处是对业务的熟悉程度要求很高，需要在上手之初就设计好针对不同的业务场景，设计好具体的模型实体，并且规划好需要暴露哪些操作，定义哪些业务逻辑。而这些在贫血模型中则不需要，可以边实现边修改。

总的来说，贫血模型更注重简单性和易上手，而充血模型更注重业务复杂的系统开发。选择使用哪种模型取决于具体的业务需求和开发团队的技术能力。

https://blog.csdn.net/wei_7396/article/details/137372885

------------ 推荐文档:

Eric Evans.领域驱动设计.赵俐盛海艳刘霞等译.人民邮电出版社，2016. Vaughn Vernon.实现领域驱动设计.滕云译.电子工业出版社，2014.

[1]《解构领域驱动设计》– 张逸
[2]《领域驱动设计-软件核心复杂性应对之道》– Eric Evans
[3]《领域驱动设计模式、原理与实践》– Scott Millett, Nick Tune
[4]《Business Model Generation》– Alexander Osterwalder

[1] 《DDD 实战课》欧创新
[2] 《领域驱动设计》 Eric Evans
[3] 《企业应用架构模式》 Martin Fowler
[4]《实现领域驱动设计》Vaughn Vernon
[5] 《The Clean Architecture》Robert C. Martin
[6] 《The Onion Architecture》 Jeffrey Palermo
[7] What is software complexity and how can you manage it? | The Man in the Arena
[8] Bounded Context