5年DDD从业者分享适用于所有人的领域驱动设计

18-10-25 banq
                   

这是一位使用DDD已经五年的经验分享:

我最近一直在谈论领域驱动设计(DDD),无论是在聚会还是与客户,所以我想我会写下我的想法,看看它是否有帮助。

现在,很多人都从技术角度撰写了有关DDD的文章,这是其他人的DDD,所以我不打算这样做,而是从非技术角度讨论DDD。

解决方案始终超支

设计和构建解决方案并非易事。它永远不会顺利进行,即使它按时完成(永远不会),解决方案通常也是无效的,需要经常大幅度地改变。这导致更多的延迟,更大的预算,甚至更大的问题。

为什么这种情况会持续发生?

Complex vs Complicated

这两种复杂是有区别的。

例如,“税收”很复杂complicated,有许多交织规则和流程,但一旦你知道如何应用流程对付它们,你就解决了这个问题。它变得程序化; 不需要再考虑。按照这个过程,你会没事的。

进行企业软件开发根本不是这种复杂complicated,而是complex,有太多的未知数。换句话说,它很复杂。如果你仔细想想,这是相当明显的。如果存在一个流程就能建立企业,那么每个人都会使用这个流程,办企业就是零风险。

复杂complex问题无法控制,只能进行管理。然而,我们仍然试图将企业软件开发视为一个流程,因为我们真的希望它成为一个流程。只要看看“敏捷”*和“精益”的受欢迎程度,特别是那些以市场为导向的,以流程为导向的产品,它们会重新强化这种错觉(而且它们也不起作用)。这是一厢情愿的想法。

DDD承认这一事实,而不是专注于严格的流程和硬规则(即一种尺寸适合所有解决方案),它提出了管理和消除歧义的技术。秘密不在于一个流程,它是关于你试图解决的问题的迭代。

专注于(正确)问题

在DDD中领域,即问题及其产生的知识/活动,是其他一切的驱动因素。所有解决方案都来自问题域,因此将核心域置于中心自然会带来更好的解决方案。

例如,假设您是在线新闻商家。您的“核心”域(驱动您的业务的域)是内容生成,其他一切都是次要的。通过更快地生成更好的内容,将会不断发展您的业务。但是,如果你专注于解决调整图像大小的问题(并聘请一大堆开发人员来编写软件),那么你可能不会发展你的业务。

DDD带来了清晰度,我们能够专注的清晰度,。

与专家交谈

如果您想了解问题,那么您需要与领域专家交谈。领域专家是比任何人都更了解问题的人,他们能够告诉你什么是重要的,什么不是。

在大多数组织中,领域专家不是构建解决方案的人。DDD有助于弥合领域专家知道的内容与构建解决方案的人之间的知识差距。

这就是为什么大量的DDD技术与技术无关,而是专注于人和方法来发现复杂性和模糊性。如果我们都在同一频道上,那么前进就更容易了。

建立共识

获得清晰度的一个关键方法是建立对问题的共同理解,即领域模型。如果每个人的头脑中都有相同的模型,那么就没有歧义。它有助于我们避免过度复杂化我们的解决方案,或者更糟糕的是,构建错误的解决方案(例如上面的图像缩放器)。

统一语言

语言是DDD的核心。我们使用语言来表达我们的想法,探索问题并定义解决方案。如果领域是复杂的,那么这种语言将是丰富而复杂的,具有自己的微妙和细微差别。

问题是,您企业中的大多数人可能不会共享这种统一语言。相反,他们使用自己的语言来解决问题,这很好。然而,当两个或更多人尝试使用不同语言进行沟通而没有意识到它会出现问题,例如相同的单词但具有不同的含义。这导致歧义,并且是导致错误和误解的主要原因。

加入这种混乱中的人越多,问题就越严重。

解决办法是让每个人与领域专家密切合作,以便在业务定义语言时理解语言,并找出这些语言边界和存在位置,即何时在不同的上下文中使用这个单词(在什么时间什么场景的单词所指的意义)。这使每个人都能够进行真正沟通(即具有共享域模型),从而减少了孤岛,更好的协作产生更简单的解决方案。

解决方案反映了您对问题的理解

你构建的任何解决方案都直接反映了你对问题的理解程度。如果解决方案是好的,那么您了解您的领域,如果方案不好,说明你没有理解领域。这就是为什么快速迭代如此重要,它是关于收紧反馈循环和迭代问题,而不是在你第一次尝试时就能构建正确的解决方案(从未发生)。

通过将解决方案作为反馈,可以进行进一步的讨论,并确定您是否接近,从而产生更好的领域模型,从而产生新的解决方案,从而反馈您对问题的理解。它是循环的,它鼓励我们更好地理解我们正在做的事情,解决方案的不会像变戏法一下子有,一下子没有了。

更快的反馈才是更好的反馈

越快地测试解决方案越好,这并不意味着需要马上构建软件,如果通过构建软件后进行测试才发现背离需求,这就最昂贵的测试方式。相反,为什么不用样机甚至笔和纸原型解决方案呢?你将在最短时间内得到相同的反馈,DDD鼓励前期发现和迭代,而不是为了它而编写软件。

这并不是说DDD不会谈论很多软件,它肯定会,并且它有很多编写模式,但软件不是核心。DDD的一个常见格言是最好的软件不是软件。因为软件本身增加了复杂性,所以如果你能避免这种复杂性,你应该这样不要立即构建软件。一个优秀的DDD从业者将尝试找到问题的现有解决方案,只有在它带来最大价值的情况下才会回到定制软件上。

自我提升

DDD是关于理解和迭代问题的问题。这是循环的,这意味着DDD经常用于了解自身并改进自身。您可以想象这个反馈循环的速度有多快,DDD从业者总是在迭代,发现和命名模式和技术。随着时间的推移它会变得更好。

结论

DDD将业务及其领域置于应有的位置。我已经使用DDD 5年了,我不得不说我建立有用解决方案的能力已大大提高。这有助于我磨练我需要理解和迭代问题的技巧和技能。如果你想更好地建立解决方案,我会全心全意地推荐DDD。

 

                   

7