DDD欧洲2017:我最喜欢的三个演讲

上周我参加了DDD欧洲会议。这是第二版,它在阿姆斯特丹举行,我住在那里。我工作公司Werkspot赞助了我的入场票,所以我还想要什么?

嗯,其实我希望一个好的会议,实际上它就是!非常有经验的开发人员都发表了演讲:Vaughn Vernon,Udy Dahan,Nick Tune,Greg Young,Alberto Brandolini,Paul Raynes,当然还有Eric Evans埃里克·埃文斯(DDD祖师爷),甚至现在大约80岁的Melvin Conway梅尔文·康威!

我参加了十二次会谈,这篇文章是关于我发现更有趣的三次会谈。

考虑开发反馈环 - 梅尔文·康威
领域驱动组织设计@ FlixBus - Thomas Ploch
好的设计是不完美的设计 - 埃里克·埃文斯


考虑开发反馈环

梅尔文·康威(Melvin Conway)谈到,如果我们可以构建利用自然人的手 - 眼 - 脑反馈循环的软件,同时能让我们立即看到自己改变的结果,这将是多么酷啊。

他以陶工的手中汲取粘土作类比示例,从而设想未来的软件开发,将来有人在白板上可以简单地拖放“某个东西”或组件,然后连接它们,就能在“总是运行”应用程序中立即看到结果,该应用程序反映了白板上的内容。

他将这个范例与DDD相关联,在这个意义上,这个软件构建过程将领域专家带到动手开发过程中,领域专家将是实际的应用程序构建器,将领域概念拖放到白板中。软件构建器中的小部件/组件将取决于业务领域,并且将由域特定语言(DSL)定义。

由软件构建者使用的DSL是仍然必须由今天的软件开发人员开发的。

通过领域专家构建软件概念中,动手是演讲中最有趣的部分。然而,最酷的部分是,梅尔文·康威在20世纪90年代初就开始研究这一点了!除此之外,他实际上开发了一个应用程序,允许领域专家通过将组件拖放到白板上来构建软件!他甚至展示了几个视频,其中的流程被举例说明,使用他在20世纪90年代初开发的软件,在Windows 3.1上使用Smalltalk(在Windows 95上运行的兼容模式),在他的MacBook上的VM上运行!超酷!!

领域驱动组织设计@ FlixBus

Thomas Ploch谈到了他将FlixBus从传统组织公司转变为“复杂适应系统”的经验。

企业应用程序是一个会不断增长复杂性和不断变化的系统。在这里,DDD将发挥作用,DDD提供给我们一组实践,帮助我们构建准备改变的软件。

尽管使用了DDD,当我们有一个高度复杂的应用程序时,许多开发人员围绕其工作,并有一个持续的需求驱动来适应市场需求,该公司的传统的方法并不能适应快速变化,也不能伸缩扩展!

在这种情况下,解决方案是将组织转变为“复杂的适应系统”。他给出的类比是一群海洋中的鱼。


当威胁来临时,并没有更高的实体指导每个小鱼该怎么做,他们自己决定自己做什么,因此,群的全局形状改变,是适应其不断变化的环境。他们是自我组织的,包括分析他们的背景,他们面临的问题,并决定最佳的解决方案。然而,虽然他们是自我组织,他们都有一个共同的驱动/程序指令使他们一起工作:他们想生存!

1. 将一个刚性组织转变为一个复杂的适应系统。

为了将组织转变为复杂的适应系统,我们首先需要了解这种系统的特征,然后改变组织以符合这些特征。

2.自组织

要实现自组织公司,给予团队自主是一个关键因素。没有它,自组织是不可能的!然而,“能力越大,责任越大”,所以自主性可能只是带来混乱。

作为上述鱼群类比,企业中的自治团队需要一个简单而常见的指令来指导他们,这是一个共同的目标。他们需要共同的意义和道德,这转化为共同的愿景,这是公司文化的一部分。

这些团队特定的目标是团队的OKR的一部分,它们是更高级别战略目标的概念性解决方案。

这里要注意的一个重要概念是OKR,团队目标,由团队本身定义为一个解决方案,对更高级目标的响应(团队面对外部环境变化,就像鱼面临外部威胁)。这是一种自下而上的管理方法,而不是传统的自上而下的指令方法。在传统方法中,问题和解决方案来自组织的顶层,但是从自下而上的方法,问题来自顶层,但解决方案从组织层次结构的底部出现。

3.试验创新

组织,社会和技术变革是连续的。公司中的最高管理实体无法预测所有更改。因此,他们不能提出竞争市场所需的所有解决方案,也不能想出这么多的预期创新。适应这种持续变化的背景需要从公司的小型自主组件中产生。

复杂适应系统(公司)的自主部分(团队)能够适应变化,新问题,新挑战,需要有实验的空间。来自试验,最好的解决方案和创新将融合其中。

提供试验的空间意味着:

(1).为团队提供时间来尝试解决问题的不同解决方案;
(2).承认并接受一些试验不会为组织和产品增加任何东西,但有些却带来创新,为组织提供有价值的,甚至关键的竞争优势;
(3).以最小的摩擦反映公司在全局范围内的试验结果;
(4).放弃中央控制,用监测代替。

