在关于DDD的每本书和每次会议中，我都听到“DDD不是银弹”。我可能是唯一一个反思的人。因此我可能会错过一些东西。
不过，自从我开始学习DDD以来，我就在每个项目中使用它。即使在CRUD实现足够好的简单情况下也是如此。
因为了解我的领域名并能决定CRUD是否能足够好地实现。
在可能的情况下进行一到两次事件风暴会议。我尝试了解子域，看看它们是如何与我的有界上下文对齐的。我知道核心领域的知识。这是DDD的战略模式对于帮助我理解上下文至关重要，以便决定是否适合应用DDD。
当你不需要它时你需要它
我需要DDD战略模式来深入了解一个领域，以决定DDD战术模式是否与其相关并可应用？如果有的话。换句话说：战略模式对于理解任何领域都很有用，而战术模式可能与您的业务上下文不太相关。
CQRS绝对不是银弹，事件溯源，存储库，实体或价值对象也不是。但DDD在其战略方面（领域分析，有界上下文等）一直非常有用。
但有时你却不使用它。
正如Liz Keogh 在DDD Europe 2016上的出色解释。她对Cynefin框架进行了精彩的讨论。当您处于框架的混乱区域时，甚至可能无法使用战略模式或任何其他工具来分析业务，因为任何分析都是不可能的。你先行动，然后感觉并做出反应。
但作为一名顾问，在这样一个混乱的环境中，我从来没有被召唤过，或者我从未认识到它。我通常被称为在遗留系统上工作，这些遗留系统由过多的技术重点和很少的域分析构成，所有这些都在复杂的业务领域。每次DDD战略模式都能帮助我更快地做出更好的诊断。
DDD定位应该在哪里？
即使在项目的实施方面，DDD也有很多有用的东西。它并不总是关于CRUD或CQRS和事件采购。但它总是根据领域语言泛在语言命名方法，类，接口和模块。这是DDD。
如果我鼓励技术专家和领域专家之间的合作并反复工作以完善概念模型，我可以声称我正在做DDD。
如果感谢这种紧密的合作，我们可以很早发现我们想要构建的软件对业务并不重要，我仍然可以说我正在做DDD。它可以为公司节省资金，例如通过选择通用的现成解决方案，或者决定构建快速CRUD解决方案。
DDD是一种甚至可以帮助您确定何时不需要它的方法，这是DDD悖论。这反而使得它非常普遍。一种普遍的方法对我来说似乎是一颗银弹。