Our strong belief in Clean Architecture compliments the principle of Encapsulating Volatility. If something is likely to change, make sure it's easy.
A very retro analogy can be applied to hifi systems:
Some manufacturers sold complete integrated hifi systems. These systems had everything on them. Amp, record player, double cassette deck, radio, CD player, equalizer (a graphic one if you were lucky) etc.
The problem is that as CDs were replaced by next gen technology (like minidisc, ok, like mp3 on storage and then streaming), the whole system was at risk of becoming obsolete, even though the system still served its original purpose.
However high-end manufacturers stuck to their component model. You could buy an Amp, separately from a CD player, and speakers etc. You can even mix and match components from different manufacturers.
So when CDs were replaced by mp3’s then mp3’s by streaming services, you could just add, or swap out the relevant components. The CD player, one of the ‘music suppliers’ within the system was a volatile component.
This view on things goes beyond modularisation. It informs you what modules you should have. If it’s volatile, very likely to change, encapsulate it.
Clean architecture
Regardless of whether we choose Microservices, SOA, or a monolithic approach, Clean Architecture can and should still be used. All of our systems should be built this way. It emphasises the domain at the heart of our designs (key also to DDD etc).
Dependency inversion is integral (and thus this approach supports good programming practice in general, and some specific SOLID principles). It moves things that are more susceptible to change to the edge instead of the center, making them easier to replace. Whatever we build can be built following this principle (even other architectures/patterns can be built in this manner).
SOLID
- S - Single-responsibility principle
- O - Open-closed principle
- L - Liskov substitution principle
- I - Interface segregation principle
- D - Dependency Inversion Principle
You adhere to SOLID principles (no exceptions for object-oriented development). These are 5 of the basic principles of Object Oriented design and programming. They should be second nature to every OO developer at Coolblue.
Top comments (0)