共计 2735 个字符，预计需要花费 7 分钟才能阅读完成。
简介：DDD 是一套方法论，实际是否胜利，不仅仅是个技术问题，更是执行贯彻实施的问题。本文将就 DDD 的基本概念和 DDD 的施行进行分享。
作者 | 侧帽
起源 | 阿里技术公众号
前言
供应链商品域 DDD 实际工夫不长，在实际过程也碰到了不少问题，有些找到了答案，有些还是在摸索中。最近很荣幸受邀在供应链服务与翻新团队做了一次分享，也想在这里把一些教训和想法分享给大家，借此抛砖引玉。
DDD 是一套方法论，实际是否胜利，我感觉不仅仅是个技术问题，更是执行贯彻实施的问题。
本文内容次要有两局部，DDD 基本概念和 DDD 施行。基本概念包含通用语言、分层架构、DDD 因素、边界上下文，DDD 施行包含畛域常识提取办法、思考形式的转变，在其中会交叉一些商品案例。
一 软件复杂性是什么？
在开始 DDD 前，咱们应该先答复的一个问题，咱们为什么须要 DDD？DDD 是简单软件应答之道，所以咱们来一起看看，软件的复杂度到底在哪里？
在阿里两年，我感触很深的一个点是，咱们不能继续交付一直演进的简单软件，所以有 1.0、2.0、3.0 很多的版本，1.0 搞不上来了，开始 2.0，2.0 也搞不上来了，开始 3.0，一直循环。
阿里体系复杂度我看来是理解力、不可预测、合作力挑战三个方面。
1 理解力挑战
- 需要规模宏大，业务数量和类型一直增多，业务互相耦合，不同业务相互影响。供应链有 20 多个行业，经销、代销、一盘货等各种商业模式，有跨境进口、国内业务、国际化业务，这些纵横导致系统复杂度大幅晋升。
- 业务零碎多，边界划分不清，零碎间依赖简单。如供应链商品和共享 SELL、AIC 和 IPM，始终都有边界问题，一个大我的项目过去，边界问题就得探讨上好几天。
- 系统结构简单，因为应答高并发、高稳定性等，功能性代码与非功能性代码混合，如业务代码混杂着各种兜底逻辑、灰度逻辑、重试等等，100 行代码，可能业务代码不到 30 行。
2 不可预测性挑战
- 商业环境复杂多变，商业流程、规定多变。商业环境变动快，往年国际化、智能商业路由、考拉交融一下子都来了，在设计上很难后期都布局好。
- 变动不可预测，软件系统变动也不可预测，带来设计挑战。
3 合作力挑战
- 大部分需要横跨多个团队，需要传递低效，须要重复沟通，计划产出效率低。
- 团队角色多，业务概念多，没有对立语言，大家了解容易呈现偏差。
二 Why DDD?
DDD 设计适合的畛域模型来映射事实中的业务，来无效地解决畛域中的外围的简单问题，是对 OOAD 的扩大和延长，其解决之道：
- 分而治之，控制规模。
- 关注点拆散，应答理解力挑战，畛域模型与存储模型拆散，业务复杂度与技术复杂度拆散。
- 分层架构、拆散外围，放弃构造清晰，应答不可预测性挑战。
- 对立语言，应答合作力挑战。
三 DDD 外围
1 通用语言
通用语言是提炼畛域常识的产出物，取得对立语言就是需要剖析的过程，也是团队中各个角色就零碎指标、范畴与具体性能达成统一的过程。
畛域语言团队专有，负责解释和保护，雷同名称概念，跨出这个团队，了解能够齐全不一样。
领域专家、产品经理、开发人员独特的语言，这种语言是将领域专家和技术人员分割在一起的纽带。
在各种文档和平时沟通中，放弃概念对立，特地提一下，做一个中文对照，把概念和代码连接起来，在代码做到概念名称对立，缩小混同。
通用语言价值：
- 定义公共术语，缩小概念混同。
- 沟通达成统一的提前，打消歧义和了解偏差，晋升需要和常识消化的效率。
- 概念和代码的对立语言，连贯概念和实现。
2 分层架构
DDD 第二个外围是分层架构，拆散模型。优良的架构应该是什么样子？关注点是拆散的，能够分而治之，可测试性好。
一个人同时要做多件事件的时候，不免慌手慌脚。代码也一样，一段代码要解决各种事件的时候，也会乱成一团，所以咱们要合成开来，各个击破。
商品域畛域模型，在分层架构中的地位，如下：
- CQRS 模式：畛域模型在应用层上面，command 才走畛域模型；查问和搜寻服务不走。
- tunnel 层，对接 db、内部数据资源拜访，畛域和模型解耦，相似 DAO。
- 内部通过 SPI 和模型交互，六边形的 adapter 模式。
3 DDD 因素
1）实体：有 id，有生命周期和状态。有属性，有行为。内部事件会触发他的行为和状态变动。
实体和 vo 的辨别，vo 属性不能批改，应用 final 润饰。vo 为表白模型减负，如商品有 100 多个属性，铺平开不能体现结构化，不能体现分层分类，将类似描述性属性分组封装成一个个 vo。
2）为什么须要 service，如批量操作多个实体、跨实体操作，如商品复制，转账。
商品域的工程架构：
- serivce 职责是：实体创立，长久化，跨实体操作等。
- 不同层应用不同数据对象，tunnel 应用 dataobjects，面向存储，须要和实体互相转换。
- 实体间有关系，能够动静加载关联对象；dataobjects 只有数据，没有行为，个别也不会有关系。
4 边界上下文
- 边界 = 域或子域。
- 畛域对象在畛域内才有确切的含意。出了这个边界，不能确保还是这个含意，如苹果。
- 语言是有上下文的。
- 在不同的上下文中，职责和工作不一样。人有多个角色，在家里是爸爸、在公司是小二，职责和工作不一样。
上下文映射：
- 有了边界，那么畛域如何输入价值呢？一个齐全关闭的零碎没有任何价值。
- 罕用的形式有：共享内核，防腐层等。防腐层：商品上游提供 spi，spi 不是间接对外开放畛域模型，建设一层凋谢视图。洽购域建设防腐层，收口商品的变更对本域影响。
四 DDD 施行
1 DDD 施行的挑战
辨认和提炼畛域常识，并体现在模型代码上，强调一次“并体现在模型代码上”！
防腐，放弃模型一直演进，须要继续投入，保障 DDD 贯彻执行。
人的转变，开发思考形式的转变。
2 什么是畛域常识？
畛域常识有分层分类，平台通用商业规定，是畛域模型次要输出，商家个性化不能下沉到畛域模型层。
3 畛域常识提炼，需要和链路 5W1H 分析法
两阶段剖析：用户故事、链路和边界剖析。
- 前 3W 刻画用户故事，用户要什么，为什么要？举个例子，我作为洽购小二，须要商品库存为 0 主动下架，因为有超卖危险，客户会投诉。
- 前面的 When、Where、How 是链路和边界剖析，触发的条件是什么，要实现这个性能须要哪些域参加进来，别离提供什么能力？
通过这个剖析，获取用户需要，和全链路分工。
4 畛域常识提炼，结构化分析
- APP 层至上而下过程剖析，模型层自下而上剖析相结合。
- 能力下沉放弃模型一直演进，能力下沉规范：复用、内聚。
5 思考形式的转变
畛域驱动，在模型阶段不会关注数据设计、不会关注存储、不会关注音讯怎么发，业务和技术视角关注点做了拆散。
五 商品域实际相干
商品域工程架构：
最初，放弃模型一直演进！！！
商品域模型更新 readme，放弃模型一直演进。否则会 APP 层会越来越大，模型层越来越小，最初头重脚轻，畛域坍塌了。
原文链接
本文为阿里云原创内容，未经容许不得转载。