what
Domain-Driven Design,是软件设计方面的理论性质的思想。类似的概念有Test-Driven Design.
领域其实是个泛概念，我理解的此处的领域是指业务领域，或者说是Design目标对象（也就是全局角度）下的顶级的领域。作为补充，比如基础设施，也可以称之为基础设施领域，但是在DDD中，我们将基础设施作为架构的一层，不称之为领域。
why
软件是个工程，工程有大小。和建筑工程不同，软件工程还会经常迭代，甚至是主体结构变更。
不是面向当期交付，而是面向长期迭代，DDD的思想很适合复杂业务场景的项目去实践。
when
项目交付产品，立项落地时。也就是说DDD思想不是开发岗位独有的，是面向软件工程中的全体的。比如通用语言，产品或者业务专家才能更好的定义。
where
Git仓库，文档工具吧～
who
业务专家，需求分析师，产品经理，开发经理等
how
设计阶段
事件风暴，四色建模之类的，具体自行查阅吧
代码阶段
一般是四层架构，infrastructure,domain,application,adapter(user interface).
前面三个一般没有歧义。
最后一个在命名上面的差异是有的，不同的名称定义有：api,adapter,web,user interface.但是定义都是相同的，面向外部的（也就是项目的入口调用）适配与服务提供层。web太狭隘，因为有job之类的；api现在太泛了；user interface太长，简写成interface也不准确。所以我倾向于借鉴COLA的adapter作为定义。
how much
随笔
- 软件是工程，工程有大小。大的也就是复杂度高，适合DDD思想。
- 引入领域概念，也就是为了适应变化
- DDD的design是code阶段的还是project工程早期阶段的？应该是后者
- 领域是超越了当期需求的实现的，所以面向领域的设计，会带来一些扩展性的支持
- 子域，完全依赖你对父级的定义范围。领域和子领域也是微服务拆分的重要参考。优秀的DDD应该子领域拆分的足够充分，以实现更高的内聚，以及实现更好的扩展性。
- 实体和数据库表结构的不同。实体 是 领域驱动设计里面的公共词汇，是应该跨部门沟通的（产品，测试与技术在讨论决策权上相对平等，产品为主），而数据库表结构是技术为主的。（曾经我作为产品，有时候会讨论表结构设计，就会被技术同事吐槽，确实应该引入实体的概念，在实体这层讨论）
- 通用语言是一个极好的概念，这样可以在更好的跨部门沟通，也可以很好的指引开发命名代码。核心点是一个优秀的命名还是有些难度的，尤其是行业经验不足时。
- DDD在微服务时代发扬光大，但是并不是只适用于微服务。单体应用，虽然连接层不像微服务通过网络链接，但是也可以应用DDD，这个核心是将大单体做合理的领域（模块）拆分
- 模型的定义以查询，期望呈现方式的角度考虑。事件按照业务需求动作的角度来考虑
- 从业务角度命名对象，最直接的是 业务对象entity，值对象object。当业务对象分析的足够充分的时候，发现他们可以分分合合。接近于db的对象叫成了entity，多entity合并后的更大层次的叫做了aggregate
references
mp.weixin.qq.com/s/XM3zNWRYA… 很好的DDD概念解释文章
