Promoting open/close principle and loose coupling between components


I’m a big fun of event-driven architecture and how different components in a system react to different state changes in a domain. Mostly because it promotes loose coupling between components and services. Sometimes it's also a good paradigm to pipe and filter architecture since, for instance, the consumer of an event might just have the responsibility to filter, transform and forward the event to another component of the system. Moreover coming from distributed environments and architectures, an event-driven approach extends horizontal scalability making them more resilient to failures promoting high availability and eventual consistency [6, 7].


The initial scope of the article was to avoid ActiveRecord Callbacks mostly because of its unwanted side effects [4] and hard to remove afterward. Other drawbacks would be violating the single responsibility principle and slowing down our test suite. Leaving AR callbacks on the side the next thought would be to decouple a service object from directly calling other services to fulfill a use case as we will see below. The advantage of the last point is that we promote the open-close principle and have a better view of the purpose of a given use case and what are its side-effects. …

When to check when business rules apply?

The question is quite common in software development. Given an instance of a class, you want to know when to check if a class is valid or not. Do you skip validations before executing an action or do you first check if the instance is valid before executing an action?

Let’s see a simple example. Image an entity called and some validation or better business invariant rules that require a flight reservation to be valid when it contains no more than passengers.

class FlightReservation < AggregateRoot
MaxPassengersReachedError =
attr_reader :passengers
attr_reader :max_passengers
def initialize(max_passenger)
@max_passengers = max_passengers
@passengers =

if (passengers.size …

Reduce coupling and dependencies between communicating objects. An event-driven approach.

Design patterns are reusable solutions to a commonly occurring problem within a given context in software design [1]. …

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store