Building blocks of an application

By | Mar 30, 2019

if you spent time looking at the systems in the wild you will note that the systems are way to complex and have many many relationships between internal components. Its the relationships between the code structures that make a systems difficult to work on.  You might need to work on something as simple like this.

But continuously have to consider the impact on the rest of the system due to the hidden relationships. Everything is coupled and where there is coupling there is a relationship to be considered.


The types

IDesign makes things easy to work on by limiting the relationships and by defining object types and rules for each. Designs focus on the use case. If one is to analyze the components of an application you will note they mainly consist out of combinations of these types but not rules are followed.

These types can be normal classes or microservices. Its important that each type communicates via a contract / interface.

  • User Interfaces
  • Managers
  • Utilities
    • 3rd party Libraries
    • Infrastructure like .net or .net core
  • Engines
  • Resource Access
  • Resources

The rules

If one is to follow the following rules you will have an application that limits coupling and promotes SOLID principles.

User Interface

  • Does not contain any business logic.
  • Interacts only with Utilities and Managers.


  • Encapsulate the use case from the UI
  • May only orchestrate and encapsulate use case related business logic.
  • Not allowed to call other managers directly.
  • No other type except the User Interface is allowed to call a manager.


  • Represent functional type requests like; encrypt, transform, read…
  • May be called by any of the types
  • May not be call other utilities
  • May not contain any business logic


  • Simular to utilities but contain business logic.
  • Uses are linked to the business and may do functions like validate, translate…
  • May be reused in other use cases.

Resource Access

  • Encapsulates the resources
  • May be used in other use cases
  • May be use case aware
  • May only interact with Resources and Utilities.


  • Represents storage or subsystems
0 0 vote
Article Rating
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newest Most Voted
Inline Feedbacks
View all comments

[…] I am not going to cover the further volatility steps in detail but the next items to identify per use case are; Engines and Utilities. These are the re-usable components between the use cases. Read more about them under the topic Building blocks of an application […]


[…] Building blocks of an application Volatility based decomposition for Microservices […]