DEV Community

Stef van Hooijdonk for Coolblue

Posted on • Edited on

1

Design to encapsulate volatility

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

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.

Image of Timescale

🚀 pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applications—without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read more

Top comments (0)

Billboard image

The Next Generation Developer Platform

Coherence is the first Platform-as-a-Service you can control. Unlike "black-box" platforms that are opinionated about the infra you can deploy, Coherence is powered by CNC, the open-source IaC framework, which offers limitless customization.

Learn more