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.
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
- 3rd party Libraries
- Infrastructure like .net or .net core
- Resource Access
If one is to follow the following rules you will have an application that limits coupling and promotes SOLID principles.
- 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.
- 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