当前位置：文江博客话题详情

CF项目太大了，怎么办？

发布于 2024-11-02 07:34:37 字数 464 浏览 1 评论 0原文

一个简单的计费系统（在 ColdBox MVC 之上）正在扩展为一个半企业库存 + 供应 + 问题跟踪 + 利润跟踪应用程序。他们似乎在做自己的事情，但他们共享许多东西，包括共同的客户和员工池（登录名），以及其他混合数据和信息。业务逻辑。

如何保持这样的系统模块化？从维护、可测试性和可重用性的立场？

单个整体应用程序？（即基本应用程序的新包）
ColdBox 模块？不确定如何使其“可安装”以及它带来什么好处。
Java Portlet？不知道，只是跳出框框思考
SOA 架构？通过Web服务API调用？

您有什么想法和/或经验想分享吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

却一份温柔 2024-11-09 07:34:38

幸运的是，我们面临的问题并不是独一无二的。

这里的问题似乎不是代码本身，或者如何分解它，而是要了解您现在正在从事 ERP 设计和开发。

了解如何最好地开发和发展 ERP，以逻辑方式管理该组织的细节是我认为您想要解决的更深层次的问题。如何编码的设计和架构本身源于对您所需的核心功能领域的理解。

幸运的是，我们可以研究一些现有的 ERP 系统，看看它们是如何解决一些问题的。有一些很好的开源 ERP，让我想到这一建议的是我监督的 SAP Business One（一种绕过大型 SAP 挑战的中小型 ERP）的全周期安装。

您需要了解其他人如何解决您面临的相同 ERP 架构。至少您会了解模块化之间的权衡、模块之间的界限以及原因。

通常，ERP 系统会处理从报价、生产（如果需要）、计费、运输以及由此产生的会计工作的所有事务。

ERPS 处理两个主要领域：

货物生产
服务交付

有些企业是小部件工厂，其他企业是服务企业。一个功能齐全的开箱即用 ERP 将具有一个“订单”的连续链/生命周期，并通过多个步骤提供服务。

如果我们阅读 ERP 可以涵盖的步骤的粗略列表，您将看到适用于您的步骤。这些可能是您拥有或应该将您的应用程序分解为的模块。想象一下以下步骤，其中每个步骤都是不同的文档，所有步骤都连接到链中的前一个文档。

潜在客户开发 -->销售机会
销售机会 -->报价/预估
报价预估 -->销售订单
销售订单 -->生产订单（构建它，或安排某人来做这项工作）
生产订单 -->采购订单（订购所需材料或需要时专家到达）
生产订单 -->生产计划（将建造什么，何时，或谁将完成此任务，何时？）
生产计划 -->生产！（完成工作）
提供的服务/良好的 -->库存调整 - 如果需要，将任何原始库存转换为成品，或准备
好运送成品/服务 -->装箱单
装箱单项目 -->发票

系统集成商介入的地方是使用所需的步骤，并跳过未使用的步骤。对于不断增长的应用程序来说，这会带来一件事：

制定可靠的数据安全策略。确保每个人都只能看到他们应该看到的内容，这让您感到放心。假设已经到位，最好将应用程序分成几个主要部分。模块是我们的朋友。然而，将它们分解的顺序可能对你所做的事情产生比任何事情都更大的影响。

查看哪些部分是通用的（报告等），可以在多个应用程序之间重复使用，哪些部分更适合应用程序本身。与应用程序本身相关的功能可能已经更加紧密地耦合，您可能必须解决这个问题。

对于 ERP，我一直更喜欢事务性“核心”模块，所有其他事务提供商都使用该模块（一旦定义，计费就会推动流程）。

当我将 Lotus Notes ERP 从 90 年代转换为 SAP ERP 时，Lotus Notes 应用程序非常出色，它按照应有的方式处理了所有事情。有一些构建在侧面的迷你应用程序没有集成为模块，这是摆脱它的主要原因。

如果您今天根据今天的要求重新编写该应用程序，您会如何做？看看与您拥有的是否有任何重大差异。让应用程序争取您的注意力，以决定哪些内容首先需要检修/模块化。 ColdBox 非常适合模块化，无论您是使用插件类型模块还是仅使用分离良好的代码，您都不会出错，这只是开发人员完成任务所需的时间和金钱的函数。

我构建/自动化单元测试的第一个模块在编程上是最复杂的。如果您是一名优秀的开发人员，那么您可能不需要从昨天开始进行端到端单元测试。从最复杂的部分开始，转到应用程序的核心部分，然后扩展到任何其他可能让您彻夜难眠的区域。

