此模式是 "遗留系统置换模式" 的一部分

创建城镇规划

确定组织的稳定部分,围绕它们构建团队和软件

此页面是一个 存根。我们打算在该材料的后续版本中对其进行全面扩展。但是,我们仍在开发这些模式,因此在继续学习如何最好地构建和解释这些想法时,模式可能会被重命名、拆分或合并。

我们经常参与软件系统的开发和维护多年,然后当面临置换系统的任务时,很难将系统分解成块,以看清全局。系统提供的业务功能的主要块是什么?

我们发现,识别业务功能的主要块的一个非常有用的方法是考虑软件参与为业务持续运营提供的不同能力。为了参考,我们将以此作为我们的工作定义

业务能力是描述业务内稳定边界的个人、流程和工具的集合。

通常,现有的遗留系统将根据系统本身包含各种不同的能力。例如,核心银行平台可能在现有系统中包含支付处理、总账和结算、客户账户等。这些能力成为我们寻求逐步安全地置换遗留系统时可以定位的关键接缝。

一旦确定了这些能力,下一步,或者你可能会认为,将是对它们中的每一个进行更详细的分析,但陷阱就在这里。遗留系统置换活动的典型失败模式是花费大量时间试图详细了解我们要构建的内容。这是一种典型的分析瘫痪形式,可以说它给 SOA 带来了一个糟糕的名声。“我们将花两年时间设计您需要置换系统的所有服务。然后我们将构建它们。”。我们希望到目前为止,我们已经吸取了教训!

那么我们该怎么做呢?作者喜欢使用城镇规划的比喻[1] 来描述我们在开始之前应该努力达到的细节级别。