Architecture 将一个软件分成多个模块，每个模块都有自己的数据库，这样更好吗

我正在开发一个医疗保健应用程序，主要是在asp.net中开发的，以Oracle 11g为后端。在当前状态下，应用程序分为3层，即UI、BLL和DAL。由于BLL和DAL是类库项目，因此它们被部署为单个dll（一个dll用于BLL，另一个用于DAL）。最近，另一位开发人员对该软件进行了审查，他建议将整个软件分成单独的模块，每个模块都有自己的项目和数据库i-e清单模块，如InventoryUI（asp.net Web应用程序项目、InventoryBLL（类库项目）和InventoryDAL（类库项目）.所有模块通过web服务获得三个不同的项目，并使用单独的数据库相互通信

所以我的问题是

建议的架构是否比我们现有的更好

BLL和DAL使用多个dll是否更好？利弊如何

单个应用程序使用多个数据库是否更好？如何

---

欢迎您提供任何链接和建议。

这完全取决于您的业务需求

这听起来像是评论员指向了SOA的方向。分离成独立的物理模块可以提供一些安全性，因为系统的某些部分可能会出现故障，而不会导致所有问题

---

但是，分离应用程序也会给产品带来复杂性（特别是在为了提交单个业务事务，您必须与多个模块进行通信的场景中）。

参与了一个项目，该项目（由于客户需求的需要）通过包含另一个应用程序的方式继承了第二个数据库，我不提倡这种方法。它会使代码库变得混乱，您通常需要在数据库之间复制数据，或者需要您的业务逻辑来访问这两个数据库（直接或通过一些其他机制，如web服务调用）。在所讨论的案例中，这是必要的，因为一个数据库是Oracle，另一个是SQL Server，因此合并这两个数据存储将是一个非常头痛的问题，但我不会轻易选择这条路线

---

建议将业务逻辑拆分为具有独立数据库的多个项目的审阅者提出了哪些论据？即使您希望按功能区域将业务逻辑拆分为独立的DLL，为什么需要不同的数据库和DAL？这似乎是为了复杂性而引入复杂性，除非您的代码库是trul庞大的数据量或存储的数据量导致了单个数据库中的性能问题，可以通过将数据拆分为单独的数据库来缓解。考虑到此更改可能涉及的工作量，似乎有责任证明您为什么要这样做！

这一切取决于您的需求

如果将来需要移动到单独的物理层，这会很方便 （您可以在不同的计算机上运行每个项目，从而将每个项目分开。） 但是，这将导致总体应用程序的减少 这将带来的好处是，其他项目可以独立地访问这些单独的项目/层

---

我非常怀疑分离数据库是否会有任何好处。您是否计划在将来将每个数据库移动到不同的框中？如果没有，那么我会说，使用具有不同模式的单个数据库。

物理分离模块的好处是，它允许在不同的模块之间进行逻辑分解租赁团队。在您的情况下，您可以有一个库存团队，负责所有与库存相关的事情，他们发布API，而对于所有其他团队来说，库存模块的基础是一个黑盒子。这对于解决您所在领域的复杂性是一个优势

缺点是，如果您的项目很小，您可能会在软件开发和部署过程中引入更多的复杂性，特别是如果您做了一些跨越过程（或机器）障碍的事情

建议的体系结构可能更好地基于项目的需求，特别是在规模方面。一些折衷可能也是更好的方法-如果您发现您可能有几十个或一百个模块，将类似的模块组合在一起是一种实用的方法

多个DLL用于业务逻辑和数据访问是可以的，只要有一个提供基类的共同祖先。每个DAL都有自己的连接字符串配置，这是一个非常糟糕的地方。同样，如果一个DAL使用映射器模式，另一个使用活动记录，而这两个模式都可以oexist-这些模式应该在基类中提供

假设您的RDBMS支持多个模式，我将首先使用多个模式，然后再转到多个数据库。当数据库的性质发生变化时，我会转到多个数据库-高事务量与高读取量（分析）。如果您有需要跨模块的事务，并且您已将数据库物理分离，则管理这些事务可能会变得不必要的复杂

---

我倾向于首先定义子域，并确保它们根据功能进行逻辑划分；不要太大，也不要太小。然后，每个子域将成为一个独立的软件，由服务层、应用层、域层和基础结构层组成（如我所述）

这也意味着它们中的每一个都有自己的存储库，但不一定是一个单独的数据库。。事实上，我主要希望保留一个数据库，但使用不同的模式来标识表所属的域。这样，您可以在表之间保留约束（跨模式）并保证数据一致性

所以我认为这是有道理的