一种用于数字集成的视觉语言

在上一个博客中，我介绍了可用于标记数字集成领域中常见概念和模式的术语。我的目的是使设计师在设计和理解21世纪大多数企业中常见的高度集成，复杂的软件系统时处于同一页面。缺乏对现有系统的功能以及未来系统应如何设计的理解是软件计划太长，成本太高甚至有时完全失败的主要原因。该博客通过引入一种视觉语言将这些概念付诸实践，进一步解决了该问题。

软件系统图充满了问题。他们试图将太多信息填充到一页上。尽管如此，他们经常忽略重要信息。最重要的是，它们没有链接到软件系统本身，常常不准确并且很快就过时了。我想在将来解决最后一个问题，但是对于这个博客，我将重点介绍用一块石头杀死前两只鸟。具体来说，在设计数字系统集成时，我们如何在一页上直观地捕获正确的信息，而仅捕获正确的信息？

注意：要全面了解软件体系结构可视化领域，我建议Ruth Malan和Simon Brown的工作。

我有史以来最喜欢的书之一是Donella Meadows撰写的“系统中的思考：入门”。我在整个O'Reilly软件体系结构会议上进行了演讲。这本书中一个令人难忘的名言如下：

您认为，因为您了解“一个”，所以您必须了解“两个”，因为一个和一个等于两个。但是您忘记了，您还必须了解“和”。

多内拉·梅多斯（Donella Meadows）

当涉及到集成时，许多软件图就成为问题的核心。系统中的组件通常被过度指定，而组件之间的交互却未被充分指定。因为“系统架构设计中最大的优势在于接口”（这是我打死的另一句话），所以至关重要的是，我们应该专注于集成架构图中的线条，而不仅仅是框。在我以前的博客中，我探讨了数字系统交互的类型和模式。让我们回顾一下这些交互原语，这次是每个原语的视觉标识符。这是我们可以用来识别交互类型的图标：

我们可以使用这些简单的标点符号来标记系统图中的交互，以指示发生了哪种类型的交互。此外，我们可以使用箭头的存在和连接器的曲率来指定交互模式，而不是使用通用线来连接图中的框和形状。

我们可以使用此可视化交互元数据来丰富我们的软件系统图。这些符号使我们能够构建明确专注于架构组件之间通信的图表。专注于这种抽象级别使架构师能够解决问题空间，而不会被现阶段不相关的实现技术所干扰。这些复杂软件系统的最基本结构由基础业务功能及其交互方式定义。这种结构将对系统的可演化性及其与支持组织的关系产生最大的影响。现在，以一个例子来说明这种方法。

几年来，我一直在使用一个虚构的银行业务示例来说明域驱动设计，微服务架构和API主导的连接性中的各种技术。假设有一家银行希望提供一种付款服务，以使客户可以根据与银行的完整关系得到批准，而不仅仅是基于其卡上或帐户中的可用资金。灵活性超出了授权决定的范围，还允许他们在以后付款。因此，客户可以在当月的第9天进行无息购买，并在收到付款后的第15日从其帐户中扣除。听起来像是一种直接的服务产品，但是数字解决方案涉及相当多的复杂性。

要为这种情况实现软件解决方案，将需要许多业务功能：

客户风险评分服务，可根据客户在银行的当前状态来评估其是否值得批准。

关于这些组件是否正确以及用于生成它们的过程可能会进行大量讨论，但是此博客的重点是展示如何将它们集成在一起以提供支付解决方案。我们将其分为三个部分：为客户评分，授权交易和完成交易。

最终推动该付款服务成功或失败的因素是如何有效评估客户的授权。如果银行的评分准确，他们将大大降低由此产生的财务风险，从而以可承受的价格为客户提供服务。准确度将取决于他们可以提取到客户风险评分服务中的客户数据的数量和币种。客户的存款帐户，信用卡，信用额度，甚至他们的抵押贷款和投资中的数据都将在这里有所帮助。实际上，产品监视器服务已被专门包括来连续查询来自旧产品系统的数据，然后将其流式传输到客户风险评分服务。这两个交互如图2所示。

有了客户风险评分，让我们看一下付款请求的流向。这些请求是通过Payments API接收的。在继续之前，必须对客户进行身份验证。身份验证完成后，API组件会将付款请求发送到“付款授权”服务，该服务将查询“客户风险评分”服务以做出授权决定。在某些情况下，最终用户可能会通过多个用户启动的操作来访问API。在这种情况下，客户身份验证服务可能会发出事件，以通知感兴趣的服务-包括付款授权服务-该特定客户在线。然后，客户身份验证服务可以主动查询客户风险评分服务并缓存数据，从而减少授权请求的等待时间。付款授权流程如图3所示。

最后一组交互说明如何完成付款交易。为了支持货币的流动，支付授权服务必须发布一个事件，其中包括有关客户，交易，预期的履行数据以及目标帐户的信息。付款实现服务将其消耗和存储。每天，此服务都会创建一批批准的交易，并通过它们各自的产品代理服务发送到旧产品系统。交易履行流程如图4所示。

覆盖这三种情况，我们现在得到如图5所示的图像。不必担心使用哪种语言编写这些服务，使用什么协议来传递数据，或者系统可以驻留在哪个云平台中，我们就将这种数字化解决方案的实质。将集成系统视为一组业务功能，尤其是查看它们如何进行通信，我们现在不仅可以就应该使用哪种技术来实施解决方案，还可以针对关键的运营和组织考虑做出良好的决策。

这个博客系列将数字集成归结为第一原理。从这里可以走很多轨迹。将来的帖子将详细探讨确定组件的过程。我们还将研究交互中的组成模式。但这一切都从这里开始。了解集成的核心概念至关重要。将它们从特定于实现的实例中抽象出来是一项挑战。尽管如此，对于集成设计师而言，这样做就像数学家学习一加一的重要性一样重要。