由于市场的不断增长和数字化的不断推进，银行的 IT 变得越来越重要，并且往往是公司成功的关键因素。您肯定知道，银行的整体系统已经发展了很多年，通常无法保持下去。达到所需的反应速度。因此，微服务架构、持续交付或敏捷方法等方法在银行业越来越受到关注。如果您想进一步了解这些方法的优点，请查看 Baris Cubukcuoglu 的博客文章，主题为“银行遇见微服务和 DevOps ”。
尽管微服务理念仍然很新，但基于需求的模块化目标始终处于幕后。独立的部署单元仅代表一种功能，并且可以彼此单独投入生产。这样我们就能更快地对市场和用户的需求做出反应。
“微”到底有多小？
“微型”实际上有多小或多大？技术领域的哪一部分最适合在服务中模块化？这些是一开始经常提出的问题。可以帮助您解决此问题的一种方法是领域驱动设计。这种方法由埃里克·埃文斯 (Eric Evans) 在 2003 年的同名书中提出，并不是什么新鲜事。然而，由于微服务浪潮，他的方法日益脱颖而出。下面我想向您介绍两个在我看来在这种情况下非常重要的“工具”：限界上下文和通用语言。
作为模式的有界上下文
为了描述模型具有一定含义的区域，领域驱动设计使用有界上 手机数据库 下文的构造——即所谓的有界上下文。我所说的“模型”是指现实的表示或要使用软件解决的问题的抽象。不可否认，这乍一听起来有点复杂。然而，正如您将在下面看到的，整个事情相对简单：假设一家银行想要开发一个门户网站，用于在其“贷款销售”域内申请贷款。不同的有界上下文可以是应用、评分和借贷。每个上下文都对来自业务合作伙伴的不同信息感兴趣。
每个限界上下文都有自己的业务合作伙伴模型。
提交申请时，申请人的个人数据（例如姓名或地址）最初是相关的。
例如，在评分过程中，信用机构的负面特征（例如客户的 SCHUFA 或负债）非常重要。
发放贷款时，必须知道评分结果和债务人的账户。
因此，每个上下文都有自己的业务合作伙伴模型，这使得微服务能够独立更改。如果在授予贷款时来自其他来源的有关客户的更多信息是相关的，则只需要在此限界上下文中进行更改。申请和评分不受影响。
当然，在任何情况下总有重要或需要的核心信息。将这些数据冗余存储在不同的数据库中，这在很长一段时间内是不可取的，但在微服务架构中绝对需要实现解耦。您应该记住，根据命令查询责任分离原则 (CQRS)，只有一个服务或上下文具有写入和更改权限。
在某些情况下 - 例如出于更好的可扩展性的原因 - 有界上下文也可以分为多个微服务。然而，一个微服务永远不应该代表多个有界上下文。通过这种方式，您还可以定义领域驱动设计意义上的最大尺寸。
无处不在的语言作为部门和开发之间的共同语言
在我的示例描述中，我特意在每种情况下对业务合作伙伴使用了不同的术语。无处不在的语言 - 领域驱动设计的基石之一 - 旨在在每个人都可以理解的上下文中创建一个语言框架。在每种情况下，业务合作伙伴可能都有一个更具体的名称 - 例如申请人、客户或债务人。这些术语可以清楚地向您展示业务合作伙伴在此特定环境中的重要性。但是，您应该意识到这种语言必须随处可见。无论是领域专家、架构师还是软件开发人员 - 每个人都必须使用相同的词汇。因此，特殊术语也必须反映在代码和数据库中。
通过引入通用语言来使用统一的词汇。
另外，微服务有下限吗？
在有界上下文或通用语言定义了上限之后，就出现了一个服务可以有多小的问题。领域驱动设计还可以帮助您进行战术设计。此处提供的模式和工具可帮助您设计上下文的内部结构。所谓的“聚合”特别有帮助。您可以使用该术语来想象一组对象，这些对象在数据更改和完整性方面形成一个单元。换句话说：不应有超过总限额的交易。此外，外部接口是通过所谓的聚合根定义的。
那我们走吧？
在您自己的公司中引入领域驱动设计等方法或工具之前，您应该意识到这通常也会对组织结构产生影响。开发人员需要更多地关注主题，领域专家应该有良好的技术理解。如果不能保证这一点，或者管理层没有积极推动这一点，潜在的摩擦点可能会很快破坏预期的利润或效益。
这篇文章也出现在银行博客上。
Stephan Wies 是美因河畔法兰克福商业银行业务架构管理能力中心的高级顾问。他研究基于 Java/JEE 技术堆栈的软件系统的概念和架构。他的重点是敏捷方法和方法，例如微服务和领域驱动设计。
在我们的技术博客中，我们将带您踏上令人兴奋的 adesso 世界之旅。您可以在我们之前的博客文章中找到其他有趣的主题。
您想定期收到我们的 adesso 博客更新吗？然后只需订阅我们的时事通讯，您将通过电子邮件方便地收到我们技术博客的最新文章。