mysql - 构造具有两个清晰部分的应用程序的方法

Question

我在一个有无限数量表的项目中，我们必须找到一个为平台带来可扩展性的解决方案，但我们似乎没有弄清楚什么才是真正好的解决方案。

该平台是一个求职者，所以它有两个明确的部分，候选人和公司。

我们一直在思考并找到了重构当前数据库的可行解决方案，因为它是一个怪物。

• 2 个 API 的 2 个数据库:这种方式需要大量的数据库迁移工作，但会非常清楚地定义平台的不同部分。
• 2 个 API 的 1 个数据库:这样一来，数据库工作将减少，使我们现在拥有的内容正常化，但我们仍会将平台的两个部分在逻辑上分开。
• 1 API 1 数据库:规范化数据库，并在同一个 API 中执行所有操作，尝试在逻辑上分离所有内容，使其可扩展，但同时可从一个部分访问到另一个部分。

现在我更喜欢 1 API 1 数据库解决方案，但我们希望阅读一些有经验的用户来做出最终选择。

谢谢!

Answer 1

几年前我遇到过和你一样的情况。我将尝试表达我对我们如何处理它的想法。所有这些听起来可能有些自以为是，但每项任务都是不同的，因此实现也是如此。

我注意到的两个最大的问题:

• 拥有无限数量的表是您当前的数据库架构设计是 Big Ball of Mud 的第一个标志。 .

• 确认您有一个 monster database表示您最好开始将其重构为更小的部分。是的，我知道这绝非容易。

如果您能向我们展示您的代码库的一些架构细节/部分，那么您的问题会增加很多值(value)，这样我们就可以给出更合适的想法。

链接请见谅Domain Driven Design相关信息来源。我知道 DDD 不是任何技术问题，但是您需要选择的策略非常重要，我认为它为这篇文章带来了值(value)。

---

了解您的问题领域

在开始拆分数据库之前，您应该清楚地了解您的问题域是如何工作的。简而言之:简而言之，问题域定义是您尝试使用您将要应用的策略解决的业务问题的域。

选择您的策略

这里最重要的是:您的策略带来的商业值(value)。在这种情况下，建议的策略是明确区分数据库对象。

战术!

我们选择了策略，现在我们需要定义应用于此重构的策略。我们在这里对策略的定义应该明确设置为:

• 将属于一起的相关数据库对象分开，这定义了明确的边界。
• 确保重新分组的数据库对象之间的连接保持完好并且正常工作。我在这里谈论的是交叉表/对象引用。

---

让我们了解技术 - 数据库

如何破坏东西

我个人会将您当前的模式拆分为三个独立的部分:

1. 候选人
2. 公司
3. 常用表

推理

通过策略性地拆分这些数据库对象，您可以有意识地分离这些关注点。这种分离让您拥有了一个新事物:战术边界。

您的每个新分离的模式现在都有不同的上下文和不同的边界。例如有候选人模式 bounded context .它将业务概念/规则/等组合在一起。这同样适用于公司架构。

唯一的区别是公用表架构。这可以作为 shared kernel - 如果您愿意，可以在您的其他数据库之间架起一座桥梁，其中包含所有其他模式需要访问的所有共享表。

结果

上面所说的一切都可以让你达到一个水平，你可以:

• 备份/恢复更快更方便
• 分别扩展数据库实例
• 轻松设置/监控对每个模式定义的数据库对象的访问

---

API

如何粘合东西

这是它变得非常油腻的地方，但是实现 API 真的取决于您的业务用例。我个人会设计两个不同的公共(public) API。

例子

1. 对于候选人
2. 对于公司

相同的设计原则也适用于此。这里唯一的区别是，我认为为公用表添加 API 没有增加业务值(value)。它可能只是一个简单的数据库模式，这两个主要 API 都可以查询或向其发送命令。