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" <p...@cohsoft.com.au> 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: +61 3 9585 6788
Web: http://www.coherentsoftware.com.au/
Email: i...@coherentsoftware.com.au

Reply via email to