先说结论
业务复杂且需要长期维护的时候
首先，我们来看看什么叫业务复杂。试想一下，如果你的系统只需要对几个简单的表进行CRUD，那你不需要使用DDD，甚至都不需要开发一个应用程序，直接使用一个数据库客户端可能就能解决问题。
从经验上来看，如果你的系统有30个以内的业务操作或用户故事，那也是没有太大必要去使用DDD的。而如果超过三四十个，软件就会有一定的复杂性，这个时候就可以考虑使用DDD了。
另一方面来说，即使现在这个软件并不复杂，但后续会进行开发和扩展，在可以预见的将来，它会变得复杂，那也可以考虑使用DDD。而一些初创公司，它们或许只需要一个简单的产品来快速测试市场反馈，后续并不会继续开发和维护，而是考虑重新购买或者从头开发的话，那也没有必要浪费成本去使用DDD。
开发成员需要了解DDD，最好有落地的经验
使用DDD是有一些成本的，你的团队成员需要去了解DDD的一些基础知识，最好还需要有人做过DDD方面的实践，有一定的经验。做任何事情都需要衡量成本和收益，技术方案的选型也不例外。DDD有一定的成本，但也能带给我们显而易见的收益。
团队需要引入领域专家
要将领域专家引人你的项目恐怕也不是一件易事。但是不管有多么困难，这是你必须做的。如果你连一个领域专家都找不到，那么你无法对一个领域有深入的理解。当你找到领域专家的时候，此时开发者应该表现出主动。开发者应该找领域专家交谈并仔细聆听，然后将你们的谈话转化成软件代码。
开发周期比传统模式长
使用DDD最大的挑战之一便是：我们需要花费大量的时间和精力来思考业务领域，研究概念和术语，并且和领域专家交流，以发现、捕捉和改进通用语言。如果你想完全采用DDD来最大化业务价值，你需要做出很多努力，并且花费很多时间。事实就是这样的。