CF项目变得太大，该怎么办？

如何解决CF项目变得太大，该怎么办？

| 一个简单的计费系统（在ColdBox MVC之上）正在膨胀为半企业库存+设置+问题跟踪+利润跟踪应用程序。他们似乎在做自己的事情，但他们却共享许多东西，包括一个通用的客户和员工库（登录名）以及其他混合的数据和业务逻辑。 您如何保持这样的系统模块化？从维护，可测试性和可重用性的角度来看？ 单个整体应用程序？ （即基本应用的新软件包） ColdBox模块？不确定如何使其“可安装”，以及它带来了什么好处。 Java Portlet？不知道，只是跳出框框思考 SOA体系结构？通过网络服务API调用？ 您想分享什么想法和/或经验吗？

解决方法

停止考虑技术（例如Java门户，ColdBox模块等），而专注于架构。我的意思是想象您如何向观察者解释您的系统。首先在白板上绘制一组代表每个部件的框-库存，客户，问题跟踪等...-然后使用线条显示这些系统之间的交互。这使您专注于关注点的分离，即像功能一样分组在一起。首先，不必担心UI，而只需关注算法和数据。 如果您正在谈论MVC，则该步骤将重点放在模型上。这项工作完成之后，困难的部分便是修改代码以符合该图（即模型）。为了真正理解该模型的外观，我建议阅读Eric Evans的“域驱动设计”。目标是建立一个可以通过依赖注入来管理其关系的模型。据推测，这将为您提供一组高级CFC（如果需要的话）以及基础业务实体和持久性管理。它们之间的关系最好由某种bean容器/服务定位器来管理，我相信ColdBean有它自己的定位器，另一个例子是ColdSpring。 这项工作的结果是可以单元测试的模型。独立于用户界面。如果这一切令人困惑，我建议您看一看如何有效地使用Legacy Code，以获取有关如何进行此过渡的一些想法。 设置好之后，现在就可以考虑控制器（例如ColdBox），并通过它将模型链接到视图。但是，请仔细研究任何控制器，并选择它，因为它可以为您的应用程序提供所需的功能（缓存是我想到的一个示例）。您可能还需要重新定义视图以与该新设计进行交互，但是您应该拥有的系统现在已将算法与UI分开，从而使视图的工作变得容易。 实际上，解决此问题的方式是迭代的。找到一个可以按照我所描述的方式轻松弄懂的系统，在单元测试中进行验证，同时与他人进行验证，然后继续使用下一个系统。尽管这是一个繁琐的过程，但是我可以保证，与尝试重写所有内容相比，它的工作量要少得多，除非您事先拥有非常好的一组自动验证，否则这将引发灾难。 更新资料 重申一下，这项技术不会解决您的问题。朝着更具凝聚力的对象的方向不断迭代。 现在，就耦合数据而言，使用ORM进行了权衡，单片系统确实具有其优势。另一种方法是通过DI给一个有状态实体一个对另一个服务对象的引用，以便您通过该对象来检索它。这将使您能够出于单元测试的目的对其进行模拟，并将其替换为类似的服务对象和相应的实体，以促进在其他上下文中的重用。 就解决业务问题（例如会计）而言，重用是一种新兴属性，您可以编写多个系统执行大致相同的操作，然后弄清楚如何进行概括。以我的经验，您很少会开始写一些东西来解决一些业务问题，这些问题会变成可重用的组件。,我建议您使用ColdBox模块将应用程序分成模块化的部分。您还可以将单独的业务逻辑研究到RESTful ColdBox层中，也可以通过这种方式加入系统。同样，这一切都取决于您当前的需求。 这些模块旨在将单片应用程序分解为更易于管理的部分，这些部分可以独立或耦合在一起。,我建议您花一些时间来研究模块。这将有助于将代码划分为逻辑功能，同时保留与模型的集成。 作为ColdBox，有大量的文档和示例... http://wiki.coldbox.org/wiki/Modules.cfm http://experts.adobeconnect.com/p21086674/,您需要摆脱MVC并将其替换为SOA体系结构，这样，将两个部分结合在一起的唯一事情就是服务请求。 因此，在服务器端，您具有DAO和FACADE层。客户端可以是MVC，也可以是您想在其他地方使用的任何体系结构。您甚至可以为每个不同的业务拥有一个单独的客户。 即使对于服务器端，您也可以将项目分解为多个服务器：所有业务之间的共同点，然后是所有业务之间的不同点。,幸运的是，我们在这里面临的问题不是唯一的。 这里的问题似乎不在于代码本身，也不在于如何将其分解，而是要了解您现在正在从事ERP设计和开发。 知道如何最好地开发和发展以逻辑方式管理该组织的详细信息的ERP是我想解决的更深层的问题。如何从中进行编码的设计和体系结构本身就是对所需核心功能领域的理解。 幸运的是，我们可以研究一些现有的ERP系统，以了解它们如何解决某些问题。有一些很好的开源ERP，而使我想到这个窍门的是我监督的SAP Business One I的全周期安装（中小型ERP，绕过了大型SAP的挑战）。 您正在寻找的是看到其他人如何解决您面临的相同的ERP体系结构。至少，您将了解模块化之间的权衡，在模块之间的界限以及原因。 通常，ERP系统处理从报价到生产（如果需要），开票，运输以及由此产生的会计工作等所有过程。 ERPS处理两个主要问题： 商品生产 提供服务 一些企业是小部件工厂，其他企业是服务企业。一个功能齐全的现成的ERP将具有一个“订单”的连续链/生命周期，该“订单”可以通过许多步骤进行维护。 如果我们阅读了ERP可以涵盖的步骤的粗略清单，您将看到适用于您的那些步骤。这些可能是您拥有的模块或应该将您的应用程序分解为的模块。想象一下以下步骤，每个步骤都是一个不同的文档，它们都与链中的上一个文档相连。 潜在客户生成->销售机会 销售机会->报价/估价 报价估算->销售订单 销售订单->生产订单（构建或安排某人进行工作） 生产订单->采购订单（订购所需材料或专家可在需要时到达） 生产订单->生产计划（什么时候建立，什么时候完成？ 生产时间表->生产！ （做工作） 生产的服务/货物->库存调整-如有需要，将任何原始库存转换为成品，或准备发货 成品/服务->装箱单 装箱单项目->发票 系统集成商介入的地方是使用所需的步骤，并跳过不使用的步骤。这为您不断增长的应用带来了一件事： 制定可靠的数据安全策略。确保您对每个人只能看到自己应该看到的内容感到满意。假设已安装好，最好将应用程序分解为主要部分。模块是我们的朋友。但是，将它们分解的顺序可能会对您的工作产生更大的影响。 查看哪些部分是通用的（报告等），可以在多个应用程序之间重复使用，哪些部分更适合于应用程序本身。与应用程序本身相关的功能可能已经更加紧密地结合在一起，您可能必须解决此问题。 对于ERP，我一直偏爱事务“核心”模块，所有其他事务提供程序都使用该模块（一旦定义了过程，便可以推动过程进行）。 当我将Lotus Notes ERP从90年代转换为SAP ERP时，Lotus Notes应用程序非常出色，它可以按需处理一切。这是一些在侧面构建的微型应用，这些微型应用没有作为模块集成，这是摆脱它的主要原因。 如果您今天按照今天的要求重新编写了该应用程序，那么您将如何做呢？看看与您有什么主要区别。让应用程序争取您的注意力，以便首先确定需要大修/模块化的内容。无论您是使用插件类型的模块，还是只是使用分隔良好的代码，ColdBox都是模块化的绝佳选择，它不会出错，它只是开发人员投入时间和金钱来完成它的功能。 我要构建/自动化单元测试的第一个模块是编程上最复杂的模块。如果您是一个体面的开发人员，那么从昨天开始您就不需要端到端单元测试。从最复杂的部分开始，移至应用程序的核心部分，然后扩展到可能使您彻夜难眠的任何其他区域。 希望能有所帮助！如果您不介意，请分享您最终会做的事情，如果我提到的任何事情需要进一步说明，请在此处或推特上打我：) @JasPanesar