希望有帮助！如果您不介意的话，请分享您最终会做什么，如果我提到的任何内容需要进一步解释，请在此处或 Twitter 上联系我:)
@JasPanesar

The problem we're facing here luckily isn't unique.

The issue here seems not to be the code itself, or how to break it apart, but rather to understand that you're now into ERP design and development.

Knowing how best to develop and grow an ERP which manages the details of this organization in a logical manner is the deeper question I think you're trying to get at. The design and architecture itself of how to code from this flows from an understanding of the core functional areas you need.

Luckily we can study some existing ERP systems you can get a hold of to see how they tackled some of the problems. There's a few good open source ERP's, and what brought this tip to my mind is a full cycle install of SAP Business One I oversaw (a small-mid size ERP that bypasses the challenges of the big SAP).

What you're looking for is seeing how others are solving the same ERP architecture you're facing. At the very least you'll get an idea of the tradeoffs between modularization, where to draw the line between modules and why.

Typically an ERP system handles everything from the quote, to production (if required), to billing, shipping, and the resulting accounting work all the way through out.

ERPS handle two main worlds:

Production of goods
Delivery of service

Some businesses are widget factories, others are service businesses. A full featured out of the box ERP will have one continuous chain/lifecycle of an "order" which gets serviced by a number of steps.

If we read a rough list of the steps an ERP can cover, you'll see the ones that apply to you. Those are probably the modules you have or should be breaking your app into. Imagine the following steps where each is a different document, all connected to the previous one in the chain.

Lead Generation --> Sales Opportunities
Sales Opportunities --> Quote/Estimate
Quote Estimate --> Sales Order
Sales Order --> Production Order (Build it, or schedule someone to do the work)
Production order --> Purchase orders (Order required materials or specialists to arrive when needed)
Production Order --> Production Scheduling (What will be built, when, or Who will get this done, when?)
Production Schedule --> Produce! (Do the work)
Produced Service/Good --> Inventory Adjustments - Convert any raw inventory to finished goods if needed, or get it ready to ship
Finished Good/Service --> Packing Slip
Packing Slip items --> Invoice

Where system integrators come in is using the steps required, and skipping over the ones that aren't used. This leads to one thing for your growing app:

Get a solid data security strategy in place. Make sure you're confortable that everyone can only see what they should. Assuming that is in place, it's a good idea to break apart the app into it's major sections. Modules are our friends. The order to break them up in, however, will likely have a larger effect on what you do than anything.

See which sections are general, (reporting, etc) that could be re-used between multiple apps, and which are more specialized to the application itself. The features that are tied to the application itself will likely be more tightly coupled already and you may have to work around that.

For an ERP, I have always preferred a transactional "core" module, which all the other transaction providers (billing pushing the process along once it is defined).

When I converted a Lotus Notes ERP from the 90's to the SAP ERP, the Lotus Notes app was excellent, it handled everything as it should. THere were some mini-apps built on the side that weren't integrated as modules which was the main reason to get rid of it.

If you re-wrote the app today, with today's requirements, how would you have done it differently? See if there's any major differences from what you have. Let the app fight for your attention to decide what needs overhauling / modularization first. ColdBox is wonderful for modularization, whether you're using plugin type modules or just using well separated code you won't go wrong with it, it's just a function of developer time and money available to get it done.

The first modules I'd build / automate unit testing on are the most complex programatically. Chances are if you're a decent dev, you don't need end to end unit testing as of yesterday. Start with the most complex, move onto the core parts of the app, and then spread into any other areas that may keep you up at night.

Hope that helped! Share what you end up doing if you don't mind, if anything I mentioned needs further explanation hit me up on here or twitter :)
@JasPanesar

回复收藏 0 原文

dawn曙光 2024-11-09 07:34:37

我建议您使用 ColdBox 模块将应用程序分解为模块化部分。您还可以将单独的业务逻辑研究到 RESTful ColdBox 层中，并以这种方式加入系统。同样，这完全取决于您目前的要求和需求。

模块旨在将整体应用程序分解为更易于管理的部分，这些部分可以独立或耦合在一起。

回复收藏 0 原文

不…忘初心 2024-11-09 07:34:37

停止考虑技术（例如 Java Portal、ColdBox 模块等）并专注于架构。我的意思是想象一下如何向观察者解释你的系统。首先在白板上绘制一组代表每个部分（库存、客户、问题跟踪等）的方框，然后使用线条显示这些系统之间的交互。这会让您关注关注点分离，即将类似的功能分组在一起。首先不要担心用户界面，而是关注算法和数据。

