DDD欧洲会议纪要 - 第一天 — Matthias Noback

19-02-01 banq
                   

Eric Evans:主题演讲(“上下文中的语言”):

从基础知识开始(单词在上下文中有意义;当我们明确指出这个上下文的边界时,我们最终得到一个有界的上下文),Eric讨论了两个主要的主题:大泥球,以及微服务上下文中有界的上下文。

banq注:语言单词在不同上下文有不同意思,语义取决于上下文,这是维根斯坦语言游戏的一部分,比如以下中文老外就看不懂:

  1. 冬天:能穿多少穿多少;夏天:能穿多少穿多少。
  2. 剩女产生的原因有两个,一是谁都看不上,二是谁都看不上。
  3. 单身的原因:原来是喜欢一个人,现在是喜欢一个人。
  4. 两种人容易被甩:一种不知道什么叫做爱,一种不知道什么叫做爱。
  5. 想和某个人在一起的两种原因:一种是喜欢上人家,另一种是喜欢上人家。
  6. 女孩约的男孩迟到了有两个原因:1.睡过了。 2.睡过了。

遗留应用程序总是以负面的方式构建,好像标记上遗产后就可以摆脱了,但我个人非常喜欢这些遗产,始终存在解决遗留代码的冲动。 Bubble Context (PDF)可以在现有模型旁边创建行之有效的新模式。要在新模型和旧模型之间保持安全缓冲区,您可以构建反腐败层(ACL)。Eric提到的一个有趣的事情是缓冲区在两个方向上工作。ACL还允许旧模型保持运行,而不会受到Bubble Context中正在发生的所有新事物的干扰。

鉴于有界上下文可能与或不与实际的子域对齐,很可能遗留上下文实际上是个大泥球,具有统一模型,并且只是在许多意大利式面条线之间编织入了大量的领域知识。然而,即使它是一团糟,并且每天使用它变得越来越困难,它仍然可以称为“成熟的生产环境”。问题是:它是否仍然符合业务观点?如果是这样,我们可以通过执行本地重构来提高可维护性和变更成本。如果不是,那么改变任何东西都会非常困难。如果模型的基本假设发生变化,返工将非常昂贵。

事实上,对于我目前正在进行的项目,我们正在研究一个模块(或上下文)是否需要一些重构,因为技术上已经很难使用它了,然而,该公司仍对现状非常满意,并且它对其流程至关重要。

可以在遗留代码区域中使用的一种重要的领域驱动方法是分析不同的子域,并找出哪些是通用的,哪些是业务的“核心”。例如,在上述项目中,实际上有两个候选者用于上下文级别的改进。一个与Sales(这是此财务应用程序的核心)有关,一个与Addressbook记录相关(它非常支持Sales部分)。人们可以说它甚至是通用的,因为现成的解决方案可能更可取。我们也不想在那里花费大量的设计或开发工作。

Eric提到术语“古雅上下文Quaint Context”作为人们认为“遗留”的上下文的合适名称。它可能使用过时的技术,并且变得难以维护。不可能在那里做出重大改变(如上所述,因为这些基本假设不容易改变),所以另一个好名字可能是“Patch-by-P​​atch Context”。

使用微服务架构,处理遗留环境的另一种选择成为Eric称之为“暴露的遗留资产”(又一个不错的术语!)。这将是一个遗留应用程序,它通过生成对该环境中的实际微服务有用的消息,开始适应微服务环境。例如,数据库触发器可用于生成事件。外部事件本身不必像导致它们的内部事件那样低级。

Eric谈到微服务架构的其他几个有趣的方面,但我想在这里简要提一些其他相关的想法。Eric回顾了15年的领域驱动设计,并提出到现在我们可能需要定义DDD本身。他不希望DDD只是一个俱乐部,但要求知识分子的诚实。如果您尝试应用DDD并以某种方式失败,您应该分享这个故事。如果你对DDD的某些方面持怀疑态度,请谈谈它。我喜欢它归结为如何专注于核心领域,共同探索模型,以及在明确有界的上下文下讲无处不在的语言。太好了!

Rebecca Wirfs-Brock:开发您的设计启发式工具包:

这是一个访问受限的研讨会,所以我很幸运能参加。Rebecca 曾在会议的前一版中谈过启发式,这引发了我对这个想法的兴趣。研讨会是关于它背后的过程。它有一些有趣的指针,比如关于概念PDF和Billy Vaughn Koen的一本书:方法的讨论。绝对要检查的东西!

Rebecca 将“启发式”定义为一种实用的方法,一种经验法则。当您发现在某种情况下最有效的方法时,启发式算法是您随时间收集的内容。它们可能暗示如何解决设计问题,或者如何找出下一步该做什么,或者如何与某些事物联系起来。

软件开发中的一个困难情况的例子是当你遇到“臭”代码时。出了点问题。它需要修复,但是:你现在这样做吗?决不?只在某些情况下?有人可能会说:如果你发现问题,请修复它。另一个人会说:如果没有破坏,请不要修理它。或许:永远不要修复它。不要碰任何东西,因为它可能会破裂。

在这个问题上我们都有一些直观的方法,我发现它非常有趣:

  1. 这种方法随着时间而变化。
  2. 很多人会有很多不同的方法。

Rebecca 建议保留一份期刊,描述和反思你如何实际解决设计问题。我们根据一些固定的食谱练习收集启发式方法。这是一个例子:

问题:每当遇到代码有味道时,我应该修复代码味道吗?

启发式:只有在您处理代码时才能修复它们。

示例:如果您只是阅读代码,请不要改进它。如果您因为请求了新功能而潜入并进行更改,或者必须修复错误,请添加测试并修复坏味。

您可以根据自己的工作收集这些内容,在与想要学习的其他人交谈时,您可以开始收集更多内容。当发现其他人使用哪种启发式方法时,有助于挑战他们。提出问题,找出异常,应该考虑的许多其他微妙的事情,等等。

 

                   

4