Breaking the monolith… what did I learn

WARNING this in working progress so please bear with me whilst I am capturing my thoughts

Earlier this year on QCon I attended a great talk by Stefan Tilko. He talked about breaking a system into several subsystems, separating the micro and macro architecture, and addressing various integration issues in order to get a suppler architecture.

Summary of what I captured is as follows:

  • Systems grow with projects
  • Project may lead you to design system boundries. This is often wrong.

Some things to brear in mind are characteristics of the systems i.e.

  • Does you system have a sperate persistence layer?
  • What domain models and implementation stratgey do you have?
  • Do you have seprate UI?
  • What is the interactions with systems and sub-systems?

Micro Architecture vs Macro Architecture

Micro Architecture- Micro-architecture as a set of patterns used together to realize parts of a system or subsystem. We view a micro-architecture as a building block for piecing together well-known, cohesive portions of an overall architecture. A micro-architecture is used to solve a coarser-grained, higher-level problem that cannot be solved by a single pattern. Thus, a micro-architecture represents a higher level of abstraction than the individual patterns.

Macro Architecture- Macro Achitecture  on the focuses of high level system design, focussing of  design , giving you flexibility of the appropriate language for the substem. 

What should you be looking for in an architecture diagram

If your architecture diagram is talking about layers like UI, Persistence, etc. Its too generic. It can apply to any system and hidding the interactions and the complexities of the system.

A good architecture diagram should comprise of boxes that display the sub-systems/modules/components, their interaction, dependencies and complexity.

How do we arrive at the system when we think about the architecture of a system. How do we arrive at system boundries?
The boundries of the system we are designing are often driven by the projects. This is often wrong and worst possible approach. As often the full scope of the project not really defined correctly from start and therefore boundries driven by a change scope will be wrong.

How should we design the system boundries?

As the LOC grows we should split the code into modularity i.e. framework is growing and there for system should become multiple applications. There are some size limits (what ever your measure may be) that will make sense to you split your system into multiple subsystems. Its a usefull way.


Characteristics of Each system/Sub system:

  • It system may have its own pesistence layer
  • It may have its own UI, etc.
  • It got its own eco system and is possible to operate it indepently and has some interactions with some other system, but the interaction are limited i.e. therefore autonomous

Leave a Reply