我昨天和我的一个朋友一起去了酒吧，我们开始讨论他所在公司使用的架构。对话基本上围绕着共享数据库体系结构与分布式独立应用程序体系结构的优缺点 - 我们无法达成共识，在这种情况下，我想听听人们对这两种方法的优缺点的看法。 p>
基本上，他所工作的公司拥有一个拥有许多不同应用程序的大型架构。某些应用程序具有单个数据库，它们在它们之间共享。例如，有一个应用程序为用户提供UI以更改参考数据。该参考数据由另一个也访问相同数据的应用程序使用。我相信代码实际上是作为共享库编写的（即两个应用程序都将使用为每个代码集重新部署的公共代码集（一个将其作为依赖项）。）
还有其他应用程序使用数据库，其他应用程序也使用直接JDBC连接和数据访问代码（两个应用程序之间不常见 - 重复!!呃！）。
我的问题是围绕这个架构的优缺点而不是一个架构，其中每个应用程序都包含它在筒仓中的“主”数据。如果应用程序x需要来自应用程序的数据，则他们使用Web服务或某些消息传递技术来接收该数据。
消息传递方法会引入一个问题，即当前现在必须从其他源获取在其他应用程序的数据库中使用的引用数据“代码”（或外键）。在当前的体系结构中，这些体系的“解码”可以随时更改并立即反映在外部应用程序中，而不必具有复制数据的主/从关系 - 或者应用程序x必须查询应用程序的替代方案y只是为了显示解码值。
我读过企业集成模式，虽然它确实提供了一些消息传递优势的例子 - 我不太相信。
由于 伊恩
答案 0 :(得分：27)
message-based整合shared database的优势很难明确表达，但会在此尝试：
DBA希望对实体之间的所有关系进行建模，以便数据始终为100% consistent，这是不可避免的争论。另一方面，您让开发人员警告DBA关于tight-coupling出现的monolithic architecture以及如何轻松更改绑定到主表的应用程序。
我认为，无论您如何进行整合，这两个论点都有点难以理解并且构建易于更改的系统具有挑战性。我想为SOA和基于消息的集成提出另一种论点。
归结为：
您有多少次遇到过拥有数百名用户的大型系统，这些用户可以完成许多不同的工作，支持多种不同的业务功能？我总是遇到他们。它们似乎是企业软件的主要内容。
所有这些系统似乎都有一个共同点，那就是改变它们非常昂贵。其中一个原因是，正如Joe R在his answer所说的那样紧密耦合。
然而，耦合是一个加载术语，我认为我们需要考虑两种非常不同的耦合类型。
第一种可以被认为是技术耦合，这意味着技术堆栈内部的垂直耦合，通常是在一层和另一层之间的n层。
因此，我们在应用程序的数据库和数据访问层之间进行耦合，在数据访问层和业务逻辑层之间进行耦合等。将这种耦合看作是错误还是错误似乎被普遍接受，但我们应该合理地思考不是期待，甚至欢迎用户DTO，UserRepository类和User数据库表之间的高度耦合？
让我们考虑一下耦合在实现层面的实际意义。耦合发生在＆＃34;属于＆＃34;一件事泄漏到另一件事。当您有多个层基本上相互讨论同一个业务实体时，这种泄漏是不可避免的。
第二种耦合，以及我想要解决的耦合，可以被认为是 business capability耦合，也称为水平耦合。这就是我们将属于一个业务功能的概念泄漏到另一个业务功能中的地方。
我的断言这个水平耦合受到使用数据库作为集成平台的鼓励。
作为一个例子，想象一下支持电子商务网站系统的典型后端系统。您通常会将库存，订购，定价和CRM作为核心功能。
如果我们在单个数据库中对此域进行建模，我们实际上将不同的功能耦合在一起。每个外键约束都可能增加这些功能之间的耦合程度。实际上，到目前为止，系统已经可以被认为是几种不同的服务＆＃34;集成在共享数据库中。
这是＆＃34;大系统＆＃34;通过使用500多个表数据库将企业的不同区域连接在一起，支持和鼓励世界的图景。
将此与小型系统＆＃34;进行对比。世界的图片，在我们的示例中，后端Web应用程序库存，订购，定价和CRM是完全独立的应用程序，具有自己的技术堆栈，他们自己的项目团队，他们自己的发布计划和他们自己的数据库。
每个应用程序或服务将对给定实体的内容有自己的理解，并且根据其支持的业务能力，它将适合该实体的定义。
这方面的一个例子是＆＃34; User＆＃34;。 CRM对用户的定义与订购或履行有着截然不同的定义。订购仅关注用户购买的用户。 CRM关注其他内容，例如客户购买模式，以及关于名称，地址等的履行关注。使用共享数据库中的单个User表不容易实现。
这张图片对我来说比共享数据库路由更可取，主要原因是生成的系统会更好地模拟它应该支持的实际业务流程。 DDD的主要原则之一是系统应该尽可能地拥有拥有它的企业。
在典型的业务中，这些各种功能并不是跨越大型企业跨越团队的层次，而是由小型垂直团队实现，通常是完全自治的，他们之间通过发送请求与其他垂直团队进行通信，指令，或让其他团队知道某个流程或任务已经开始/完成等等。
好的，但是没有共享数据库，网站现在依赖于来自所有这些不同服务的数据用于它的UI。它仍然需要在同一屏幕上一起显示这些东西。网站＆＃34;演示文稿＆＃34;图层组合所有这些并将其呈现给UI？
更重要的是，如果CRM想知道客户何时订购了什么？如果订购想知道产品价格何时发生变化，或者产品库存缺货，该怎么办？如果这些服务完全分开，那么他们如何交换数据呢？
首先解决UI问题，可以使用composite UIs完成此操作。有很多技巧可以做到这一点，但足以说它是一个相对着名的景观，而不是我们的重点。
这些服务如何沟通的第二个问题是，他们交换信息。什么样的消息？ Events。事件由一个系统发布，以便由对该事件感兴趣的任何其他系统使用。
在我们的电子商务示例中，各种事件可能是：
这些事件具有商业意义。这意味着我们可以通过小型系统方法获得额外的好处，即集成介质本身具有商业意义，并且可以用业务语言表达，这非常适合Scrum和敏捷方法。
因此，为了最终回答OP的问题，我不认为从技术角度来看共享数据库与消息传递集成方法之间存在很大差异。两种方法都需要相同类型的抽象和语义。但我确实认为它们背后的驱动力存在巨大差异，采用更多小系统思维模式的结果总体上提供了更好的商业价值。
答案 1 :(得分：4)
我正在制作这个案例。我相信有一个非常明确的理由来使用其中一个（以及一些尚未制作的点）。
数据库集成
<强>赞成
<强>缺点
不能很好地扩展。您最终会得到一个运行各种工作负载（例如事务和报告）的数据库，或者您最终会使用数据库复制来分配生产负载。
广域分布困难。多站点架构更是如此。
消息系统
<强>赞成
<强>缺点
答案 2 :(得分：3)
这是一个共享数据库架构，它足以避免它：
紧密耦合 - 如果一个应用程序需要更改主数据库表 - 其他应用程序将需要重新测试并可能需要更改以适应这些更改。
共享数据库体系结构最终会避免对架构进行严重更改。主数据库和相关应用程序往往停滞不前，导致公司无法提供创新的新产品。
This MSDN article，其中之一，解释了松散耦合的服务如何帮助上述方案。松散耦合的系统可以创新和改变，而公司其他部门不必同时进行更改 - 从而使公司能够很好地响应客户需求。