I’ve been lucky to attend a very interesting meetup with Adrian Bolboaca recently at Arolla on the edgy topic of Evolutionary Design using Inductive or Deductive approach. It is about TDD of course, as Adi is a master of TDD. The topic could not escape my mind since then, so I’d like to share about it here, even if it remains not fully baked. I also hope Adi will share his material on all this soon.
Evolutionary Design is the art of growing a system by observing its natural traits then normalizing and optimizing its growth. — Adrian Bolboaca
DDD Europe 2017 in Amsterdam was a blast, once again. The line-up of the conference was decided by one man, Mathias. We’re lucky he has very good taste and a large culture so he invited fantastic speakers! Although the conference was primarily about Domain-Driven Design, I had the impression of an implicit recurring theme across the various talks this year, revolving around the idea of “Emancipation” of people in software.
Emancipation: The fact or process of being set free from legal, social, or political restrictions
— Oxford dictionary
Mel Conway, the author of the Conway’s Law himself, started the first…
At Agile France 2016 in Paris I ran an open-space session on Decentralized Architecture. This was an opportunity to collect various perspectives on an increasingly important topic.
We started with a quick survey with all the attendees, who were asked to give “examples of architecture”, in any form and in their own interpretation of the word.
Going through the examples, the very first realization was that in practice there are many different visions of architecture:
In sports, football for example, players have only one goal in mind: score, score, again and again, as often as possible. Close to them, but not too close, arbiters have only one goal in mind: detect quickly all violations of the rules of the game, and sanction them.
The players know the rules, still we need an antagonism role, the arbiters, to keep the game fair. It is never perfect, but this is not plain chaos either.
Many mature businesses have chosen a similar structure. …
I’ve once worked for the IT department of a large restaurant network. They had a secret sauce, and this wasn’t one you could eat.
In a restaurant kitchen, when a customer orders a dish on the menu you have to cook it. You take the recipe with a list of ingredients and their quantities, and you prepare the dish by following the instructions. In theory, if the recipe says you need a quarter of a lemon, then you should be able to cook 4 dishes with one lemon. Unfortunately, when you analyze the actual consumption of ingredients over a day…
It is not uncommon to oppose the empirical process of TDD, together with its heavy use of unit tests, to the more mathematically based techniques, with the “formal methods” and formal verification at the other end of the spectrum. However I experienced again recently that the process of TDD can indeed help discover and draw upon math formalisms well-suited to the problem considered. We then benefit from the math formalism for an easier implementation and correctness.
It is quite frequent that maths structures, or more generally “established formalisms” as Eric Evans would say, are hidden everywhere in the business concepts…
Alberto Brandolini (@ziobrando) gave a great talk at the last Domain-Driven Design eXchange in London. In this talk, among many other insights, he described a recurring pattern he had seen many times in several very different projects: “Collaborative Construction, Execution & Tracking. Sounds familiar? Maybe we didn’t notice something cool”
In various unrelated projects we see similar problems. Consider a project that deals with building a complex artifact like an advertising campaigns. Creating a campaign involves a lot of different communication channels between many people.
On this project, the boss said:
We should prevent the user from entering incorrect data.
The Composite pattern is a very powerful design pattern that you use regularly to manipulate a group of things through the very same interface than a single thing. By doing so you don’t have to discriminate between the singular and plural cases, which often simplifies your design.
Yet there are cases where you are tempted to use the Composite pattern but the interface of your objects does not fit quite well. Fear not, some simple refactorings on the methods signatures can make your interfaces Composite-friendly, because it’s worth it.
Imagine an interface for a financial instrument with a getter on…
Domain-Driven Design, patterns, BDD & TDD enthusiast. CTO @Arollafr & Founder of the Paris Software Craftsmanship Community. Author of “Living Documentation”.