将软件划分为多个模块是否更好,每个模块都有自己的数据库

Question

我正在开发一个主要在asp.net开发的医疗保健应用程序,Oracle 11g作为后端.在当前状态下,应用程序分为3层,即UI,BLL和DAL.由于BLL和DAL是类库项目,因此它们被部署为单个dll(一个用于BLL,另一个用于DAL).最近,该软件被审查了另一位开发人员,他提出了将整个软件划分为单独模块的建议,每个模块都有自己的项目和数据库,即库存模块作为InventoryUI(asp.net Web应用程序项目,InventoryBLL(类库项目)和InventoryDAL(类库项目).所有模块获得三个不同的项目,其中单独的数据库通过Web服务相互通信.

所以我的问题是

1. 这个建议的架构比我们的更好吗？
2. BLL和DAL有多个dll是否更好？优缺点都有什么.
3. 单个应用程序有多个数据库是否更好？怎么样？

任何链接,建议都非常欢迎.

Answer 1

物理分离模块的优点是它允许在不同团队之间逻辑分解工作.在您的情况下,您可以拥有一个库存团队负责所有与库存相关的事务,他们会发布API,而对于所有其他团队,库存模块的基础都是黑盒子.这是解决域中复杂性的一个优势.

缺点是如果您的项目很小,您可能会在软件开发和部署过程中引入更多的复杂性,特别是如果您执行跨越流程(或机器)障碍的事情.

1. 建议的体系结构可能更好地基于项目的需求,特别是在大小方面.一些妥协可能也是一种更好的方法 - 如果你发现你可能有几十个或一百个模块将类似的模块组合在一起是一种实用的方法.

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

3. 假设您的RDBMS支持多个模式,我将首先使用多个模式,然后再访问多个数据库.当数据库的性质发生变化时,我会访问多个数据库 - 高交易量与高读取量(分析).如果您有需要跨模块的事务,并且您在物理上将数据库分开,那么管理这些事务可能会变得不必要地复杂化.