Hi Taher,
I like the idea, Initially we can move all the entity-auto services to service-library, and slowly move other services that can be move to service-library. Thanks & Regards -- Deepak Dixit www.hotwaxsystems.com www.hotwax.co On Mon, Mar 5, 2018 at 5:05 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? > > 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 >
