[Discussion] Creating a unified service-library component

[taher]

Hello Everyone,

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 ...)
- They are independent of the user interface. In fact you can make
multiple interfaces that share the same data model and services.
- 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?

Cheers,

Taher Alkhateeb

[Paul Foxworthy]

On 5 March 2018 at 00:45, Taher Alkhateeb <[hidden email]>
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: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[Deepak Dixit-3]

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 <[hidden email]> wrote:

> On 5 March 2018 at 00:45, Taher Alkhateeb <[hidden email]>
> 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: [phone]
> Web: http://www.coherentsoftware.com.au/
> Email: [hidden email]
>

[taher]

Hi Paul, Good points and questions. Inline ...

On Mar 5, 2018 2:36 AM, "Paul Foxworthy" <[hidden email]> wrote:

On 5 March 2018 at 00:45, Taher Alkhateeb <[hidden email]>
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: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[Rishi Solanki]

+1 for the idea for having services at top and then use them whenever
required, the only thing comes in my mind (also mentioned by Paul in the
thread) what to do with the cross component services. Also once the
services moved then how to customize them as per requirements. But we can
finalize the things as we move.

We can go slowly and move the items in following sequence to be on safer
side (better advise from community most welcome);

1) Entity Auto Services and service interfaces (with dependency check)
2) Other Crud Services
3) Other services in order of component-load

In most cases we don't have to worry about the order of services load, but
it would be good to follow some practice to work independently for
components.

The best thing I can see here, once we have everything comes out as Map we
can use any UI technology to work with OFBiz and can have our own UI
independent on OFBiz other components. So again big +1.

I would like to help/work on this effort, LMK.


Thanks!



Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com
www.hotwax.co

On Mon, Mar 5, 2018 at 10:57 AM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Paul, Good points and questions. Inline ...
>
> On Mar 5, 2018 2:36 AM, "Paul Foxworthy" <[hidden email]> wrote:
>
> On 5 March 2018 at 00:45, Taher Alkhateeb <[hidden email]>
> 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: [phone]
> Web: http://www.coherentsoftware.com.au/
> Email: [hidden email]
>

[Paul Foxworthy]

Thanks Taher, I agree with your idea.

I agree that most services can and should be decoupled from user
interfaces. As you say if a service exists only to support a UI, it can
stay with the UI component. Services that only make sense to support AJAX
calls would be one example.

If most services move somewhere else, should there be one monolithic
component, or several? So where we now have accounting, content and so on,
would we have accounting-ui, accounting, content-ui, content and so on?
Possibly accounting-services, accounting-ui etc, but -services is
long-winded and I think not very useful.

Cheers

Paul Foxworthy

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[taher]

Hi Paul,

Yeah I am proposing one big component to house all services. The reason is
that it makes no sense in separating them because they are tightly coupled
and depend on each other heavily (because they share the full data model)

As I mentioned in my first email, we can perhaps create a new component and
call it "service-library". Inside this component we follow a similar
pattern to the datamodel component in organizing the files.

To me the big win out of this move is that all the complexity we have right
now in figuring out the dependencies between components almost completely
goes away. Remember that big spaghetti diagram in the wiki for component
dependencies? We get rid of that.

Did I understand your question correctly and WDYT?

On Mar 7, 2018 5:45 AM, "Paul Foxworthy" <[hidden email]> wrote:

Thanks Taher, I agree with your idea.

I agree that most services can and should be decoupled from user
interfaces. As you say if a service exists only to support a UI, it can
stay with the UI component. Services that only make sense to support AJAX
calls would be one example.

If most services move somewhere else, should there be one monolithic
component, or several? So where we now have accounting, content and so on,
would we have accounting-ui, accounting, content-ui, content and so on?
Possibly accounting-services, accounting-ui etc, but -services is
long-winded and I think not very useful.

Cheers

Paul Foxworthy

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[Paul Foxworthy]

On 7 March 2018 at 16:57, Taher Alkhateeb <[hidden email]>
wrote:

> Yeah I am proposing one big component to house all services. The reason is
> that it makes no sense in separating them because they are tightly coupled
> and depend on each other heavily (because they share the full data model)
>
> As I mentioned in my first email, we can perhaps create a new component and
> call it "service-library". Inside this component we follow a similar
> pattern to the datamodel component in organizing the files.
>
> To me the big win out of this move is that all the complexity we have right
> now in figuring out the dependencies between components almost completely
> goes away. Remember that big spaghetti diagram in the wiki for component
> dependencies? We get rid of that.
>
> Did I understand your question correctly and WDYT?
>

You did understand correctly and I think I agree.

Would there be folders for human understanding and some organisation, but
without them defining separate components?

Thanks

Paul Foxworthy

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Australia

Phone: [phone]
Web: http://www.coherentsoftware.com.au/
Email: [hidden email]

[taher]

Yes possibly folders, and more likely just file names. For example:

