I've read and enjoyed the "Clean Architecture" book. So the first thing I tried to do is to implement my project with it.

Where I work we follow a design method called IDesign in which the architecture is broken into:

  1. "clients" - encapsulate communication with consumers (e.g. UI)
  2. "managers" - manages business flows (drives use cases)
  3. "engines" - stateless computational components (not always needed)
  4. "resource accesses" - encapsulates accesses to data sources

A component of each type is logically a service so I was trying to treat each one as a component in "Clean Architecture". What I'm having a hard time with is this.

RA (Resource access) component is clearly low level so manager for instance should not depend on it.

We can have multiple managers and engines using the same RA so according to my favorite uncle each should define its own interface and the RA component should implement all of them.

What I cannot understand is, if I'll want to make the RA component into a micro-service, how would its API look?

I'm trying to follow this approach in a NodeJS project which makes it even harder for me to grasp how to implement such a solution..

The best I could up with so far is to have a single API for the RA and on each engine/manager to have internal onion architecture approach in which a repository layer class is implementing a "Use Case" layer interface and calls the RA API (in memory at first stage, through network potentially in the future).

Another thing I struggled with is the entity objects. should the RA service map to them when returning response? Again it makes sense when this is the same process but between micro services I'm not so sure...

  • Is RA's function to map a request to a resource that can fulfill it or something more? – candied_orange Mar 25 '19 at 0:00
  • RA's responsibility is to encapsulate everything related to to data access. It could handle for instance - throttling, transactions, query building, data scoping, auditing, connection to DB etc. – Tal Joffe Mar 25 '19 at 8:00
  • 1
    Just a question. Is it your intention to make this "service" the data source for the others (services)? If yes, it would be good for you to re-think why you want to do this in this way, It's very contrary to the MS philosophy because this service will become into a point of heavy coupling. On the other hand, I would not trust any answer that basically suggests swinging against the current. – Laiv Mar 25 '19 at 10:05
  • I'm with laiv. That's too much for a micro service. It's too much for a component. It reminds me of the service locator pattern. Unless you're being crippled by some framework that forces you to work this way consider a redesign. – candied_orange Mar 25 '19 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.