Earlier this year, I had the chance to attend the DDD Europe 2017 conference. It was my second time at this conference, as I also participated in the first edition in Brussels in 2016.
Here are a few comments on some of the talks that interested me most.
Thomas Ploch - Domain-Driven Organisation Design
I really enjoyed Thomas' presentation. He talked about some generics on complex systems, this is the way he chose to represent his organization going through a very strong agile transformation. And later on they actually structured the company.
An organization, as a complex adaptive system, has four main properties : self-organising, emergent, non-linear, order/chaos dynamic. Those properties will come to life when two criterias are met. All the agents of the system must have autonomy, but all must share a common goal. This is why he emphasized on the importance of change agent, being element inside of the organization, who by their knowledge and competence can influence the rest of the organization. His company chose OKR to focus the energy of all element on shared goals.
Udi Dahan - If (domain logic) then CQRS, or Saga?
Links: Talk
In this talk Udi Dahan entered in details in the complexity of managing alternative scenarii using conditional as 'if'. He made a strong case on using CQRS and sagas to handle such cases in collaborative contexts.
He was using a web store checkout as his main example and trying to design a feature that would not add an item to the cart if the item is disabled. In a high concurency domain, he states that writing something as this will create a wrong sense of security:
<?php
class Cart
{
public method add(Product $product)
{
if ($product->isEnabled()) {
// What happens if the item is disable here?
$this->itemsInCart[] = $product;
}
}
}
The best way to solve theses cases is to think of the cart as a Saga. The cart and the cart process are two seperate things. The cart will be an entity, but the cart process will be a saga. A timeout will be put on the cart process to make sure that even if it has disabled items in it, they will be removed after a reasonable time.
Eric Evans - Keynote
Links: Talk
Eric Evans' talk was very captivating, his style works with brio in this exercise. He has a calm voice and uses clear and punctuated sentences. It's always a pleasure to hear is talks. This one in particular felt as a collection of lessons learned, all related yet all different.
Good design is imperfect design: The main goal of the design is to solve most of the issue elegantly, not all of them. If a design covers a large portion of the use case then it is good to be released. It is much preferable to ship early imperfect software than to polish indefinetely something that will never be used.
Avoid abstraction when concept are not clear: Abstractions are an amazing feature of object oriented programming, but introducing badly understood abstraction can lead to harder code to maintain in the future. The abstraction will direct your code more than you want. It's better to leave a feature with if then else logic than introduce early abstraction.
Honest naming: Give akward name to akward concept. If an operation has a behaviour that cannot be described with a few words, then give a more precise and akward name. He was using the example of the add method in most DateTime class. The fact that the method is called add should mean that the method should be associative which is not the case, he suggest using a more descriptive like laterBy or advance that do not suggest associativeness.
Community Garden Metaphor: He sees enterprise software as a community garden. It is a space in which some basic infrastructure is provided and you as a developer are given a lot and the responsability to have clear boundaries on that lot. The infrastructure is a perfect image for actual software infrastructure: servers, load-balancers, logging and monitoring. And the boundaries of each services should be very clear just as each lot in the garden.
comments powered by Disqus