That approach sounds very monolithic, and I tend to avoid monoliths.
I gave this subject a lot of thought about a year ago when I was working on a vision for a new framework (https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision). In particular, I was trying to devise a way for us to build a new architecture for OFBiz out of well-defined and self-contained parts - with the ultimate goal of using OSGI to connect them all together.
That goal led to only one pattern that seemed to work: Hub-and-spoke. Hubs can be suspended, replaced, and restarted without too much disruption because they affect only the spokes connected to them.
It sounds like what you're proposing is a layered pattern - like a wall built up of many bricks, but with an all-covering capstone on top.
I don't have a strong opinion on which approach is best, but I tend to favor modularity.
The discussion is worthwhile, and I appreciate you starting it. -Adrian On 3/14/2012 2:37 PM, Jacopo Cappellato wrote:
In the eraly days of the project, the OFBiz applications have been designed as independent components to make them more reusable and because they were designed to be a set of reusable and generic artifacts, each of them based on a specific domain of the data model (order, party, product etc...). They were not intended to be ready to be used out of the box; they were not intended to implement complete ERP workflows (mostly all complete real World workflows encompass several domains) but rather to provide some common artifacts (screens, forms, basic business rules) to facilitate the implementation of custom applications. However over the years, they have been implemented to be used as being part of the same big suite of ERP applications: i.e. the building blocks of a specific instance of an ERP system. Some (parts) of them have become "ready to be used" out of the box (for certain specific business models) by implementing more specific workflows (based on some real World requirements coming from companies): because of the fact that there was not a central design and coordination (which industry/business to implement etc...) and because for the same task (shipping, receiving etc...) there are thousands of different valid worflows we have now several workflows in OFBiz that implement similar features but in different alternative ways. It is off topic here to say if this is good (the company user can choose between a series of choices based on the nature of its business and then customize/clean/complete them) or bad (a lot of duplicated code, the applications seem to deal with everything but they are not really really good for anything): however it is a reality that the applications are now more a suite of ERP application (one application) rather than reusable generic artifacts that can be plugged together. In fact the OFBiz Applications are now a set of OFBiz components that are strictly interdependent at several layers (data model, service, ui). In their current status I believe that it would be better to merge them into one big component, the "Apache OFBiz ERP" (or a better name). The component will contain: * the complete data model for the OFBiz application * all the services (Java, Minilang) * all data * one web application (merged from the existing ones); even if initially we could do this in steps and keep them separated as they are now but under the same component * one aggregated and consolidated set of ui labels Even in one component we will have several mechanisms to categorize our artifacts (file names, folders) even if I would suggest to rethink them based on new rules (and only if we need the categorization). We could merge a lot of files (data preparation scripts, screen definitions, service definitions etc...) to make them more consistent. We would also resolve some of the issues with inter-application links and navigation. I am pretty sure that we could end up with less code and easier to organize and maintain. It will also be more practical to reuse this component and extend it from an external hot deploy component: you will have to extend one webapp and then reuse from the official component what you like. This is just the rough ideas and there could be some variants to it: we could isolate all the data model and services into one component and all the applications (ui, screens, controllers, data prep scripts and templates) into another one. etc. etc. etc... It is a lot of work but we are a big community and we like to keep us busy. What do you think? Jacopo
