DDD名词
如果你是管项目的话，直接跟客户还有组员说，因为开发团队和客户之间经常关于名词有不一样地认识导致开发出错，所以我想统一一下名词，我这里根据客户地叫法整理了一个“名词表”，你们看看有没有意见，今后就按照这个名词来推进项目。组内有人用错名词的话就主动纠正他让他用正确的叫法。至于客户那边，如果你没法改变客户的叫法那通用语言就完全按照客户叫法来调整
至于领域专家，直接就跟客户说我需要你们那提供一两个能和我门对接，解答我们疑问的熟悉业务的人，只字别提什么“领域专家”
至于拆领域，找核心领域，子领域之类的，边界之类的的名词更是只字别提，直接就让客户给你讲讲业务范围，业务内容，然后你把业务问详细了，自己画几个图，美其名曰“业务构成图”，下次会议把疑问和图给客户看看有问题就提，没问题的话留下证据，顺便今后扯皮时还能甩锅给客户
是否适合DDD
凡事都有代价, 没有银弹, 学习一门技术, 重要的是理解它解决了什么问题, 带来了什么问题, 这样才能在项目中合理使用,DDD 适合业务特别复杂, 模型众多, 模型行为丰富, 重行为而非重数据的项目. 很多互联网公司的业务一点也不复杂, 只是规模庞大罢了, 那些项目用 DDD 可能没啥好处, 反而为了追求极致的性能, 使用事务脚本, 甚至裸写 SQL 这样反而更加合适.
Service相互依赖
如果 User 依赖 Order ，并且 Order 又反过来依赖 User ，那说明你们并没有把 User 跟 Order 解开。上面再套一层，还是没有解开，治标不治本。而且还是用毒药治那种，因为层是个很重的东西，加一层的成本是很高的。
相互依赖，一个原因是同层之间不同模块没解开造成的。对于你这个例子，根据用户 ID 获取所有订单信息，这实际上只是 Order 自身的事，跟 User 屁关系都没有。请注意用户 ID 作为不变的值，即使它是通过 User 生成的，它也不属于 User 而是属于全局，或者所有对它感兴趣的模块。
另一个原因，是根本没用好层造成的。分层既然隔离了技术，那自然要把基于技术的模块划分也给隔离了，不同层的模块划分原则是不一样的。还拿你这个例子来说，根据用户 ID 获取所有订单信息，在 UI 层往往是属于“我的……”这种用户个人资料模块的，但在业务逻辑层，或者数据模型层，它是属于 Order 模型的。
DDD好坏
理论上来说是业务解耦，配合微服务的利器。但是实际上操作下来有几个难以突破的点：
- 领域专家太少，导致很多时候开发的拆分和实际业务有分歧，不合理。
- 开发间的认知存在差距，这导致组长的能力需要更强，但我很少碰到这样能力的人。
- 业务发展太快，很多组内 ddd设计的文档没有及时更新，久而久之，变成废铁。
个人观点是，可以当做自己代码开发的规范和标杆，在团队内执行的难度很大。
转自互联网，侵删