service-library/
├── ofbiz-component.xml
└── services
    ├── accounting-services.xml
    ├── content-services.xml
    ├── humanres-services.xml
    ├── manufacturing-services.xml
    ├── marketing-services.xml
    ├── order-services.xml
    ├── party-services.xml
    ├── product-services.xml
    ├── shipment-services.xml
    └── workeffort-services.xml

On Wed, Mar 7, 2018 at 3:27 PM, Paul Foxworthy <[hidden email]> wrote:

> On 7 March 2018 at 16:57, Taher Alkhateeb <[hidden email]>
> wrote:
>
>
>> Yeah I am proposing one big component to house all services. The reason is
>> that it makes no sense in separating them because they are tightly coupled
>> and depend on each other heavily (because they share the full data model)
>>
>> As I mentioned in my first email, we can perhaps create a new component and
>> call it "service-library". Inside this component we follow a similar
>> pattern to the datamodel component in organizing the files.
>>
>> To me the big win out of this move is that all the complexity we have right
>> now in figuring out the dependencies between components almost completely
>> goes away. Remember that big spaghetti diagram in the wiki for component
>> dependencies? We get rid of that.
>>
>> Did I understand your question correctly and WDYT?
>>
>
> You did understand correctly and I think I agree.
>
> Would there be folders for human understanding and some organisation, but
> without them defining separate components?
>
> Thanks
>
> Paul Foxworthy
>
> --
> Coherent Software Australia Pty Ltd
> PO Box 2773
> Cheltenham Vic 3192
> Australia
>
> Phone: [phone]
> Web: http://www.coherentsoftware.com.au/
> Email: [hidden email]

[taher]

Thank you all for your kind feedback.

I gathered in here 3 generally positive replies to the proposal. I
will create a JIRA for this task for which volunteers are _highly_
appreciated. Thank you Rishi also for stepping in.

I do not fancy lazy consensus in important design decisions, so some
additional voices and opinions would also be great. If you have any
concerns or questions I'd love to hear them.

On Wed, Mar 7, 2018 at 4:15 PM, Taher Alkhateeb
<[hidden email]> wrote:

> Yes possibly folders, and more likely just file names. For example:
>
> service-library/
> ├── ofbiz-component.xml
> └── services
>     ├── accounting-services.xml
>     ├── content-services.xml
>     ├── humanres-services.xml
>     ├── manufacturing-services.xml
>     ├── marketing-services.xml
>     ├── order-services.xml
>     ├── party-services.xml
>     ├── product-services.xml
>     ├── shipment-services.xml
>     └── workeffort-services.xml
>
> On Wed, Mar 7, 2018 at 3:27 PM, Paul Foxworthy <[hidden email]> wrote:
>> On 7 March 2018 at 16:57, Taher Alkhateeb <[hidden email]>
>> wrote:
>>
>>
>>> Yeah I am proposing one big component to house all services. The reason is
>>> that it makes no sense in separating them because they are tightly coupled
>>> and depend on each other heavily (because they share the full data model)
>>>
>>> As I mentioned in my first email, we can perhaps create a new component and
>>> call it "service-library". Inside this component we follow a similar
>>> pattern to the datamodel component in organizing the files.
>>>
>>> To me the big win out of this move is that all the complexity we have right
>>> now in figuring out the dependencies between components almost completely
>>> goes away. Remember that big spaghetti diagram in the wiki for component
>>> dependencies? We get rid of that.
>>>
>>> Did I understand your question correctly and WDYT?
>>>
>>
>> You did understand correctly and I think I agree.
>>
>> Would there be folders for human understanding and some organisation, but
>> without them defining separate components?
>>
>> Thanks
>>
>> Paul Foxworthy
>>
>> --
>> Coherent Software Australia Pty Ltd
>> PO Box 2773
>> Cheltenham Vic 3192
>> Australia
>>
>> Phone: [phone]
>> Web: http://www.coherentsoftware.com.au/
>> Email: [hidden email]

[Nicolas Malin-2]

Hello Taher, I will reply to this thread please give me sometime :)

Nicolas


On 13/03/2018 16:03, Taher Alkhateeb wrote:

