一个巨大的应用程序的架构。在模块之间共享或不共享代码

Question

一个巨大的应用程序，每隔几个月就会添加新的模块，5-10个程序员。

一些模块访问相同的表，一些模块使用(目前)相同的查询。

我的问题是，让每个模块成为一个100%独立的应用程序，有它自己的DAL类和BL类(当然，库类ZF是共享的)，或者所有的模块都应该使用相同的资源(类)，是不是更智能呢？

我唯一百分之百确定需要通用的是用户配置文件/ACL/auth数据，它位于OpenLDAP服务器上。

Answer 1

在大型易变环境中共享代码时应格外小心。在许多情况下，快速的发展和更改可能会引入不兼容性，可能会导致只有在生产中才会发现的问题。

共享代码最重要的影响是测试。特别是当依赖受到潜在破坏性变化的影响时-测试变得非常昂贵。这种开销通常会导致在进行更改时很少或根本不执行测试。因此，缺陷潜入到生产环境中。

代码越成熟，在模块或系统之间共享它就越合理。成熟的代码往往是稳定的，变化很小。它还应该有最健壮的单元和集成测试库来支持它。成熟的代码通常已经被许多用户使用过，并且您有更高的信心相信错误已经被检测和修复。

相比之下，不成熟的代码往往会经常变化--而这些变化往往是破坏性的。通常是公共接口发生变化的--这要么导致依赖于它的模块进行大量重构工作，要么导致代码库的分支，这违背了共享代码的目的。

如果您选择共享代码库的某些部分，您应该确保每个模块/系统都有一套单元和集成测试，以验证现有的使用不会受到共享代码更改的影响。您还应该考虑使共享代码非常明显，无论是通过命名约定还是版本控制实践。

根据我的经验，以下是一些共享代码可以相当安全的情况(假设您有良好的版本控制和更改管理实践)：

• 库只有一个明确的职责，它们非常简单，而且更改起来非常慢。执行定义明确的计算的
• 代码，并且只能通过加法而不是接口更改来发展。
• 代码具有窄的公共接口和支持它的广泛单元和集成测试。

Answer 2

不要认为它会更聪明，如果它是一个大型系统，可能会以维护噩梦告终。

重用很重要，而重复并不重要。

Answer 3

我认为你应该对模块进行分区，这样它们就不会共享表或查询。

面向服务的体系结构，无论您是否决定在分布式web组件方面实现它，都将隔离业务功能和它们所拥有的数据。如果操作得当，就不会有共享表或查询，而且只有一个界面可以与数据交互。在我推荐分享之前，我会花时间重新设计到这个标准。