我正在开发一个医疗保健应用程序，主要是在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是否更好?利弊是什么?
- 对于单个应用程序有多个数据库更好吗?如何?
欢迎任何链接，建议。
物理分离模块的优点是它允许在不同的团队之间逻辑地分解工作。在您的案例中，您可能有一个负责所有与库存相关的事情的库存团队，他们发布了一个API，而对所有其他团队来说，库存模块的基础是一个黑盒。这是处理领域复杂性的一个优势。
缺点是如果你的项目很小，你可能会在软件开发和部署过程中引入更多的复杂性，特别是当你做一些像跨越过程(或机器)障碍的事情时。
-
根据项目的需要，特别是在规模方面，建议的架构可能更好。如果您发现您可能有几十个或100个模块，那么将类似的模块分组在一起是一种实用的方法。
-
多个用于业务逻辑和数据访问的DLL是可以的，只要有一个共同的祖先提供可以利用的基类。每个DAL在连接字符串方面都有自己的配置，这是一个非常糟糕的地方。同样，如果一个DAL使用映射器模式而另一个使用活动记录——虽然这两种模式可以共存——这些模式应该在基类中提供。
-
假设您的RDBMS支持多个模式，我会首先使用多个模式，然后再去多个数据库。当数据库的性质发生变化时——高交易量vs高读取量(分析)——我会使用多个数据库。如果您有需要跨模块的事务，并且您已经在物理上分离了数据库，那么管理这些事务可能会变得不必要的复杂。
这完全取决于您的业务需求。
听起来好像审稿人指向了SOA的方向。将系统分割成独立的物理模块提供了一定的安全性，因为系统的某些部分可能会出现故障，而不会导致整个系统瘫痪。
但是，分离应用程序也会给产品带来复杂性(特别是在为了提交单个业务事务，必须与多个模块通信的场景中)。我曾参与过一个项目，该项目(由于客户需求的必要性)通过包含另一个应用程序的方式继承了第二个数据库，因此我不提倡这种方法。它使代码库变得混乱，您经常需要在数据库之间复制数据，或者需要您的业务逻辑访问两个数据库(直接或通过web服务调用等其他机制)。在这种情况下，这是必要的，因为一个数据库是Oracle，另一个是SQL Server，所以合并两个数据存储将是一个非常令人头疼的问题，但这不是我轻易选择的路线。
建议将项目分成多个项目并使用单独的数据库的审稿人提出了什么论点?即使您希望按功能领域将业务逻辑拆分为单独的dll，为什么还需要不同的数据库和dll呢?这似乎是为了复杂性而引入复杂性，除非您的代码库非常庞大，或者存储的数据量导致单个DB中的性能问题，可以通过将数据拆分到单独的DB中来缓解。考虑到这种改变可能涉及的工作量，似乎这个人有责任证明为什么你应该做这件事!
我倾向于做的是首先定义子域，并确保它们是基于功能的逻辑划分;不要太大，也不要太小。然后，每个子域将成为一个独立的软件，由服务层、应用层、域层和基础设施层组成(如我在这里所描述的)。
这也意味着它们中的每一个都有自己的存储库，但不一定是单独的数据库。实际上，我更希望保留一个数据库，但使用不同的模式来标识表所属的域。通过这种方式，您可以在表之间保持约束(跨模式)并保证数据一致性。
所以我认为在逻辑模块中构建代码是有意义的(事实上你应该这样做)，但是如果真的不需要，我会而不是对数据库这样做，因为这会使您的生活在维护和可靠性方面变得更加困难。这完全取决于你的要求。
如果您将来需要移动到单独的物理层，这可以派上用场(您可以在不同的机器上运行每个项目，从而将每个项目分开模块)。然而，这将导致整个应用程序的减少表演这样做的好处是，其他项目可以独立访问这些单独的项目/层。
我非常怀疑您是否会通过分离数据库获得任何收益。您是否计划将来将每个数据库移动到不同的盒子中?如果没有，那么我建议坚持使用具有不同模式的单个数据库。