我正在开发一个主要在 asp.net 中以 Oracle 11g 作为后端开发的医疗保健应用程序。在其当前状态下，应用程序分为 3 层，即 UI、BLL 和 DAL。由于 BLL 和 DAL 是类库项目，它们被部署为单个 dll（一个 dll 用于 BLL，另一个用于 DAL）。最近，另一位开发人员对该软件进行了审查，他提出将整个软件划分为单独的模块的建议，每个模块都有自己的项目和数据库，即库存模块作为 InventoryUI（asp.net Web 应用程序项目、InventoryBLL（类库项目）和 InventoryDAL（类库项目）。所有模块都获得三个不同的项目，这些项目具有单独的数据库，通过 Web 服务相互通信。
所以我的问题是
任何链接，建议都非常受欢迎。
物理分离模块的优点是它允许在不同团队之间逻辑分解工作。在您的情况下，您可能有一个库存团队负责所有与库存相关的事情，他们发布一个 API，并且对于所有其他团队，库存模块的基础是一个黑匣子。这是解决您的域中的复杂性的一个优势。
缺点是如果您的项目很小，您可能会在软件开发和部署过程中引入更多的复杂性，特别是如果您执行诸如跨越流程（或机器）障碍之类的事情。
根据项目的需要，特别是在规模方面，建议的架构可能会更好。一些妥协也可能是一种更好的方法——如果你发现你可能有几十个或一百个模块将相似的模块组合在一起是一种实用的方法。
用于业务逻辑和数据访问的多个 DLL 是可以的，只要有一个共同的祖先提供基类以供使用。每个 DAL 在连接字符串方面都有自己的配置是一个非常糟糕的地方。同样，如果一个 DAL 使用映射器模式，另一个使用活动记录 - 虽然两种模式可以共存 - 这些模式应该在基类中提供。
假设您的 RDBMS 支持多个模式，我将首先使用多个模式，然后再访问多个数据库。当数据库的性质发生变化时，我会访问多个数据库 - 高事务量与高读取量（分析）。如果您有需要跨模块的事务，并且您已经将管理这些事务的数据库物理分离，则可能会变得不必要地复杂。
我倾向于做的是首先定义子域，并确保它们根据功能在逻辑上划分；不要太大，不要太小。然后，每个子域将成为一个独立的软件，由服务层、应用程序层、域层和基础设施层组成（正如我在此处描述的那样）。
这也意味着他们每个人都有自己的存储库，但不一定是单独的数据库。事实上，我主要想保留一个数据库，但使用不同的模式来标识表所属的域。这样，您可以保持表之间的约束（跨模式）并保证数据的一致性。
所以我认为在逻辑模块中构造你的代码是有意义的（事实上你应该这样做），但如果不是真的需要，我不会对数据库这样做，因为这会使你的生活在维护和可靠性。
这完全取决于您的业务需求。
听起来审稿人指的是 SOA 的方向。分离成独立的物理模块可以提供一定的安全性，因为系统的某些部分可能会发生故障而不会导致一切崩溃。
但是，分离应用程序也给产品带来了复杂性（特别是在为了提交单个业务事务，您必须与多个模块进行通信的场景中）。
在从事过一个项目（根据客户要求）通过包含另一个应用程序来继承第二个数据库时，我不会提倡这种路线。它使代码库变得混乱，您通常最终需要在数据库之间复制数据，或者需要您的业务逻辑访问两个数据库（直接或通过一些其他机制，例如 Web 服务调用）。在有问题的情况下，这是有必要的，因为一个数据库是 Oracle，另一个是 SQL Server，因此合并这两个数据存储会非常令人头疼，但这不是我会轻易选择的路线。
建议将项目拆分为具有独立数据库的多个项目的审稿人提出了哪些论点？即使您想将业务逻辑按功能区域拆分为单独的 DLL，为什么需要不同的数据库和 DAL？这似乎是为了复杂性而引入复杂性，除非您的代码库确实庞大，或者存储的数据量导致单个数据库中的性能问题，可以通过将数据拆分为单独的数据库来缓解这些问题。鉴于此更改可能涉及的工作量，似乎这个人有责任证明您为什么应该这样做！
这一切都取决于您的要求。
如果您将来需要移动到单独的物理层，这可以派上用场（您可以在不同的机器上运行每个项目，从而分离每个模块）。但是，这将导致整体应用程序性能下降。这将产生的好处是其他项目可以独立访问这些单独的项目/层。
我非常怀疑分离数据库是否会带来任何好处。您是否打算将来将每个数据库移动到不同的盒子中？如果不是，那么我会说坚持使用具有不同模式的单个数据库。