Big Database

当然，在任何情况下总有重要或需要的核心信息。将这些数据冗余存储在不同的数据库中，这在很长一段时间内是不可取的，但在微服务架构中绝对是可取的，以实现解耦。您应该记住，根据命令查询责任分离原则 (CQRS)，只有一个服务或上下文具有写入和更改权限。

在某些情况下 - 例如出于更好的可扩展性的原因 - 有界上下文也可以分为多个微服务。然而，一个微服务永远不应该代表多个有界上下文。通过这种方式，您还可以定义领域驱动设计意义上的最大尺寸。

在我的示例描述中，我特意在每种情况下对业务合作伙伴使用了不同的术语。无处不在的语言 - 领域驱动设计的基石之一 - 旨在在每个人都可以理解的上下文中创建一个语言框架。在每种情况下，业务合作伙伴可能都有一个更 美国电子邮件列表中的牧师 具体的名称 - 例如申请人、客户或债务人。这些术语可以清楚地向您展示业务合作伙伴在此特定环境中的重要性。但是，您应该意识到这种语言必须随处可见。无论是领域专家、架构师还是软件开发人员 - 每个人都必须使用相同的词汇。因此，特殊术语也必须反映在代码和数据库中。


通过引入通用语言来使用统一的词汇。

另外，微服务有下限吗？
在有界上下文或通用语言定义了上限之后，就出现了一个服务可以有多小的问题。领域驱动设计还可以帮助您进行战术设计。此处提供的模式和工具可帮助您设计上下文的内部结构。所谓的“聚合”特别有帮助。您可以使用该术语来想象一组对象，这些对象在数据更改和完整性方面形成一个单元。换句话说：不应有超过总限额的交易。此外，外部接口是通过所谓的聚合根定义的。

那我们走吧？
在您自己的公司中引入领域驱动设计等方法或工具之前，您应该意识到这通常也会对组织结构产生影响。开发人员需要更多地关注主题，领域专家应该有良好的技术理解。如果不能保证这一点，或者管理层没有积极推动这一点，潜在的摩擦点可能会很快破坏预期的利润或效益。

这篇文章也出现在银行博客上。