为什么DDD难以教授?

18-11-29 banq
    

在日常工作中使用领域驱动设计的工作越多,就越能面对教学的难度。这是怎么回事?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的重点介绍)会增加了错过核心概念的风险。

​​​​​​​