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

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

缺点是,如果你的项目很小,你可能会在软件开发和部署过程中引入更多的复杂性,尤其是如果你做了一些事情,比如跨越流程(或机器)障碍。

1. 根据项目的需要,特别是在规模方面,建议的架构可能会更好。一些折衷可能也是一种更好的方法——如果你发现你可能有几十个或一百个模块将类似的模块组合在一起是一种实用的方法。

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

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

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

这听起来像是评审员在指向SOA的方向。分离成隔离的物理模块可以提供一定的安全性,因为系统的某些部分可能会出现故障,而不会导致所有设备故障。

然而,分离应用程序也会给产品带来复杂性(特别是在为了提交单个业务事务,必须与多个模块通信的场景中)。

我曾参与过一个项目,该项目(由于客户需求的需要)通过包含另一个应用程序的方式继承了第二个数据库,所以我不提倡这种方法。这会使代码库变得混乱,最终往往需要在数据库之间复制数据,或者需要业务逻辑访问这两个数据库(直接访问或通过web服务调用等其他机制访问)。在有问题的情况下,这是必要的,因为一个数据库是Oracle,另一个是SQL Server,所以合并这两个数据存储将是一个非常头疼的问题,但这不是我会轻易选择的路线。

评审员提出了哪些论点,建议将其拆分为多个具有独立数据库的项目?即使您想按功能区将业务逻辑拆分为单独的DLL,为什么需要不同的数据库和DAL?这似乎是为了复杂性而引入复杂性,除非你的代码库真的很庞大,或者存储的数据量会导致单个数据库中的性能问题,而这些问题可以通过将数据拆分成单独的数据库来缓解。考虑到这一变化可能涉及的工作量,似乎这个人有责任证明你为什么 应该 去做!

我倾向于首先定义子域,并确保它们根据功能进行逻辑划分;不要太大,也不要太小。然后,每个子域都将成为一个独立的软件,由服务层、应用层、域层和基础设施层组成(正如我所描述的 here ).

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

所以我认为在逻辑模块中构建代码是有意义的(事实上你应该这样做),但我会 不 如果不是真的需要的话,请对数据库进行此操作,因为这会使您的维护和可靠性更加困难。

这完全取决于你的要求。

如果您将来需要移动到单独的物理层,这可以派上用场 (您可以在不同的机器上运行每个项目,从而将每个项目分开 模块)。然而,这将导致整体应用程序的减少 表演这样做的好处是,其他项目可以独立访问这些单独的项目/层。

我对分离数据库是否会有任何好处持高度怀疑态度。您是否计划将来将每个数据库移到不同的盒子中?如果没有,那么我会说坚持使用具有不同模式的单个数据库。