> Thank you all for your kind feedback.
>
> I gathered in here 3 generally positive replies to the proposal. I
> will create a JIRA for this task for which volunteers are _highly_
> appreciated. Thank you Rishi also for stepping in.
>
> I do not fancy lazy consensus in important design decisions, so some
> additional voices and opinions would also be great. If you have any
> concerns or questions I'd love to hear them.
>
> On Wed, Mar 7, 2018 at 4:15 PM, Taher Alkhateeb
> <[hidden email]> wrote:
>> Yes possibly folders, and more likely just file names. For example:
>>
>> service-library/
>> ├── ofbiz-component.xml
>> └── services
>>      ├── accounting-services.xml
>>      ├── content-services.xml
>>      ├── humanres-services.xml
>>      ├── manufacturing-services.xml
>>      ├── marketing-services.xml
>>      ├── order-services.xml
>>      ├── party-services.xml
>>      ├── product-services.xml
>>      ├── shipment-services.xml
>>      └── workeffort-services.xml
>>
>> On Wed, Mar 7, 2018 at 3:27 PM, Paul Foxworthy <[hidden email]> wrote:
>>> On 7 March 2018 at 16:57, Taher Alkhateeb <[hidden email]>
>>> wrote:
>>>
>>>
>>>> Yeah I am proposing one big component to house all services. The reason is
>>>> that it makes no sense in separating them because they are tightly coupled
>>>> and depend on each other heavily (because they share the full data model)
>>>>
>>>> As I mentioned in my first email, we can perhaps create a new component and
>>>> call it "service-library". Inside this component we follow a similar
>>>> pattern to the datamodel component in organizing the files.
>>>>
>>>> To me the big win out of this move is that all the complexity we have right
>>>> now in figuring out the dependencies between components almost completely
>>>> goes away. Remember that big spaghetti diagram in the wiki for component
>>>> dependencies? We get rid of that.
>>>>
>>>> Did I understand your question correctly and WDYT?
>>>>
>>> You did understand correctly and I think I agree.
>>>
>>> Would there be folders for human understanding and some organisation, but
>>> without them defining separate components?
>>>
>>> Thanks
>>>
>>> Paul Foxworthy
>>>
>>> --
>>> Coherent Software Australia Pty Ltd
>>> PO Box 2773
>>> Cheltenham Vic 3192
>>> Australia
>>>
>>> Phone: [phone]
>>> Web: http://www.coherentsoftware.com.au/
>>> Email: [hidden email]

[Michael Brohl-3]

Let me join in here, Nicolas. I'd like to think about this but had not
the time yet.

Michael

Am 13.03.18 um 16:41 schrieb Nicolas Malin:

> Hello Taher, I will reply to this thread please give me sometime :)
>
> Nicolas
>
>
> On 13/03/2018 16:03, Taher Alkhateeb wrote:
>> Thank you all for your kind feedback.
>>
>> I gathered in here 3 generally positive replies to the proposal. I
>> will create a JIRA for this task for which volunteers are _highly_
>> appreciated. Thank you Rishi also for stepping in.
>>
>> I do not fancy lazy consensus in important design decisions, so some
>> additional voices and opinions would also be great. If you have any
>> concerns or questions I'd love to hear them.
>>
>> On Wed, Mar 7, 2018 at 4:15 PM, Taher Alkhateeb
>> <[hidden email]> wrote:
>>> Yes possibly folders, and more likely just file names. For example:
>>>
>>> service-library/
>>> ├── ofbiz-component.xml
>>> └── services
>>>      ├── accounting-services.xml
>>>      ├── content-services.xml
>>>      ├── humanres-services.xml
>>>      ├── manufacturing-services.xml
>>>      ├── marketing-services.xml
>>>      ├── order-services.xml
>>>      ├── party-services.xml
>>>      ├── product-services.xml
>>>      ├── shipment-services.xml
>>>      └── workeffort-services.xml
>>>
>>> On Wed, Mar 7, 2018 at 3:27 PM, Paul Foxworthy <[hidden email]>
>>> wrote:
>>>> On 7 March 2018 at 16:57, Taher Alkhateeb <[hidden email]>
>>>> wrote:
>>>>
>>>>
>>>>> Yeah I am proposing one big component to house all services. The
>>>>> reason is
>>>>> that it makes no sense in separating them because they are tightly
>>>>> coupled
>>>>> and depend on each other heavily (because they share the full data
>>>>> model)
>>>>>
>>>>> As I mentioned in my first email, we can perhaps create a new
>>>>> component and
>>>>> call it "service-library". Inside this component we follow a similar
>>>>> pattern to the datamodel component in organizing the files.
>>>>>
>>>>> To me the big win out of this move is that all the complexity we
>>>>> have right
>>>>> now in figuring out the dependencies between components almost
>>>>> completely
>>>>> goes away. Remember that big spaghetti diagram in the wiki for
>>>>> component
>>>>> dependencies? We get rid of that.
>>>>>
>>>>> Did I understand your question correctly and WDYT?
>>>>>
>>>> You did understand correctly and I think I agree.
>>>>
>>>> Would there be folders for human understanding and some
>>>> organisation, but
>>>> without them defining separate components?
>>>>
>>>> Thanks
>>>>
>>>> Paul Foxworthy
>>>>
>>>> --
>>>> Coherent Software Australia Pty Ltd
>>>> PO Box 2773
>>>> Cheltenham Vic 3192
>>>> Australia
>>>>
>>>> Phone: [phone]
>>>> Web: http://www.coherentsoftware.com.au/
>>>> Email: [hidden email]
>