构建具有两个明确部分的应用程序的方法

Question

我在一个拥有无限数量表的项目中，我们必须找到一个为平台带来可扩展性的解决方案，而我们似乎无法弄清楚什么是非常好的。< / p>

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

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

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

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

谢谢！

Answer 1

几年前，我的情况有点像你的情况。我将尝试表达我对如何处理它的想法。所有这些听起来都很自以为是，但每个任务都是不同的，因此实施也是如此。

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

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

• 承认您有monster database表示您最好开始将其重构为较小的部分。是的，我知道从不

。

如果您向我们展示代码库中的一些架构细节/部分，那么它会为您的问题增加更多价值，因此我们可以提供更合适的想法。

请原谅我链接Domain Driven Design相关信息来源。我知道DDD 不关于任何技术上的瑕疵，但是你需要选择的策略是非常重要的，我认为它为这篇文章带来了价值。

了解您的问题域

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

选择策略

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

战术！

我们选择了策略，现在我们需要定义应用于此重构的策略。我们在这里对战术的定义应该明确地设置如下：

• 将属于一起的相关数据库对象分开，这定义了明确的边界。
• 确保重新分组的数据库对象之间的连接保持不变并且正在运行。我在这里谈论跨表/对象引用。

让技术 - 数据库

如何破解

我个人会将您当前的架构拆分为三个独立的部分：

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

推理

通过战略性地拆分这些数据库对象，您可以有意识地将这些问题分开。这种分离让你有了新的东西：战术边界。

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

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

结果

所有这一切都可以让你达到你可以达到的水平：

• 更快更方便地备份/恢复
• 单独扩展数据库实例
• 轻松设置/监控按架构定义的数据库对象的访问权限

API

如何粘贴东西

这是非常油腻的地方，但是在您的业务用例中实现API 真正依赖。我个人会设计两种不同的公共API。

实施例

1. 候选人
2. 公司

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

Answer 2

我认为，分离数据库会导致一些内容管理困难。这两个单独的部分将包含完全相同的表格，如工作岗位，城市，商业区等。您将如何维护这些表格？你会插入国家＆＃34;津巴布韦＆＃34;对他们两个？如果他们的主键不相等怎么办？在某些时候，您将需要使用来自这些分离数据库的数据以及＆＃34;津巴布韦＆＃34;将会被使用？我不是在谈论性能，但为这两个项目使用相同的数据库将使您的生活更轻松。此外，我们处于云时代，您可以根据需要扩展单个数据库服务/服务器/ Droplet。为了清楚模块，您可以定义命名约定。例如，如果两个部分都使用了表格，则添加前缀＆＃34; common _＆＃34 ;,如果候选人使用的表格使用＆＃34;候选人_＆＃34;等。

对于API，您也可以使用相同的方法。定义3个不同的API部分。共同的，候选人和公司。但是，通过这种方式，您应该为API编写经过充分测试的身份验证和授权层。

如果我是你，我选择1 API，1数据库。

如果失败 ，将1个API分离到2个API或1个数据库分成2个数据库要比合并它们容易得多（拙见...）< / em>的