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? 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. 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? 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? 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? 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
