为什么要引进

1. DDD从软对文化，需求分析，架构模式，模块划分等方面都比较契合现有分布式微服务风格架构模式

2. 把DDD作为抽象具体化的方法论，软件思维好一点的同学具有较好的抽象能力，但也需要一种类似roudmap将思考过程进行适当规范化；对于抽象能力较差的同学，按照DDD提倡的步骤和思想就可以完成较好的设计。

3. DDD和敏捷提倡的企业文化，以及现有互联网扁平化管理比较吻合

DDD过程

1. 产品愿景：产品讲解产品要达到的水平
2. 场景分析：使用场景
3. 聚合，实体和值对象分析，分析出聚合根
4. 从聚合抽象领域，比拟拆分微服务
5. 依赖分析，分层
6. 列出领域，实体，方法列表
7.应用层代码
8.领域层代码
9.实体属性分析

为啥要说第一滴血，引入DDD确实很难，不是提倡的架构模式和代码结构等。而是在于文化铺垫准备，转变。

如果从0开始，接触起来自然容易。企业，团队，个人无论从思想，文化，做事方式都固定，越是在一类企业待时间长了，所在的能力陷阱就越深。其实能力陷阱是可以避免的，在深入的同时也需要兼顾广度，但广度的投入不能产生短期利益，涨工资。

难点1：DDD要求产品，研发经理，开发，测试，架构平等的在一块讨论。没有承认人跟人不平等，但确实有甲乙方，上下游区别，人跟人总不平等。要坐在一块平心静气讨论谈何容易。作为产品研发提出产品改进意见，只有少部分产品能平心静气接收。

难点2：讨论产品拆分，抽象，模块划分，原来各司其职，现在却要头脑风暴。软件研发长期处于瀑布模式，为啥做研发不是很关注，怎么做产品却不关心，架构方面技术架构偏重，测试也不会参与研发讨论。现在研发，测试要关注产品的愿景，产品需要参与产品抽象设计。

难点3：思维，讨论方式改变需要一个教练。要求是教练对各方面都熟悉，并具有实际项目权力的人。按照现有的产品，研发，架构，运维等组织管理模式，很难找到这类人。最好的是部落制，又具有能力的研发Leader，架构当教练，并可以得到部落长的支持。

1. 打开心扉，拥抱新思想

2. 上下游平等，提倡讨论

3. 抽象看待产品

1. 需求交底，让大家都参加，并提倡讨论

2. 涉及设计变动，增加二次交底会议

3. 需求交底用原型，仅限于需求说明

1. 根据业务抽象不同模块

2. 讨论从业务流，命令，事件几方面讨论

1. 一个对象（模块，模型）可以是一个模块，一个服务

2. 服务直接沟通就用MQ消息中间件解耦

3. 单个服务，对象，模型使用六边形模式，面向适配器

1. 三层调整为四层

2. 尽可能依赖接口，而不是具体实现

3. 根据抽象领域划分为不同的package

4. 以domain领域为中心

END