什么是最好的架构/系统设计，以不同的口味和不同的逻辑推出相同的应用程序？

Question

有一家公司，比方说"X“，它主要经营房地产/房地产，并有一个网站(在线门户)来显示这些属性。

就像其他大公司一样，当他们看到一个竞争对手时，他们会收购它，并让姐妹公司之间的竞争遗产完好无损，这样业务就会增长，最终的利益将流向母公司/总公司。

现在考虑"X“获得的"Y”。然后X的管理层决定使用X的源代码，修改UI，迅速在市场上重新推出Y，哦，是的，用同一个数据库，引入一个新的值/列来区分源/应用程序来记录两个门户的活动。(这是因为Y的管理层没有出售代码或数据库，而只是出售名称/ SEO)。

X的产品管理团队决定用Y来瞄准X弱的地区，这样Y就会在这些领域变得更强，并与其他领域竞争。此更改将需要应用程序级逻辑更改/代码调整。Ps。X将向Y提供新的引线/财产记录，以帮助Y获得相对于其他竞争对手的优势。

工程小组所面对的问题是：

1. 源代码是一种遗留代码，没有达到目标。
2. X的数据已经太大了(比方说10M+记录)
3. 数据库模式/结构是一个完整的混乱！
4. 工程队从来没有机会清偿技术债务，他们也没有看到它在不久的将来。

Ps。一些商业层面的决策/逻辑，比如:X将拥有自己的用户，Y将拥有自己的用户(这意味着您必须在Y注册才能发布属性或获得应用程序特定的统计数据，尽管X的用户可以在没有注册的情况下在Y上发布内容，这需要在app的业务逻辑中处理)。

作为一名工程师，我看到了两个选择。无论是单租户还是多租户。相反，我同意我的观点，我想知道在这个场景中应该使用的最佳策略/体系结构系统设计。对于低耦合和易于维护的代码和成本效益方法，应该做些什么？

Answer 1

根据你的叙述，我理解以下要求：

• X和Y将继续作为2家品牌以下的公司运营。
• 有两个产品管理团队，显然在他们的方法上有一定的自主权，例如数据。
• X有自己的用户，Y有自己的用户

我还了解到，已经得出了以下分析结论：

• 这两家公司的数据结构非常接近，可以将所有数据合并到一个数据库中。
• 但是，在处理过程中可能会有一些不同，因为每个记录都分配给拥有的系统。
• 只有一个团队负责这个系统(S)

所有这些元素都建议采用多租方法：

• 数据所有权和公司独立性得到保障(如果以后出售给另一投资者，则很重要)
• 工程和支持可以简化，因为在现实中，他的一个系统有一些变体
• 多功能允许租户特定的定制。但这必须从一开始就得到妥善的设计。

我没有发现任何关于单一租赁方式的理由(但可能存在，而你没有告诉)。

不幸的是，根据所提供的信息无法提供更多关于体系结构的信息并提出进一步的建议。