4.非线性

非线性意味着提供相同的输入可能导致不同的输出。

这似乎很合理,如果我们有两个独立和自主的团队,由不同的人组成,有自己的知识,经验,观点和想法,我们给他们同样的问题解决,有一个合理的机会,他们会来具有不同的解决方案,具有不同的时间框架,不同的利弊。

所有这些意味着组织作为一个复杂的适应系统,已经失去了可预测性。因此,一个想法是放弃所有的可预测性,因为它阻碍了自主性,而是使用value价值作为一种全局模式来代替它:

(1)了解公司如何产生价值;
(2)将精益价值流模式应用于自治团队。

5.秩序/混沌动力学

不幸的是,Ploch先生(发言人)没有深入复杂的适应系统的最后特点。不过,我做了一些研究,这是我想出来的...

混沌理论带给我们的一些概念是:

(1)秩序/无序

混乱不仅仅是“无序”,它探讨了秩序和无序之间的过渡,这可能以不可预见的方式发生;

(2)蝴蝶效应

“在新墨西哥拍动翅膀的蝴蝶可能在中国造成飓风”。表达这个意思的另一种方式是说,初始条件的微小变化可能导致完全不同的最终结果;

(3)不可预测性

由于复杂系统的初始条件不可能足够详细地知道,因此不可能预测结果;

(4)反馈

反馈通常会引起混乱。

将这些与软件开发相关联,我可以想象自动开发团队的背景,将我们定义为从最终用户到后端开发人员的精益价值流。

从最初的秩序状态,开发团队面临着上下文变化,该改变来自价值流中的一个提示:最终用户反馈。因此,团队进入“无序”状态,在那里它将分析终端用户反馈,建立问题来解决,提出解决方案并实现一个或多个解决方案,从而适应上下文变化并返回到有序状态。这个过程持续进行,有效地表现为一个自主和自组织的复杂适应系统。


6.让变化发生

对于传统上有组织的公司转向复杂的适应系统,有必要雇用“变革代理”,他们短期加入公司,定期地激发局部化的组织范式转换,评估和进一步改进新的工作流程。

根据Ploch先生,这些变革代理不能是公司的现任经理,至少在FlixBus的情况下他们不能。目前的管理者已经有他们的日常工作的手,并且需要人们完全专注于使改变发生。

这些改变代理可以是例如敏捷的教练或编码冠军,它们在短时间内加入团队并帮助他们以新的方式工作。然而,这些变革代理需要具有几个特征:

(1)同情

他们需要能够被容易地接受在团队的整合,他们的想法和实践被接受和拥抱;

(2)上下文更改

他们需要专注于改变他们所集成的团队的当前做法;

(3)知识渊博

他们需要具备建立新流程和动态所需的知识和经验,以及解决沿途遇到的挑战。


好的设计是不完美的设计 --Eric Evans

在闭幕主题演讲中,埃里克·埃文斯(Eric Evans)谈到: 开发人员总是陷入寻找完美的设计,完美的代码,这并不总是一件好事,因为我们需要交付!

他告诉我们,我们应该尽最大努力拥有一个好的设计,良好的代码,它甚至可以是我们的主要目标,但它不一定是我们唯一的目标,因为这将失去对我们正在构建软件的原因的看法:生意。

我还要补充一点,到底是什么是完美?完美不存在,它是相对的,这取决于谁在看和什么眼睛...我的意思是,我发现完美,一个同事可能不会找到完美的。不仅如此,我在一天中找到完美的,我可能会发现下个月甚至第二天都不那么完美。

他告诉我们,我们应该:

(1)将有界上下文与子域对齐:如果我们能!
(2)使用康威定律(Conway’s law)作为我们的优势:如果我们能!
他给出了将有界上下文与子域和组织匹配的示例。这是完美的设置。

然而,当公司决定改变其业务重点时,它将重组其人力资源等部门。即使开发团队也可能会重组,以匹配新的重点,但如果不这么做,组织将不再与代码结构匹配。

如果应用程序突然失败,“完美”的设置就没有了?那么我们该怎么办呢?我们应该重构整个事情吗?嗯,这当然是一个选择,但我们能就应该做,因为我们的主要目标是递交价值。

Eric这个演讲实际上与Rebecca Wirfs-Brock在她的题为“设计事务”的演讲中提到的一些点类似,在那里她提到我们应该是务实的,而不是教条式的,特别是在遵循软件设计原则指导时。

然而,这不是一个新的想法。 埃里克·埃文斯在2003年写的象征蓝皮书已经提到,系统的一些部分比其他部分更重要,即核心领域是系统的最重要的部分。系统的最重要的部分是我们必须努力使设计尽可能好。代码库的其他部分需要隔离,使用一些机制,如反腐败层,但不需要是我们的主要焦点。

即使在蓝皮书编辑之前的几年,我已经被教导软件开发是一个迭代的过程,在每个迭代我们改进以前的工作。 这实际上符合精益和敏捷软件开发的原则,我们应该释放小的,经常得到快速反馈,并能够准确地尽快正确地决定下一步开发工作。


DDD Europe 2017: The 3 talks I most enjoyed | @her