Table of Contents
Let’s recap. We are located in Amsterdam, in the 2018 edition of the Domain-Driven Design Europe convention.
In the first article I highlighted the first two presentations that, in my opinion, stood out the most in Domain-Driven Design Europe conference. The first one was about “The Systems of the Liskov Substitution Principle” presented by Romeu Moura where I highlighted the relationship between Liskov and the principle of Interface Segregation. Also, we looked at the examples, which are all developed in Java using the Type-Driven Development methodology.
While in the second presentation about “Autonomy & Asynchrony: the key to design reliable systems” exposed by Indu Alagarsamy, we looked at the structured review of the patterns to achieve reliable systems, without the prohibitive costs of using distributed transactions.
Let’s continue with the presentations:
Most interesting presentations from the Domain-Driven Design Europe 2018
3). Functional and Algebraic Domain Modeling
by Debashish Ghosh
The author of the book “Functional and Reactive Domain Modeling” (Manning Publications) introduced some concepts of his book while he was giving his presentation.
It started by defining Functional as a modeling using the concepts of functions as pure maps between domain and codomain.
And Algebraic, on the other hand, refers to the modeling of types (objects) and equations among them (constraints), which represent the domain logic, to arrive at an abstract algebra, which is basically what we are used to defining as the interface of a domain service.
Through the use of functional abstractions and the universal language of mathematics (in the abstractions of category theory), there is a clear advantage that many of them are already implemented in standard libraries, such as Scalaz.
The result is that much less code is written, and it is more robust.
When we talk about Domain, the author points out that it refers to the Domain in the space of the problem, so the modeling operation is about mapping the space of the problem to the space of the solutions.
A system can never be “pure”, so there are abstractions to compose sequentially when side-effects occur (Monads).
The author highlights the difference between effects and side-effects, in the sense that the effects can coexist in pure code (for example the existence or not of a value),
while the side-effects involve interactions of the program with other environments (from the treatment of exceptions in the runtime of a language to writing to disk).
Having algebras and composition operators despite the presence of side-effects makes it possible to imagine the use of composition operators at a higher level, which is, a composition of domains.
Let’s continue by introducing the algebraic types (sum and product), and the higher-kinded types, as type constructors, and the other concepts of functional programming.
The work of the author, both in the book and in the presentation, is exceptional.
Let’s briefly look at some of our discrepancies which are related to the type of modeling proposed:
- Pattern matching: we consider that the pattern matching breaks the modularity of the system, especially if it is executed on functors or monads.
Check of the Scala compiler is simply a warning, and requires the use of sealed traits, which break the Open-Close principle.
The polymorphism by virtual methods, on the other hand, gives a very exhaustive compile-time checking, like compile error, minimizes the conditional logic, reinforces the encapsulation and leaves the modules opened to the extension. - Abstraction first: the levels of abstraction involved in the composition of “higher-kinded” types end up producing many generic levels, and you need monad transformers.
This result:- a very high level of stamp coupling
- a clear disadvantage in the expressiveness of the domain, and of the code in general.
- We have been working for years on a functional and algebraic modeling approach, much less “extreme”, which we call Object-Functional.
And his goes together with the way how Martin Odersky defined the Scala language, but let’s discuss it in the upcoming articles.
4). Promise & Purpose: Why understanding Promise Theory can make you better DDD
by Kiki Carter
Another great topic was presented by members of the Lightbend company.
The presenter introduces the theory named “Promise Theory”, and its applications in information systems. The theory is complex enough to be treated in this presentation, and the same goes for applications. In general, the context is a system composed of independent agents, such as a system based on actors (see Akka or MS Service Fabric), or a microservice system.
The idea is:
- The flow changes from being “imperative”, as a sequence of commands, to being the acceptance of “promises” made autonomously by each agent.
- An agent can only make promises based on the resources managed by him. An agent that depends on other agents is not able to make promises since the realization of them depends on other agents or resources not managed by him.
We still need to deepen the theory and its consequences, but we believe we can come up with a pre-conclusion:
- The theory emphasizes the autonomy of services, which is one of the pillars of service-oriented architecture (SOA).
- ways to implement mentioned autonomy:
- An asynchronous system, oriented to events, allows the operation of each service be completely autonomous
- The fact of “promising” only what is relative to each agent suggests that the agent/service is seen as an nth definition of “encapsulation“, at the level of the data/resources managed
- The same is happens with the configuration level. Undoubtedly, the suggested approach is closer to programming and declarative configuration, in opposition to the imperative one.
In conclusion, I want to say that it was a great event of 2 days, where I had the opportunity to meet very interesting people and discuss new points of view. With this new information, I want to continue investigating the software architecture and build better working software.
And if you are interested in Domain-Driven Design Europe or in DDD in general, subscribe to our monthly newsletter.
If you found this article about Domain-Driven Design Europe conference interesting, you might like…
Scala generics I: Scala type bounds
F-bound over a generic type in Scala
Microservices vs Monolithic architecture