如果我们谈论 MVC，那么该步骤的重点是模型。随着该活动的完成，困难的部分来了，修改代码以符合该图（即模型）。要真正理解这个模型应该是什么样子，我建议阅读领域驱动设计埃里克·埃文斯。目标是建立一个模型，其关系可以通过依赖注入进行管理。据推测，这将为您留下一组高级 CFC（如果您愿意的话，可以提供服务）以及底层业务实体和持久性管理。他们的关系最好通过某种bean容器/服务定位器来管理，我相信ColdBox有自己的，另一个例子是ColdSpring。

这项工作的结果是一个可进行单元测试的模型。独立于用户界面。如果所有这些都令人困惑，我建议看看有效地使用旧代码，了解有关如何进行此转换的一些想法。

一旦你完成了这个，现在就可以考虑一个控制器（例如ColdBox）并通过它将模型链接到视图。然而，请仔细研究任何控制器并选择它，因为它为您的应用程序带来了一些功能（我想到的一个例子是缓存）。您的视图可能还需要重新构想才能与这个新设计交互，但您应该拥有一个算法现在与 UI 分离的系统，从而使视图的工作变得容易。

实际上，解决这个问题的方法是迭代。找到一个可以按照我描述的方式轻松梳理出来的系统，对其进行单元测试，与人们一起验证，然后继续下一个系统。虽然这是一个乏味的过程，但我可以保证，这比尝试重写所有内容要少得多，否则会带来灾难，除非您提前有一套非常好的自动验证。

更新

重申一下，技术并不能解决你的问题。持续迭代将朝着更具凝聚力的对象发展。

现在就耦合数据而言，您已经通过 ORM 进行了权衡，而单体系统确实有其优点。另一种方法是通过 DI 为一个有状态实体提供对另一个服务对象的引用，以便您通过该实体检索它。这将使您能够出于单元测试的目的而模拟它，并将其替换为类似的服务对象和相应的实体，以便于在其他上下文中重用。

在解决业务问题（例如会计）方面，重用是一种新兴的属性，您可以编写多个系统来完成大致相同的事情，然后弄清楚如何进行泛化。根据我的经验，您很少会开始编写一些东西来解决一些成为可重用组件的业务问题。

Stop thinking about technology (e.g. Java Portals, ColdBox modules, etc...) and focus on architecture. By this I mean imagining how you can explain your system to an observer. Start by drawing a set of boxes on a whiteboard that represent each piece - inventory, clients, issue tracking, etc... - and then use lines to show interactions between those systems. This focuses you on a separation of concerns, that is grouping together like functionality. To start don't worry about the UI, instead focus on algorithms and data.

If you we're talking about MVC, that step is focusing on the model. With that activity complete comes the hard part, modifying code to conform to that diagram (i.e the model). To really understand what this model should look like I suggest reading Domain Driven Design by Eric Evans. The goal is arriving at a model whose relationships are manageable via dependency injection. Presumably this leaves you with a set of high level CFCs - services if you will - with underlying business entities and persistence management. Their relationships are best managed by some sort of bean container / service locator, of which I believe ColdBox has its own, another example is ColdSpring.

The upshot of this effort is a model that's unit testable. Independent of of the user interface. If all of this is confusing I'd suggest taking a look at Working Effectively with Legacy Code for some ideas on how to make this transition.

Once you have this in place it's now possible to think about a controller (e.g. ColdBox) and linking the model to views through it. However, study whatever controller carefully and choose it because of some capability it brings to the table that your application needs (caching is an example that comes to mind). Your views will likely need to be reimagined as well to interact with this new design, but what you should have is a system where the algorithms are now divorced from the UI, making the views' job easy.

Realistically, the way you tackle this problem is iteratively. Find one system that can easily be teased out in the fashion I describe, get it under unit tests, validate with people as well, and continue to the next system. While a tedious process, I can assure it's much less work than trying to rewrite everything, which invites disaster unless you have a very good set of automated validation ahead of time.

Update

To reiterate, the tech is not going to solve your problem. Continued iteration toward more cohesive objects will.

Now as far as coupled data, with an ORM you've made a tradeoff, and monolithic systems do have their benefits. Another approach would be giving one stateful entity a reference to another's service object via DI, such that you retrieve it through that. This would enable you to mock it for the purpose of unit testing and replace it with a similar service object and corresponding entity to facilitate reuse in other contexts.

In terms of solving business problems (e.g. accounting) reuse is an emergent property where you write multiple systems that do roughly the same thing and then figure out how to generalize. Rarely if ever in my experience do you start out writing something to solve some business problem that becomes a reusable component.

回复收藏 0 原文