一个简单的计费系统(在 ColdBox MVC 之上)正在膨胀成一个半企业库存 + 供应 + 问题跟踪 + 利润跟踪应用程序。他们似乎在做自己的事情，但他们共享许多东西，包括一个公共(public)的客户和员工池(登录)，以及其他混合的数据和业务逻辑。
你如何保持这样的系统模块化？从 维护 、 可测试性 和 可重用性 立场来看？
您有什么想法和/或经验要分享吗？
最佳答案
停止考虑技术(例如 Java 门户、ColdBox 模块等)并专注于架构。我的意思是想象你如何向观察者解释你的系统。首先在白板上绘制一组框，代表每个部分——库存、客户、问题跟踪等——然后使用线条来显示这些系统之间的交互。这让您专注于 separation of concerns ，它像功能一样组合在一起。首先不要担心 UI，而是专注于算法和数据。
如果您在谈论 MVC，那么这一步将重点放在模型上。随着该事件的完成，困难的部分来了，修改代码以符合该图(即模型)。为了真正理解这个模型应该是什么样子，我建议阅读 Eric Evans 的 Domain Driven Design。目标是建立一个模型，其关系可通过 dependency injection 进行管理。据推测，这会给您留下一组高级 CFC——服务，如果你愿意的话——具有底层业务实体和持久性管理。它们的关系最好由某种 bean 容器/服务定位器管理，我相信 ColdBox 有自己的，另一个例子是 ColdSpring。
这项工作的结果是一个可单元测试的模型。独立于用户界面。如果所有这些都令人困惑，我建议您查看 Working Effectively with Legacy Code 以了解有关如何进行此转换的一些想法。
一旦你有了它，现在就可以考虑 Controller (例如 ColdBox)并通过它将模型链接到 View 。但是，请仔细研究任何 Controller 并选择它，因为它会为您的应用程序带来一些功能(缓存是一个想到的例子)。您的 View 可能也需要重新构想才能与这个新设计进行交互，但是您应该拥有一个系统，其中算法现在与 UI 分离，使 View 的工作变得容易。
实际上，您解决这个问题的方法是迭代的。找到一个可以按照我所描述的方式轻松梳理出来的系统，进行单元测试，与人一起验证，然后继续下一个系统。虽然这是一个乏味的过程，但我可以保证它比尝试重写所有内容要少得多，除非您提前有一套非常好的自动验证，否则会招来灾难。
更新
重申一下，该技术不会解决您的问题。朝着更具凝聚力的对象继续迭代将。
现在就耦合数据而言，使用 ORM 您已经做出了权衡，而整体系统确实有其优势。另一种方法是通过 DI 为一个有状态实体提供对另一个服务对象的引用，以便您通过它检索它。这将使您能够出于单元测试的目的模拟它，并将其替换为类似的服务对象和相应的实体，以促进在其他上下文中的重用。
在解决业务问题(例如会计)方面，重用是一种新兴属性，您可以编写多个系统来做大致相同的事情，然后弄清楚如何概括。根据我的经验，您很少会开始编写一些东西来解决一些成为可重用组件的业务问题。
关于model-view-controller - CF项目太大了，怎么办？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/5709926/