DDD领域驱动设计
什么是DDD？
Domin Driven Design，领域驱动设计。核心思想：通过领域驱动定义领域模型，能帮助我们确定业务边界与技术边界。
为什么需要DDD？
早期的领域模型：数据库，根据业务建立表，根据表生成对象，当业务发生变化，对应的表也需要发生变化，耦合度会随时间增加。仅仅适合瀑布式开发，需求较为恒定。而现在更多的是使用敏捷开发，版本在不断变更，也就是需求也在不断的变更，整个阶段都是位于实验阶段，没有需求是固定下来的。
微服务的拆分问题，如果使用SOA的方式，拆分的太粗，比如订单、库存、商品；如果使用更细粒度的拆分，有可能出现上百个微服务，这些服务的管理将会变得很困难。
DDD 通过确定业务边界、技术边界可以很好的解决上述问题。但是ddd通常对架构师的技术能力以及业务能力要求很高，对其他角色的要求也很高，并且需要项目具有一定的体量。
DDD的落地大致可以归结为三个步骤：
概念设计
逻辑设计
物理设计
领域驱动进行边界定义的方式共有两个部分：
战略设计，从业务角度出发，建立业务模型，划分业务边界
领域设计
子域设计
通用语言定义
限界上下文
战术设计，根据业务模型进行技术实现，完成软件开发以及落地
定义领域模型
不适合DDD的应用场景：
频繁你的进行战略改动（规模较小的场景下，老板可能频繁的更改战略目标）
战略设计
领域
一个问题域，只要在同一个领域，那问题域就相同。
比如，传统电商的领域问题可以大致分为
订单
商品
物流
绝不会涉及到的问题：
出行
政法
有可能设计到的问题：
社交电商，仍然是电商属性
子域
一个领域的业务可能过于复杂，可以将领域拆分为多个子域。比如仍然以传统电商为例，他的子域可以有：
订单
商品
物流
仓储
社交电商
根据每个领域的业务，对子域进一步进行划分：
核心子域
核心领域是指整个业务系统的核心，所有业务都要围绕着核心业务域展开。
如何明确业务核心：
精炼业务域，将某一处剔除，核心业务还能正常进行，那么经过持续精炼就可以得到核心子域
如何精炼业务域：
领域愿景模型，也就是立项的目的是什么
突出核心，留文档
内聚机制，核心业务内聚在一起
分离的核心，非核心业务与核心业务分离，比如支付和支付优惠，核心支付功能如果没有支付优惠也可以正常进行
抽象核心
举例，虽然同样都是电商领域，他们的核心子域不同：
淘宝 C2C（卖家卖出去，卖家买出来，主要做中间的交易保证）
京东 B2C（卖家是京东，主要做口碑，所以产品质量好）
苏宁 （线下选货，线上卖货）
通用子域
整个领域都能用到的子域，比如
认证授权
支撑子域
是不包含核心竞争力的功能，也不包含通用的功能，但是优势必须的支撑。以电商为例：
限时秒杀活动，支撑增加订单成交
通用语言
通用语言：能够正确的、简单地、清晰的表达业务。并让项目参与人员都能够达成共识的语言，降低人员之家能沟通成本。
限界上下文
限界上下文：用来封装通用语言和领域对象，提供上下文环境，保证在领域内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。这个边界定义了模型的适用范围。
战术设计
领域模型（domain model）
领域模型是对领域内的概念类或显示世界中对象的可视化表示，也就是业务对象模型，用于描述业务对象之间的引用关系。
业务对象主要分为三种：
业务角色，每个角色都有对应的职责，比如收银员拥有计算商品价格、收钱、找零、退换货的职责
业务实体，表示的是与业务角色交互所需要的可交付的工作、资源、事件，比如商品、发票
业务实例，表示的是一整套的业务链路，包含业务角色以及业务实体，也就是业务角色与业务实体质检室如何执行工作流程
实现领域模型的四种方式
失血模型
优点：领域对象结构简单，只包含数据层与业务逻辑层两层
缺点：肿胀的业务代码难以维护，无法应对频繁修改的需求
贫血模型
固有行为：作为业务对象，一定具有的行为，比如人一定可以走路、睡觉
非固有行为:作为业务对象，不一定具有的行为，是变动的，比如人不一定可以敲代码、弹钢琴
固有行为一般不用进入持久层，非固有行为因为具有不确定性的，那么一般进入持久层
优点：层次结构清楚，各层级是单向依赖，对于只有少量业务的应用来说，使用起来非常自然（Spring），开发迅速简单
缺点：无法应对非常复杂的业务逻辑场景，比如订单业务模型要顺带获取库存信息，而订单业务模型与库存业务模型不是包含关系
充血模型
优点：更加符合面向对象原则，业务逻辑层很薄，符合单一职责原则
缺点：职责很难划分，模型中包含大量的操作，将造成很多不必要的消耗
胀血模型
优点：建立了分层的架构，符合面向对象设计
缺点：取消了业务逻辑层，直接在Domain Object上封装事物以及授权，授权很多原本不属于这个领域对象的逻辑，增加了模型的不稳定性。
最后更新于
这有帮助吗？
