Notes on DDD Europe conference I – 2018 edition

Just like last year, this February I have had the opportunity to attend a very important event in the world of Domain Driven Design – DDD Europe conference 2018, which took place in the city of Amsterdam.

I have to say that the level of both the speakers and the audience in the DDD Europe conference was very high, especially if we compare it with the level of meetups in Spain, organized for software developers and software architects.

However, they were some presentations that seemed very unproductive to me. These were, in my opinion, the ones that went too far away from the world of development and the technical world in general.

An example of what I have just described, from my perspective, was a speech: “from legacy chaos to the promised land of DDD“. I expected to dive into strategic patterns to evolve a monolithic system towards a correct application of the logic of Domain Driven Design.
Unfortunately, after the presentations of the two speakers, the session focused a lot on the history and experience of the team led by one of the speakers.
I don’t want to say that the speaker was wrong, I believe in the importance of the culture of the team in a situation of an evolution of a critical system like the one carried by the speaker. But I also strongly believe that issues that each team has are unique, so it is extremely difficult (if not impossible) to find universal “recipes”, except the most obvious ones. So the presentation itself was useless for me.

I divided my notes into two articles. In each one, I listed down the presentations from the DDD Europe conference, which I found the most interesting.
In the first article, I will talk about “The Systems of the Liskov Substitution Principle” and about the “Autonomy & Asynchrony: the key to designing reliable systems”.

Most interesting presentations from the DDD Europe conference in 2018

1) .The systematic of the Liskov Substitution Principle
By Romeu Moura

The presentation was focused on the use of the word sistemics.

Let’s start by considering the purposes of the Object-Oriented paradigm:

– encapsulation
– decoupling
– coherence (a type of SRP?)
– cohesion

The audience asked an intelligent question about the reason to leave out concepts like inheritance ( talking about the list mentioned above ). The answer of Romeu was the following: this is the only way to meet the goals. He compared it to the relationship between law (way) and ethical society (goal ). 

Let’s continue with the interpretation of the semantics of the Liskov principle: it is a system that has to be allowed to replace some of its parts, thus changing its behavior, but without breaking its operation.

Also, he shared several significant and interesting examples, beginning with mathematical operations (a division between integers is not isomorphic to a sum of them since it is not a mathematical closure), and ending with the classic examples of covariance and contravariance with lists of animals, which we also have in our blog.

Highlight:

• The relationship between Liskov and the principle of Interface Segregation:
  • A large interface is more subjective to possible ruptures of the pre and post conditions established by the Liskov principle
  • If the interface suggests a rupture of the principle of temporal cohesion, each implementer is bound to contravene Liskov
• The examples are all developed in Java using the Type-Driven Development methodology, defining the contract types of each method prior to its implementation, to guide it.
  We fully support the use of this methodology.

In my opinion, the most valuable part of the presentation was about the use of the word systemics.
Advising the book “Thinking in systems”, by Donella, Romeu introduced the elements of systems theory to try come up with the system definition.

What we know about a system:

• is more than a simple sum of the parts that compose it (holistic principle)
• it must allow the evolution of its behavior by replacing one or more of its parts, without breaking its functioning

What I found very valuable and very profound is the consideration that what we discussed above can be negative as well: a bad system can’t be improved by simply replacing its parts.

So, here goes the key phrase, that I personally love:

“If you remake awful software from scratch without changing the culture that created it: you’ll remake awful software.”

Small comment: we fully support the exposed phrase.

Who knows Apiumhub, knows that we are very skeptical of just rewriting software from scratch,
because when we work on software projects, we are oriented towards gradual changes in the culture of software. And it is not only about our internal team, we do it with our clients, partners, and other collaborators.

And let me give you the final example, taken by Romeu, which was related to history: the French Revolution ended up abolishing the monarchy, passing through despotism, despite having removed the King, the symptom stayed the same.

2). Autonomy & Asynchrony: the key to design reliable systems
by Indu Alagarsamy

This presentation was given by a Particular Software worker.
For those who do not know Particular Software, it is the company behind NServiceBus, an excellent service bus for .NET technology.The company was founded by Udi Dahan.
For this reason, the expectations were very high, since for those who write code there is no better architectural culture today than the one proposed by Udi Dahan.

The speaker gave a structured explanation of the patterns to achieve reliable systems, without having the prohibitive costs of using distributed transactions:

• Asynchrony
  • At the very beginning, we refer to detailing the anti-pattern “the knot“.
    Using the slogan “remove temporary coupling”, the concept focuses on the way that each time a component depends synchronously on other components, an important brake is placed on (among others):
    • scalability and quality of service leveraging (to scale 1 component I have to scale all of them)
    • reliability (reaction to chain of failures)
    • efficiency (whole system slowdowns due to 1 component overload)
    • decoupling and functional scalability (changing a component or adding a new one affects all the components)
    • traceability (difficult to understand the reason for failure)
• EDA / Coreography
  • using an architectural style based on Pub / Sub events allows complete decoupling between components, and enables functional scalability.
• Message synchronization
  • In an asynchronous system, the correct order of the messages can not be assured.
    The proposed pattern is the saga pattern. There are two forms:
    • orchestration
    • choreography We indicate two alternative or complementary solutions to saga to solve the problem of synchronization:
    • choreography
    • message sequence number, sent by the message producer, and controlled by the consumer
• Dead letter queue
  • In the case of a failure, the queue systems have to deal with the retry logic.
    To avoid the problem of poison messages, at a certain number of retries, the message is placed in a dead letter queue, monitored continuously, for root cause analysis.
• The duplicity of messages (idempotence, idempotence, idempotence!)
  • Just like with the order, asynchronous systems cannot ensure the uniqueness of the message. The system has to provide, in all its parts, idempotence of processing.
    There are two cases:
    • when the business logic allows idempotence using upserts. For example, a logic of updates.
    • when logic does not allow it, as in the case of CreateOrder. In these cases the producer has to assign a unique messageId, and the consumer does not have to process messages already processed. This pattern has the name of idempotent consumer.
• Message traceability (“where is my message?”)
  • To be always aware of where the message is, or where a processing has failed, it is necessary to accumulate all the services that have processed it in the headers of the message, starting from the very first message.
• Deployments
  • Actually, before starting with asynchronous systems, it is necessary to start automatic, traceable and reliable deployments systems. It is an essential precondition for everything.
• Side by side
  • Asynchronous systems, event-driven, supported by messaging bus, have the ability to deploy new versions of components next to the previous ones, with the purpose of testing in production, without interrupting the service.
    To be able to do this, we must to respect the existing compatibility, be it with the tolerant reader pattern, or by use of schema versioning.
• Resilience
  • Finally, it is recommended to use (in test environment) the chaos monkey pattern: randomly restart components and services to measure how this affects the operation (and performance) of the system. It is also known as a resilience test, and there are corporations that do it systematically also in the production environments (Netflix).

These are the most critical points that I highlighted from the presentations of DDD Europe conference. Now I would like to read your opinion about them before sharing my next article with other presentations that deserved to be discussed.

And if you want to receive the second part of DDD Europe conference with other interesting presentations and notes, subscribe to our monthly newsletter.

If you found this article about DDD Europe conference interesting, you might like…

Scala generics I: Scala type bounds

BDD: user interface testing

F-bound over a generic type in Scala

Microservices vs Monolithic architecture

“Almost-infinit” scalability