前言
DDD不是一种具体的技术或框架，而是一种面向业务的设计思想和方法论。它可以与各种不同的技术和框架结合使用，例如Spring、Hibernate、Event Sourcing等。
DDD这种设计思想，出来的时间比微服务还要早。只是在早起的软件市场没有那么吸睛，一直默默无闻。直到微服务横空出世，在微服务架构里出现一个很关键的问题，就是怎么对业务模块进行拆分，软件从业人员回过头去看DDD的时候，发现其非常适合处理这个场景，这才再次进入大众的视野。
为什么要回避
在日常需求开发过程中，大多数情况下，都是比较简单的迭代。如果我们投入大量精力进行领域建模，处处贴合DDD的设计理念，那么很有可能造成延期风险，浪费人件成本。
简单列举几个不适合的场景
- 简单业务场景：如果业务场景非常简单，没有太多的业务逻辑和复杂性，使用DDD可能会增加不必要的复杂性和开发成本。
- 时间紧迫的项目：DDD需要对业务领域进行深入的理解和分析，需要花费大量的时间和精力来设计和实现领域模型，如果项目时间紧迫，可能无法承受这种开销。
- 技术水平不足：DDD需要开发人员具备一定的领域建模和设计能力，如果开发人员的技术水平不足，可能无法正确地理解和实践DDD思想。
- 不稳定的业务需求：如果业务需求经常发生变化，可能需要频繁地修改领域模型，这会增加代码的复杂性和维护成本。
- 已有成熟的业务系统：如果已有一个成熟的业务系统，使用DDD进行重构可能会带来较大的风险和成本，不一定值得投入。
结论
虽然DDD可以帮助我们构建高质量、易于维护的软件系统，但并不是所有情况都适合使用DDD，在实践中需要根据具体情况来决定是否使用DDD。
