You may think: “What the heck `hostable` means there? of course you have to host them somewhere?” true, true, but I mean something different here, you’ll see.
We all used (and is still heavy used) N-Tier Architectures. I don’t get along with them quite totally now, but it was fantastic. You organize application in layers that specializes in the kind of tasks performed in that layer.
The presentation layer is specialized in UI stuff to a user can interact with our app and it enforces usability, aesthetics etc. DataAccess Layer specializes in the details of interacting with a data source hence abstracting this tasks to upper layers. And so on with the others.
My problem with this over time was that for larger systems you end up with components from different domains of your model all mixed together.
The main reason for that is that developers tend to group them per their technical function rather than per their business or domain function. “This is data access work, have to go to the data access layer”, true, but that data access code for billing I don’t like to be mixed with user management, I just don’t like that mix.
I then split the design vertically into more domain oriented modules that each keep its layers inside, in a way to increase cohesion, organize and assign people more functionally in a way they can work top to bottom.
Using a relational database made it complex, sometimes impractical to logically and physically separate those domains as dependencies increases specially at database level. But later on, I started using noSql approaches and mixed SQL and noSql in the same system and that was the perfect moment to split the architecture as I wanted.
Now each module is entirely independent, has it’s own entities, it’s own data access, it’s own data store (it could be SQL, it could be Document Oriented) it’s own repositories, it’s own migrations, it’s own services, it’s own startup code etc.. Services and entities are exposed for other modules to use.
All modules shares vertical services like common data access generic code, utilities, security, logging, telemetry, configuration…
This architecture worked really well, it is physically and logically separated, it helps in understanding the system complexity, helps with the “where things are” onboarding questions, and most of all: I can choose to host them in side a webAPI project and expose business service’s functionality through a rest API and scale them independently.
Is that a microservice architecture? I definitely can be, and it definitely is, but it’s “hostable” microservices as they are not yet physically deployed to independent hosts that you can scale separately, they are referenced via project reference and consumed via instantiation rather than HTTP calls.
Good thing for me is the option to convert them to the now called microservices, (which I have successfully done for some modules specially the auth ones) or keep referencing them and avoid latency
Look at 3 hostable microservices our clients portal has:
And an inner look of one of them
This is the billing module using SQL storage. Where’s the presentation layer? Presentation has become so rich and complex now that they are an app on their own with it’s own architecture, let’s examine an angular front end app that would serve for all those components how it would look like in another post soon.