我正在开发一个主要使用 Oracle 11g 作为后端的 asp.net 开发的医疗保健应用程序。在当前状态下，应用程序分为 3 层，即 UI、BLL 和 DAL。由于 BLL 和 DAL 是类库项目，因此它们被部署为单个 dll(一个 dll 用于 BLL，另一个用于 DAL)。最近，另一位开发人员对该软件进行了审查，他提出了将整个软件分成单独的模块的建议，每个模块都有自己的项目和数据库，即库存模块，如 InventoryUI(asp.net Web 应用程序项目、InventoryBLL(类库项目)和 InventoryDAL(类库项目)。所有模块都获得三个不同的项目，这些项目具有单独的数据库，通过 Web 服务相互通信。
所以我的问题是
- 这个建议的架构是否比我们现有的更好？
- 为 BLL 和 DAL 使用多个 dll 是否更好？有什么优点和缺点。
- 单个应用程序拥有多个数据库是否更好？怎么样？
任何链接、建议都非常受欢迎。
请您参考如下方法:
物理分离模块的优势在于它允许工作在不同团队之间进行逻辑分解。在您的情况下，您可以有一个库存团队负责所有与库存相关的事情，他们发布一个 API，并且对于所有其他团队来说，库存模块的基础是一个黑盒子。这有利于解决您所在领域的复杂性。
缺点是，如果您的项目很小，您可能会在软件开发和部署过程中引入更多的复杂性，尤其是当您执行跨进程(或机器)障碍之类的操作时。
建议的架构可能会更好地基于项目的需求，尤其是在规模方面。一些妥协可能也是一种更好的方法 - 如果您发现您可能有几十个或一百个模块，将相似的模块组合在一起是一种实用的方法。
只要有一个共同的祖先提供可利用的基类，就可以使用多个用于业务逻辑和数据访问的 DLL。每个 DAL 在连接字符串方面都有自己的配置，这是一个非常糟糕的地方。同样，如果一个 DAL 使用映射器模式而另一个使用事件记录——虽然这两种模式可以共存——这些模式应该在基类中提供。
假设您的 RDBMS 支持多个模式，我会先使用多个模式，然后再使用多个数据库。当数据库的性质发生变化时，我会访问多个数据库——高事务量与高读取量(分析)。如果您有需要跨模块的事务，并且您在物理上分离了数据库，那么管理这些事务可能会变得不必要地复杂。
