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行。
商业环境复杂多变，商业流程、规则多变。商业环境变化快，今年国际化、智能商业路由、考拉融合一下子都来了，在设计上很难前期都规划好。
变化不可预测，软件系统变化也不可预测，带来设计挑战。
大部分需求横跨多个团队，需求传递低效，需要反复沟通，方案产出效率低。
团队角色多，业务概念多，没有统一语言，大家理解容易出现偏差。
DDD设计合适的领域模型来映射现实中的业务，来有效地解决领域中的核心的复杂问题，是对OOAD的扩展和延伸，其解决之道：
分而治之，控制规模。
关注点分离，应对理解力挑战，领域模型与存储模型分离，业务复杂度与技术复杂度分离。
分层架构、分离核心，保持结构清晰，应对不可预测性挑战。
统一语言，应对协作力挑战。
1 通用语言
领域语言团队专有，负责解释和维护，相同名称概念，跨出这个团队，理解可以完全不一样。
领域专家、产品经理、开发人员共同的语言，这种语言是将领域专家和技术人员联系在一起的纽带。
在各种文档和平时沟通中，保持概念统一，特别提一下，做一个中文对照， 把概念和代码连接起来，在代码做到概念名称统一，减少混淆。
通用语言价值：
定义公共术语，减少概念混淆。
沟通达成一致的提前，消除歧义和理解偏差，提升需求和知识消化的效率。
概念和代码的统一语言，连接概念和实现。
评论列表