一个简单的计费系统（在 ColdBox MVC 之上）正在膨胀为一个半企业库存 + 配置 + 问题跟踪 + 利润跟踪应用程序。他们似乎在做自己的事情，但他们共享许多东西，包括共同的客户和员工（登录）池，以及其他混合的数据和业务逻辑。
您如何保持这样的系统模块化？从维护、可测试性和可重用性的角度来看？
您有什么想法和/或经验想分享吗？
【问题讨论】：
标签： model-view-controller coldfusion erp coldbox
我建议您使用 ColdBox Modules 将应用程序分解为模块化部分。您还可以将单独的业务逻辑研究到 RESTful ColdBox 层中，并以这种方式加入系统。同样，这完全取决于您目前的要求和需要。
模块旨在将单一应用程序分解成更易于管理的部分，这些部分可以独立或耦合在一起。
【讨论】：
停止思考技术（例如 Java 门户、ColdBox 模块等）并专注于架构。我的意思是想象你如何向观察者解释你的系统。首先在白板上绘制一组框，代表每件作品 - 库存、客户、问题跟踪等…… - 然后使用线条显示这些系统之间的交互。这让您关注separation of concerns，它像功能一样组合在一起。首先不要担心 UI，而是专注于算法和数据。
如果我们谈论的是 MVC，那么这一步就是专注于模型。随着该活动的完成，困难的部分来了，修改代码以符合该图（即模型）。要真正理解这个模型应该是什么样子，我建议阅读 Eric Evans 的Domain Driven Design。目标是建立一个模型，其关系可通过dependency injection 进行管理。大概这会为您留下一组高级 CFC（如果您愿意的话，可以提供服务）以及底层业务实体和持久性管理。他们的关系最好由某种 bean 容器/服务定位器来管理，我相信 ColdBox 有它自己的，另一个例子是 ColdSpring。
这项工作的结果是一个可单元测试的模型。独立于用户界面。如果所有这些都令人困惑，我建议您查看Working Effectively with Legacy Code，了解有关如何进行此转换的一些想法。
一旦你有了这个，现在就可以考虑一个控制器（例如ColdBox）并通过它将模型链接到视图。但是，请仔细研究任何控制器并选择它，因为它可以为您的应用程序带来一些功能（缓存是一个例子）。您的视图可能也需要重新构想才能与这个新设计交互，但您应该拥有一个算法现在与 UI 分离的系统，从而使视图的工作变得容易。
实际上，您解决此问题的方式是迭代的。找到一个可以按照我描述的方式轻松梳理的系统，通过单元测试对其进行测试，并与人员一起验证，然后继续下一个系统。虽然这是一个乏味的过程，但我可以保证它比尝试重写所有内容要少得多，除非您提前拥有一套非常好的自动验证，否则会招致灾难。
重申一下，技术无法解决您的问题。将朝着更具凝聚力的对象继续迭代。
现在就耦合数据而言，使用 ORM 已经做出了权衡，而单体系统确实有其优势。另一种方法是通过 DI 为一个有状态实体提供对另一个服务对象的引用，以便您通过它检索它。这将使您能够模拟它以进行单元测试，并将其替换为类似的服务对象和相应的实体，以促进在其他上下文中的重用。
就解决业务问题（例如会计）而言，重用是一种新兴属性，您可以编写多个系统来做大致相同的事情，然后弄清楚如何进行泛化。根据我的经验，您很少会开始编写一些东西来解决一些成为可重用组件的业务问题。
【讨论】：
我建议您花一些时间来研究模块。它将有助于将您的代码划分为逻辑特征，同时保持与模型的集成。
作为 ColdBox，有大量的文档和示例...
【讨论】：
您需要摆脱 MVC 并用 SOA 架构取而代之，这样将两部分连接起来的唯一东西就是服务请求。
所以在服务器端你有 DAO 和 FACADE 层。客户端可以是 MVC 或您想在其他地方使用的任何架构。您甚至可以为每个不同的业务拥有一个单独的客户。
即使对于服务器端，您也可以将项目分解为多个服务器：所有业务之间的共同点以及所有业务之间的区别。
【讨论】：
幸运的是，我们在这里面临的问题并不是独一无二的。
这里的问题似乎不在于代码本身，或者如何将其分解，而是要了解您现在正在从事 ERP 设计和开发。
了解如何最好地开发和发展以合乎逻辑的方式管理组织细节的 ERP 是我认为您要解决的更深层次的问题。如何从中进行编码的设计和架构本身源于对您需要的核心功能领域的理解。
幸运的是，我们可以研究一些您可以掌握的现有 ERP 系统，看看它们是如何解决一些问题的。有一些不错的开源 ERP，让我想到这个提示的是我监督的 SAP Business One 的全周期安装（一个绕过大型 SAP 挑战的中小型 ERP）。
您正在寻找的是了解其他人如何解决您面临的相同 ERP 架构。至少您会了解模块化之间的权衡，在哪里划定模块之间的界限以及为什么。
通常情况下，ERP 系统会处理从报价到生产（如果需要）、计费、运输和由此产生的会计工作的所有事情。
ERPS 处理两个主要领域：
有些企业是小部件工厂，有些是服务企业。一个功能齐全的开箱即用 ERP 将有一个“订单”的连续链/生命周期，该“订单”由多个步骤提供服务。
如果我们阅读 ERP 可以涵盖的步骤的粗略列表，您会看到适用于您的步骤。这些可能是您拥有或应该将您的应用程序分解成的模块。想象一下以下步骤，其中每个步骤都是不同的文档，都连接到链中的前一个文档。
系统集成商的作用是使用所需的步骤，并跳过未使用的步骤。这会为您不断发展的应用带来一件事：
制定可靠的数据安全策略。确保您感到舒适，因为每个人都只能看到他们应该看到的内容。假设它已经到位，将应用程序分解为主要部分是一个好主意。模块是我们的朋友。然而，分解它们的顺序可能会对你的行为产生更大的影响。
查看哪些部分是通用的（报告等），可以在多个应用程序之间重复使用，哪些部分更专门用于应用程序本身。与应用程序本身相关的功能可能已经更紧密地耦合在一起，您可能需要解决这个问题。
对于 ERP，我一直更喜欢交易“核心”模块，所有其他交易提供者都使用该模块（一旦定义，计费就会推动流程）。
当我将 90 年代的 Lotus Notes ERP 转换为 SAP ERP 时，Lotus Notes 应用程序非常出色，它可以处理应有的一切。有一些构建在侧面的小应用程序没有作为模块集成，这是摆脱它的主要原因。
如果您今天根据今天的要求重新编写应用程序，您会如何以不同的方式完成它？看看与你所拥有的是否有任何重大差异。让应用程序争取您的注意力，以决定首先需要检修/模块化的内容。 ColdBox 非常适合模块化，无论您是使用插件类型的模块还是只是使用分离良好的代码，您都不会出错，这只是开发人员时间和金钱的功能来完成它。
我要构建/自动化单元测试的第一个模块是最复杂的编程模块。如果你是一个体面的开发人员，你可能不需要从昨天开始进行端到端的单元测试。从最复杂的开始，进入应用程序的核心部分，然后扩展到可能让您彻夜难眠的任何其他领域。
希望对您有所帮助！如果您不介意，请分享您最终会做什么，如果我提到的任何内容需要进一步解释，请在此处或推特上联系我 :) @JasPanesar
【讨论】：