Hi Paul, Good points and questions. Inline ... On Mar 5, 2018 2:36 AM, "Paul Foxworthy" <p...@cohsoft.com.au> wrote:
On 5 March 2018 at 00:45, Taher Alkhateeb <slidingfilame...@gmail.com> wrote: > I think If you look at both the "data model" and "services" in OFBiz > you will notice the following: > > - They are highly coupled and everything is connected to everything > (orders, parties, work efforts, contents, etc ...) > - Some services and entity models are component-specific and do not > belong to the generic data models and services. > > So what does that mean? It means in order to achieve real flexibility > and a clean architecture, perhaps we need to separate our data model > and services from the rest of the components in the system, and we > already did this with the datamodel component. > > So I propose creating a new component, perhaps calling it > "service-library" that houses all "generic" services that operate on > the "generic" data model. I propose we implement this new component as > follows: > > - Slowly move services (one at a time) from components to this central > library, cleaning and refactoring as we move. > - Migrate any minilang services to another engine while moving > (groovy, entityauto, etc ...) > - Keep any services that are component-specific and do not operate on > the generic data model in the component > > What do you think? Do you agree with the general idea? Can we do this > in a better way? Anyone interested in helping out? > Hi Taher, It is the nature of a business process to cross many functional areas. To fulfil an order, we might need to commission manufacturing involving people and equipment, order from suppliers, manage inventory, schedule shipments and create accounting records. What proportion of services do you think would turn out to be generic? Perhaps most of them. What I mean by generic is that they act on the datamodel or apply wide scoped logic. In other words, any service that does not need to exist if you delete a component would be tightly coupled to that component and should probably stay there. Any OFBiz implementor can add SECAs which cross component boundaries, when the original design of a service did not anticipate that. Do we still want to allow that? If so, the split between "generic" and "component-specific" is only approximate, and adding SECAs will blur the distinction. I think perhaps most SECAs could move too. After all SECAs are just forming a call graph indirectly. And if you call any service from any component the SECAs would always apply no? If most services move to be generic, there will be one component with many tightly-coupled services, and we'll have lost some partitioning and organisation. So will we have gained anything? Could we think of services as being partitioned into components only for the purpose of rough categorisation and human understanding, and for no technical or communication reason? Well, just like in the data model component, we can have directories to split the services by category. If a component-specific service is modified to be slightly more complex or general, so it now interacts with generic services or services in other components, does that mean it should move to be generic? As we extend OFBiz to be more capable, would there be a drift of services from one component to generic? Hmmm, perhaps as I mentioned earlier, I think only a tiny minority of services would remain (if any) just like in the data model. For example we only keep data related to portals and security permissions in components because they are tightly coupled to the user interface and should not exist if the component is gone. The rest is all in the data model. A similar thing could apply to services too. Would a better approach be to reduce the number of entry points between components, to better manage and understand the critical services that are called by other components? In other words, is there the possibility of encapsulation, so many simpler services are only used within one component, while others are larger in scope? To take that a step further, could your idea of generic services turn out to be big cross-component business processes, which *only* call into smaller services within several components, and contain no business logic of their own? Perhaps before I reply to this point let me try to clarify _why_ am I proposing what I propose. Imagine you wanted to create a better accounting component, or imagine you create a cross-functional component that is a full application and you called it "OFBiz retail app" that covers functionality across many entities (orders, GL, party, inventory, etc...). Under my proposal, these new components will not depend on any other components. They will only depend on the data model and service library. So the pain point of this very complex wiring between components will be significantly reduced. So under this proposal OFBiz will be a more layered architecture where the lower layers are isolated from higher layers as follow: - framework for low level infrastructure - data model and service library - applications - plugins I am hoping that perhaps creating the service library would be the first step towards refactoring the core applications. We would be able if we want to reconsider the design of how we split apps (party, work effort, content, etc..). Perhaps in the future we can separate apps by business, not data model e.g. Service company app, retail company app, ecommerce app, manufacturing company app, and so on. TIA Paul Foxworthy -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Australia Phone: +61 3 9585 6788 Web: http://www.coherentsoftware.com.au/ Email: i...@coherentsoftware.com.au
