Skip to main content

C4 ExMan Sample Solution

warning

You do not find this in the sidebar and you will not. You must earn your path here 👺

Context

ExMan context

This context is the result of RME work. It is the basis of the model we make below (together with further information from RME transfer tasks).

Container diagram

Requirements

QR-003 UI

Covered with the ExMan Web App (which is not part of this lecture but more of WEG (Web Engineering).

QR-004 Location agnostic

ExMan Web App is a hosted web app, accessible from any location with access to the internet.

QR-004 Permission based

Permissions are managed from an external service Identity Provider (which one is to be defined later).

QR-002 Modularity

ExMan API starts out as monolith. In the current scope there is no advocation for using any for of microservices. The ExMan API is the domain owner of expeditions. This domain currently is small enough to not split the service up in any kind. Since it uses proper abstraction and hexagonal design it will not be problematic to split off some domains in future scenarios (e.g. HR component).

Component diagram

ExMan API manages the following domain:

ExMan API domain

Explanations

Monolithic approach

The current domain could be split up into the domains Skill, Person and Expedition. While this is architecturally a perfect and legit option, for the skill set of our developers its not. Also, the current scope is yet too small to already split the service up. The overhead of writing three APIs between the services is additionally luring us away from a microservice architecture.

Split the monolith!

If one sleeps over the tipping point of a monolith split, one pays an enormous price. To avoid this disaster we take the following risk mitigation:

  • Proper and strict isolation of contexts (separation of concerns) allow an easier split later - no 🍝 code, no randomly calling other out-of-layer entities
    • Code reviews and pair programming will ensure that contexts are not violated
  • Hexagonal architecture provides us means to later exchange a DB repository with a remote repository fetching skills instead from a DB from another service
  • Regular reviewing and challenging of the decision to stay with the monolith or split (upon every introduction of a new feature) - the management is to be made aware of this upcoming architectural change one day
💡

For educational purposes the future domains and their isolation within our monolith are separated by colors. This is not normal to do but should point out how each domain is within itself isolated. As hexagonal architecture suggests dependencies flow inward, meaning that only at service level (logic layer) we will allow cross-service communication. With that we can later take one domain, split it into a microservice but maintain 80% of our architecture thanks to proper isolation.

💡

For educational purposes the isolation and separation is quite verbose (it resembles quite a class diagram already). This verbosity could be abstracted in practice maybe a bit to reduce overhead.