一个简单的计费系统（在ColdBox MVC之上）正在膨胀成为半企业级库存+配置+问题跟踪+利润跟踪应用程序。他们似乎在做自己的事情，但他们共享许多东西，包括一个共同的客户和员工池（登录），以及其他混合数据＆amp;商业逻辑。
您如何保持这种系统模块化？来自维护，可测试性＆amp; 可重用性立场？
您想分享任何想法和/或经验吗？
答案 0 :(得分：7)
我建议你使用ColdBox模块将应用程序分解为模块化部分。您还可以将单独的业务逻辑调查到RESTful ColdBox层，并以这种方式加入系统。同样，这一切都取决于您当前的要求和需求。
模块旨在将单片应用程序分解为更易于管理的部分，这些部分可以是独立的，也可以耦合在一起。
答案 1 :(得分：3)
不再考虑技术（例如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为一个有状态实体提供对另一个服务对象的引用，以便通过它来检索它。这将使您能够为了单元测试而模拟它，并将其替换为类似的服务对象和相应的实体，以便于在其他上下文中重用。
在解决业务问题（例如会计）方面，重用是一种新兴属性，您可以编写多个系统来执行大致相同的操作，然后找出如何进行概括。很少根据我的经验，你开始写一些东西来解决一些成为可重用组件的业务问题。
答案 2 :(得分：2)
我建议你花点时间看一下模块。它有助于将代码划分为逻辑功能，同时保留与模型的集成。
作为ColdBox，有大量的文档和示例......
答案 3 :(得分：1)
您需要摆脱MVC并将其替换为SOA架构，这样，加入这两半的唯一方法就是服务请求。
所以在服务器端你有DAO和FACADE层。客户端可以是MVC，也可以是想要在其他地方使用的架构。您甚至可以为每个不同的业务部门建立个人客户。
即使是服务器端，您也可以将项目分解为多个服务器：所有业务之间的共同点，以及所有业务之间的区别。
答案 4 :(得分：1)
幸运的是，我们面临的问题不是唯一的。
这里的问题似乎不是代码本身，或者如何将其分开，而是要了解您现在正在进行ERP设计和开发。
了解如何以合理的方式开发和发展以最佳方式管理该组织的详细信息的ERP是我认为您正在尝试的更深层次的问题。关于如何从中进行编码的设计和体系结构本身来自对所需核心功能区域的理解。
幸运的是，我们可以研究一些现有的ERP系统，您可以了解它们如何解决一些问题。有一些很好的开源ERP，我想到的一点是SAP Business One的全周期安装（一个中小型ERP，绕过了大SAP的挑战）。
您正在寻找的是了解其他人如何解决您所面临的相同ERP架构。至少你会了解模块化之间的权衡，模块之间的界线和原因。
通常情况下，ERP系统处理从报价到生产（如果需要），结算，发货以及由此产生的会计工作的所有内容。
ERPS处理两个主要世界：
有些企业是小工具，有些则是服务企业。一个功能齐全的开箱即用ERP将有一个连续的“订单”链/生命周期，可通过多个步骤进行维护。
如果我们阅读了ERP可以涵盖的步骤的粗略列表，您将看到适用于您的步骤。这些可能是您拥有或应该破坏您的应用程序的模块。想象一下以下步骤，其中每个都是一个不同的文档，都连接到链中的前一个文档。
系统集成商进入时使用所需的步骤，并跳过未使用的步骤。这为您不断增长的应用程序带来了一件事：
制定可靠的数据安全策略。确保你很舒服，每个人都只能看到他们应该做的事情。假设已经到位，将应用程序拆分为主要部分是个好主意。模块是我们的朋友。然而，将它们分解的顺序可能会对你所做的事情产生更大的影响。
查看哪些部分是通用的，（报告等）可以在多个应用之间重复使用，哪些更专用于应用程序本身。与应用程序本身相关的功能可能已经更加紧密耦合，您可能需要解决这个问题。
对于ERP，我一直更喜欢交易“核心”模块，所有其他交易提供商（计费一旦定义就开始推动流程）。
当我将Lotus Notes ERP从90年代转换为SAP ERP时，Lotus Notes应用程序非常出色，它可以处理所有应有的事情。这是一些侧面构建的迷你应用程序，它们没有作为模块集成，这是摆脱它的主要原因。
如果您今天重新编写应用程序，满足今天的要求，您将如何以不同的方式完成它？看看你有什么与你有什么重大差异。让应用程序争取你的注意力，以决定首先需要检修/模块化。 ColdBox非常适合模块化，无论您是使用插件类型模块还是只使用分离良好的代码，您都不会出错，它只是开发人员时间和资金的一个功能，可以完成它。
我构建/自动化单元测试的第一个模块是编程最复杂的。如果你是一个体面的开发者，你可能不需要从昨天开始的端到端单元测试。从最复杂的开始，移动到应用程序的核心部分，然后传播到任何其他可能让你夜不能寐的地方。
希望有所帮助！如果你不介意，分享你最终做的事情，如果我提到的任何事情需要进一步解释，请点击这里或推特:) @JasPanesar