适用场景
理论上DDD可以指导所有业务系统的分析设计与开发。但从实践经验角度来讲，并不适合不加区分的在所有团队和业务系统建设时实施DDD，尤其是DDD推荐的CQRS架构，原因大概有以下几点：
- DDD的践行是一个知识付费的过程，学习成本巨大；
- 创建通用语言需要耗费大量的时间和精力；
- 过程中需要持续的引入领域专家（事实上很少能找到这样一个人）；
- 需要开发者转变对业务的思考方式；从技术思维转为产品思维，再从数据模型设计转为业务模型设计；
- 工程构建、架构设计、编码方式可能会与现有系统架构差异较大，这会给落地过程带来极大的挑战；
但是单从系统的角度来衡量，如果系统符下几下几点之一：
- 业务复杂：复杂到只有个别人员甚至没有人可以讲得清了，也可能是业务链路长或是链路上很多节点的逻辑都非常复杂；
- 需求变化快：包括核心需求和非核心需求，可从需求频率上来衡量；关注非核心需求主要是为了识别这些占用大量资源的非核心需求的价值到底多大；
- 支撑的垂类业务多：可从下游业务或是终端类型两个维度来评估；
目标人群
当你所在的组织愿意为知识付费时，建议可以小范围内试点DDD，然后再推广，最终效果可能不能保证但至少它可能让你的系统增加以下几点优势：1、丰富的表达力（降低认知负担提升）；2、集中的合法性校验和易测试性；3、不可变带来的线程安全；4、封装带来的柔性设计；
从众多实践团队的反馈来看，DDD并不适合所有初级人员（尤其是初级研人员）做深入研究。原因是：首先对业务的认知需要一个过程，同一业务模式在不同的场景、不同的组织中的形态差异很大，这些差异的了解和消化需要一个过程；其次DDD理论自身非常复杂，其阐述的概念理解起来非常困难，部分概念最终需要以代码的方式映射出来。前者涉及业务建模，后者关乎架构设计的合理性，这两者都属于顶层设计，一旦出现偏差纠错代价可能是非常巨大的，尤其是采用充血模型来编码DDD的团队。
在实践过程中，针对技术团队，我把DDD的目标人群分为两类：
- 高级研发：比如资深研发或系统架构师，其需熟悉业务、具备一定的业务敏锐度和很好的抽象能力、复杂软件的架构设计能力、能有时间和精入下沉到一线编写业务需求代码；
- 中级研发：在某一业务领域持续迭代需求，了解基本的架构设计原理和常见的技术中间件等，能参与到基本的概念或设计讨论中；
上述的目标人群定位可能会与DDD作者所阐述的观点相悖，实际并不矛盾。DDD强调技术架构师和领域专家的配合，尤其是领域专家是不可或缺的角色，现实情况是组织中很少存在这样的人，也不是通过高薪就可以招聘到的。最切实可行的方式是从内部培养。把有潜力的T型人才培养成n型人才，即领域专家，笔者倾向于培训有潜力的技术架构师，下面对上面的两类人群再补充两点说明。
架构师需要经常参与业务需求开发
不同企业里架构师Title的同学的工作内容可能是完全不同的，从编码参与度来讲大概可以分为三类：1、完全或很少写代码；2、只写核心代码；3、参与业务需求的开发，指导高级工程师设计开发核心代码；
怎么理解呢，首先软件架构设计的影响因素很多，一般来讲都需要适当的抽象，如果架构师只设计不参与编码，即使有很严格的过程把控，实际上都经常会出现设计与实现不符的情况；其次，在确定核心代码应该由核心研发来编写这个结论之前，我们需要回答两个问题：1、如何定义核心代码？2、核心代码开发工作量占系统开发总工作量的比例是多少？如果业务系统没有太多带有门槛的核心技术，个人还是建议架构师充当一个导师的角色同时多参与非核心代码的开发工作，这样才能结合业务并更贴地气的指导低级开发工程师。
DDD不适合初级工程师深入学习
DDD的践行是基于学习试验、质疑、再学习和重建模的过程，认知很重要。人类对事物的认知无非是基于时间和空间的，需要丰富的阅历和一个时间的跨度。
相信大家都会有这个经历，小时候调皮的时候家长会经常告诉我们：”学习是给自己学的，不是给别人学的！”或者是”别人家孩子系列”。我当时能理解的是学习好也就是期末多得张奖状或者领点铅笔这样的奖励，也只局限于这些了。如果把 ”学习” 比做DDD，笔者回忆了一下大概是这样的：
- 小学时学习好==少挨骂，家长脸上有光（逢年过节时长辈第一句话基本就是期末考第几呀）；
- 初中时学习好==重点高中，笔者所有的城市重点和非重点高中的差别就是一个天上一个地下，此时体会到了学习为自己；
- 高中时学习好==好的大学；
- 大学时学习好=好的工作和高工资；步入社会后反倒说不清学习是什么了，更多的认为学习是一种习惯、一种兴趣或是人生的修行；
回到软件设计主题上来，以商品中心为例，简单的商品中心一般只需关注类目、SKU、SPU、库存等几个关键设计即可，业务发展初期与之匹配的运营系统和客服系统一般会滞后建设，此时的系统见上图第一行部分称为1.0时代，大概表现为：
- 统一的类目树；
- 简单的运营系统，由一个团队负责所有的运营活动；
- 简单的客服系统，跨工种或兼职式的工作模式；
在1.0时代，如果负责系统实施的团队不了解运营和客服体系相关的知识，未在1.0中提前考虑和设计，那么当2.0时代到来时那么对原来系统的冲击很可能将是毁灭性的，比如考虑下列几个场景：
- 比如出现了一个叫母婴的垂直业务，这时童鞋是属于鞋类还是母婴类？
- 运营团队可能会按类目拆分为多个团队，每个团队负责特定的类目，此时类目如何与运营团队匹配？多类目设计还是采用与运营类目映射设计？
- 专业的客服团队，多维度的任务分派机制，是否也要设计一个客服类目呢，如果不是那么原类目如何匹配？
上述的例子中1.0时代影响系统建设的最重要的技术成本，但到了2.0时代在架构上就要考虑组织架构、跨部门沟通协作、系统集成、甚至KPI考核等因素。多数年轻的技术人员对这些隐性的成本和风险是没有感知的。
对DDD的应用也是，如果认知不够或是不统一，很容易出现套用的现象发生，就好比初学23种设计模式时，咋看咋明白咋用咋别扭，纠结根本就是认知不够。建议初级工程师在没有足够积累的时候尽量采用跟随的策略参与到DDD的建设中。
实施原则
- 结合scrum模式，在持续重构和迭代过程中演进式设计；
- 重构和迭代是以不断试验及协作学习中的【知识付费】为基础的；
- 基于项目的时效等特性，所采用的简单设计、基本设计、复杂设计都要和项目性质匹配；
- 设计不仅仅指让软件运行的更好，它更代表团队的工作方式；
- 团队中要有一种通用语言ubiqutious language；
- 抓住最有价值的核心域，不要把设计做成一个大泥球；
实施步骤
下面是实践积累的经验步骤（本文档中存在先后顺序的列表会以数字方式做为列表符，没有先后顺序的列表会以方块的形式做为列表符），仅供参考：
- 寻找契机，DDD实践势必挤占业务研发资源，如果不能挂靠到公司战略上那么DDD实施本质来讲还是技术的事，所以需要做好价值分析，并寻求上层和业务等协作团队的支持与配合；
- 圈定MVP人群，提前组织学习，并坚持定期培训；
- 目标选择上，最好以一个新系统来实施，然后再选择老系统改造；因为复杂的老系统的改造可能是一个充满风险的长尾操作；
- 过程中要落实一些技术规范，这些规范尽量用架构或技术手段来约束，规避契约模式的过程不可控；
老系统改造
如果DDD能在团队中得到推广，实施对象往往以老系统居多，就意味着对原有系统做重构（而且是动了底层模型），这个重构往往是即不能影响线上稳定运行也不能影响日常的业务需求迭代。
为了降低重构风险以及改造成本，在实践DDD之前，首先要对老系统进行隔离改造，下面是笔者在老系统改造过程中积累的一些经验，详细包括：
- 代码隔离：可按原分类逻辑，把属于同一功能模块的代码整理到一个根package包下，如果遇到平行调用或是公用逻辑，可以复制代码放在调用类中变成一个private方法；尽量做到每个根package相互独立，即所谓的逻辑分离；
- 工程删减：工程代码多是以project和moudle方式组织的，moudle的分类方法有很多种，按调用层次、按功能、按部署分moudle的都有。笔者建议合并按功能分类的moudle，只保留调用层次上的moudle和部署moudle；
- 架构层次：现在的系统架构多数是以MVC这样经典的分层设计为主，分为严格和非严格分层设计，层次调用上分为依赖抽象、依赖实现、还有混合依赖模式的。建议按分层职现尽可能的梳理成严格分层模式，然后再按调用方式统一调用依赖模型，尤其要消除混合模式，要不依赖抽象，要不依赖实现调用；
经过上述改造后，老系统在X（功能模型）和Y（架构层次）两方面都做到了隔离，如果做的彻底，我们的系统架构现在应该是一个网状结构。接下来就可以应用DDD设计方法论进行重构了。
过程中的坑
没有一种设计可以适配所有的场景，DDD也是如此。在践行时讲究的是变通而不是硬套，以下是实施DDD以来踩过的一些坑，希望牢记：
- 无差别是全面采用DDD进行战术建模；因前期投入成本比较大，建议只做核心域的DDD实践，用另一种架构实现通用和支撑域，同时做好ALC；
- 要基于竞争优势定义核心域，而不是单从业务主体定义核心域；比如JD VS TB，物流就是JD的核心域（竞争优势），而交易不是；同时售后也可能是JD的核心域，因为相比TB没有竞争优势，但对用户购物体验很重要需要超越上来；
- 领域模型不是完整映射现实，需要根据业务和增删，甚至会超出现实；模型的设计要用发展的眼光来看，因为模型会迭代，每次迭代更改的代价往往非常巨大；
- 上下文中的模型除了概念一致，还要保持行为和职责的一致，需要同时满足以上三点，才能同在一个上下文中，否则最好剥离出去；组织的结构可能决定了系统的设计；
- 事前准备好测试数据和自动化回归机制，因为老系统大规模的重构等价大规模的BUG引入；
