在日常工作中使用领域驱动设计的工作越多，就越能面对教学的难度。这是怎么回事？DDD经常被误解！我们也可以认为掌握DDD一件复杂的事情，需要掌握大量的知识和实践。让我们更具建设性，并试图找到DDD教学领域的根本问题。
DDD要旨
DDD旨在解决软件核心领域的复杂性问题。这意味着，在理想的世界中，您的软件必须与其解决的问题一样复杂。此外，您解决的问题必须是贵公司最有价值的事情。DDD提供了解决这些问题的模式（。实现DDD就是分析依赖关系。
战术模式
战术模式是我们开发人员最具体的部分，因为它是关于代码的！这是一套技术工具，可以在最重要的地方具体应用DDD方法。这些模式以与良好实践相同的速度快速发展。一个众所周知的例子是存储库模式。战术模式有助于了解如何构建业务的每个部分。
战略模式
战略模式更抽象。它们允许将域（业务）分类为子域，以便了解如何围绕它构建应用程序的上下文。每个上下文都有一个特定的通用业务语言（无处不在的语言），并使用精确的通信方式。上下文是否将一些事情强加给另一个上下文？他们共享内核吗？他们如何沟通？所有这些都可以使用战略模式捕获。它们有助于了解业务的不同部分以及它们如何相互作用。
DDD通常存在问题
自从我在2012年开始研究DDD以来，我遇到了两个经常出现的问题。首先是新人（包括我）不知道从哪里开始。他们觉得DDD很大，但参考书很吓人。这些聪明人社区中使用你以前从未听过的单词似乎很好，但你觉得处在他们周围却很愚蠢，自己很难在这个社区留下来。
第二个是大多数人（也包括我）乍一看不会抓住战略与战术模式的二元性。更糟糕的是，他们可能会专注于战术模式，因为它们看起来更具体。我们已经了解其中一些，如工厂或分层架构。结果可能是我们忽略了战略模式。
根本原因分析
在我的DDD教学领域，我认为有两个子领域：一个是战术，另一个是战略。
教授DDD的有效实施将为战略模式绘制一个有界的上下文，为战术模式绘制一个上下文。我们有几个原因来证明这种实现的合理性。
第一条：不同的语言。这两种语境具有特定的无处不在的语言。
第二条：不同的生命周期。战术模式迅速发展。来自蓝皮书大部分模式可以用更新的模式替换，如CQRS / ES或六边形体系结构。战略模式更加持久。
第三条：两种情况下的抽象级别都不尽相同。
最后：战略上下文更为重要。这是我的核心领域，是我在教授DDD时想要分享的核心价值观。我的上下文之间存在明显的依赖关系。战术模式很重要，但如果我单独教他们带来价值不大。
现在有聊“为什么DDD难以教授”答案的一部分：它混合了两个非常不同的背景。两者都很有用，一个比另一个更重要，但也更抽象，因此更难理解。
解决方案尝试
DDD作者Eric在改善行业，提供战略和战术观点方面确实雄心勃勃。我认为世界各地主要DDD会议的趋势和出现证明了他的成功。我也理解他愿意提供一些不太抽象的东西，以避免架构师患上象牙塔综合症。
不过，战略和战术模式实际上是不同的野兽。DDD两面性让人难以理解。
我们如何管理这种复杂性？这取决于上下文。但是在为新手教授DDD的领域，我会强调战略模式，主要是有界的上下文，因为这是可以导致所有其他模式的模式。然后我会解释所有行业标准的良好实践（持续集成，责任分离等等）都是实施核心领域的必要条件，DDD也将其命名为战术模式。如果试图反过来（将教导战术部分作为DDD的重点介绍）会增加了错过核心概念的风险。