Présentation du Bounded Context Canvas

Le Bounded Context Canvas est un outil collaboratif créé par Nick Tune. Il aide à concevoir et documenter un Bounded Context.

Un Bounded Context (contexte borné), constitue une frontière autour d’un modèle et de son langage métier. À l’intérieur de cette limite, la signification des termes métiers utilisés est sans ambiguïté, bien définie et comprise par toutes les parties prenantes. Le modèle est clair et les règles sont cohérentes.

Le canvas vous guide à travers le processus de conception d’un Bounded Context en vous demandant de faire des choix sur les éléments clés de design : de son nommage et ses responsabilités à ses interfaces publiques et ses dépendances.

Vous pouvez retrouver l’article original de Nick, en anglais, sur son blog → ici.

The Bounded Context Canvas V3

Comment ça marche ?

Il n’existe pas de recette miracle pour découvrir les différents contextes bornés, mais une connaissance fine du domaine vous y aidera certainement ! La phase de découverte et d’exploration d’un domaine constitue la partie cruciale du Domain Driven Design. Sans une vision partagée par toute l’équipe, aucune chance d’aboutir au produit demandé.

Pour ce faire, il existe plusieurs outils collaboratifs qui vont vous permettre de découvrir le domaine visuellement et collaborativement :

• EventStorming
• Example Mapping
• Domain Storytelling
• User Journey Mapping

Event Storming

Ma préférence va à l’Event Storming qui est, comme son créateur Alberto Brandolini le décrit : “un acte délibéré d’apprentissage collectif”. Le but de cet article n’est pas de vous expliquer comment dérouler un atelier Event Storming, si vous n’êtes pas familiers avec la pratique, je vous encourage à regarder cette vidéo ainsi que de lire le livre d’Alberto.

Commencez par modéliser le cas nominal en répartissant les événements métiers importants sur la ligne du temps. Essayez ensuite d’identifier les événements qui apportent de la valeur, ils vous aideront à coup sûr à découvrir vos contextes “cœur de métier”.

Heuristique

Cherchez les événements clés/pivots, ce sont des événements du domaine qui indiquent généralement des changements d’état entre les différentes parties du processus métier. Ce sont souvent des marqueurs de début et/ou de fin d’un contexte borné.

À la fin de cette session d’Event Storming en mode “big picture” vous devriez être en mesure de commencer à noter sur des post-it des noms de contexte borné candidats.

Domain Message Flow Modelling

Choisissez un des contextes bornés candidats que vous avez trouvé lors de l’Event Storming, identifiez une liste de scénarios clés de ce contexte et réalisez un diagramme de flux des messages pour chaque scénario (plus d’info → ici).

Ce diagramme aide à visualiser tous les messages (commandes, événements et requêtes) qui circulent entre les différents acteurs, contextes bornés et systèmes externes, pour un scénario donné.

La notation est volontairement très simple afin de s’assurer que tout le monde soit capable de participer à l’atelier sans avoir besoin de théorie :

Voici un exemple d’utilisation :

Diagramme de flux des messages – légende

Diagramme de flux des messages – exemple

Modéliser un diagramme de flux des messages vous permet d’avoir un feedback rapide sur la pertinence du choix de votre contexte borné. Vous visualiserez très vite la façon dont les contextes interagissent entre eux afin de satisfaire un scénario.

Heuristique

Si votre diagramme semble trop complexe avec beaucoup de dépendances et de relations bidirectionnelles, il se peut que vos choix de contextes bornés soient erronés. Voyez-là une bonne opportunité de retravailler votre design avant de vous lancer dans le code ;)

Il n’est pas nécessaire d’identifier tout de suite les données véhiculées dans chaque message, cela peut très bien être réalisé dans un second temps.

Le Bounded Context Canvas

Il est temps maintenant de s’atteler à remplir le canvas.

Chaque contexte borné candidat possède son propre canvas, vous pouvez d’ailleurs commencer par remplir le canvas du contexte borné qui vous semble le plus important dans votre domaine.

Voici la liste des différentes sections et pour chacune, des indications sur comment les remplir.

Nom

Le nom du contexte borné. Référez-vous au résultat de vos ateliers Event Storming et Domain Message Flow Modelling pour la liste des contextes bornés candidats.

Heuristique

Posez-vous la question de la pertinence d’un nom de contexte qui contiendrait “Management/Gestion”. Bien souvent ce terme est employé comme fourre-tout et regroupe probablement plus d’un contexte. Ex : dans le cadre d’un domaine de location de trottinettes électriques, évitez “Gestion de la flotte”, cela regroupe certainement des contextes comme “Répartition de la flotte” et “Prévision de la demande” qui sont des candidats à part entière.

Description

Cette section sert à décrire brièvement le contexte borné, ses intentions et ses responsabilités. Quel est son rôle dans le domaine ?

Classification Stratégique

La classification stratégique contient 3 axes par défaut (Domaine, Business Model et Évolution). Il n’est pas forcément nécessaire de remplir les 3, ils servent avant tout d’exemple. Vous pouvez également ajouter les vôtres si cela vous semble plus pertinent.

1 – Domaine

Dans cette sous-section, le but est d’identifier l’importance que joue le contexte dans la réussite de l’organisation. Un moyen simple et efficace est d’utiliser le tableau ci-dessous :

Core Domain Chart

Ce tableau vous aide à visualiser l’importance stratégique d’un contexte borné (abscisses) et son niveau de complexité (ordonnées).

Le cœur de métier est la raison pour laquelle vous développez votre application au lieu d’en acquérir une sur le marché, c’est évidemment la partie qui nécessite le plus d’attention. Les contextes de support sont des contextes nécessaires au domaines, liés au business, mais qui ne possèdent pas un avantage compétitif équivalent au cœur de métier. Les contextes génériques représentent des concepts qui ne sont pas uniques au domaine (on y retrouve des choses comme l’envoi d’e-mails, le paiement, …) Il est totalement possible d’imaginer utiliser des services existants au lieu de développer ses propres domaines génériques.

2 – Business Model

Ici, vous décrivez quel rôle joue le contexte borné dans le business model de votre organisation.

Prenons l’exemple du business model d’un moteur de recherche comme Google. On pourrait imaginer que plus les utilisateurs effectuent des recherches, plus cela génère des revenus. Quand on y réfléchit bien, ce n’est pas le contexte de recherche qui est générateur de revenus, mais le contexte des publicités. Le contexte de recherche sert à l’attractivité. On peut aussi très bien penser qu’un contexte qui gère les problématiques de GPDR ait le rôle de conformité dans le business model.

3 – Évolution

L’idée de cette sous-section est d’imaginer à quel niveau de maturité se trouve le contexte, à l’aide d’une Wardley Map. Sur l’axe de l’évolution, plus un contexte est répandu ou commun, moins il aura de valeur ajoutée.

La 1e étape sur une Wardley Map représente la genèse. C’est là que vous pourrez placer votre contexte s’il constitue quelque chose d’innovant. Ensuite arrive l’étape du sur mesure. A ce stade on quitte l’état de POC (Proof of Concept) mais les développements sont encore très customisés. Si votre contexte se place dans l’étape produit, c’est peut-être que vous êtes assez matures et êtes en mesure d’offrir des services à d’autres contextes ou à l’extérieur de votre organisation. Enfin, lorsque le contexte se trouve à l’étape marchandise, c’est qu’il devenu un contexte très commun auquel tout le monde peut avoir accès facilement.

Cette carte sert avant tout à visualiser la chaine de valeur. Elle vous permettra dans un second temps d’imaginer comment vos contextes risquent d’évoluer dans le temps et ainsi d’anticiper au mieux les efforts à porter sur tel ou tel contexte.

Décisions Métier

Ici, vous noterez les contraintes, décisions et règles métier du contexte : Quelles sont les décisions importantes que le contexte borné doit prendre et pourquoi ?

Vous pourrez distinguer les règles métier des invariants.

Invariant : Un Invariant est une règle forte qui ne doit jamais être rompue. Ex : Vous ne pouvez pas prendre 2 rendez-vous le même jour avec le même médecin sur une plateforme de prise de rendez-vous médical en ligne.

Règle : C’est une règle métier dont on ne connait pas forcément à l’avance la vitesse à laquelle elle va être appliquée et donc, qui est sujette à compensation. Ex : Une personne commande une pizza en ligne, la « cooking policy » s’applique. On regarde si la pizzeria est en capacité de prendre la commande et on l’accepte, sinon, on annule la commande.

Langage Ubiquitaire

Listez ici la terminologie clé du contexte ainsi qu’une définition de chaque terme.

Heuristique

Prêtez une attention particulière au langage et à la signification de chaque terme dans un contexte. Si vous luttez pour trouver une bonne définition à un terme particulier du contexte, c’est peut-être parce qu’il cache plus d’une signification. Dans ce cas, la découpe de votre contexte est certainement à revoir. Pensez au terme “livre” qui peut avoir de nombreuses définition en fonction du contexte dans lequel il est employé (imprimerie, édition, librairie, simple lecteur, …) comme en parle si bien Grégory Weinbach dans cette vidéo.

Caractéristiques du Modèle

Cette section est vraiment ouverte et vise à définir la nature des comportements internes du contexte et/ ou le type du modèle.

Le type de modèle est une notion très intéressante qui a été déjà présentée à de nombreuses reprises par Alberto Brandolini. En 2012, en 2016 et tout récemment lors de la conférence en ligne D-DDD-D dans son talk Extreme Context Mapping (partie “the three archetypes”). L’idée est de montrer que des modèles similaires peuvent avoir des comportements très différents. Alberto parle de modèles “draft“, “execution” et “metrics“. Les modèles de type “draft” et “execution” partagent une structure de données très proche mais leur comportement diffère. Sur un modèle “draft“, il y aura des validations de structure et la donnée sera consolidée de manière incrémentale. Prenons l’exemple d’un panier sur un site e-commerce. On y ajoute des articles au fur et à mesure, des vérifications de surface sont faites, mais ce n’est pas avec un panier que le site va gagner de l’argent. Le modèle “draft” passe à “execution” suite à un événement de transition (cherchez-les sur votre Event Storming !) Notre panier devient alors une commande, avec laquelle le site e-commerce pourra gagner de l’argent. Ce modèle deviendra alors pratiquement read-only. Un 3e type de modèle, le type “metrics“, avec une structure semblable, servira à des fins de reporting ou d’analyse.

Nick fournit également une liste de type de comportements applicables à un modèle, dont vous trouverez la version française → ici.

Messages Consommés et Produits

On trouvera dans cette section la description de l’interface publique du contexte. Que produit-il comme message et que consomme-t-il ?

Voici les types de messages :

Commandes :
Le contexte qui produit une commande, demande au contexte destinataire de faire quelque chose, de réaliser une action. Une commande peut échouer.
Événements :
Un événement important pour le domaine qui est arrivé dans un contexte et qui peut intéresser d’autres contextes.
Requêtes :
Un contexte demande des informations à un autre contexte.

Interface du contexte borné

De nouveau, n’hésitez pas à jeter un œil à votre Event Storming, vous trouverez de quoi alimenter cette section !

Dépendances et Relations

Ici on listera les contextes et les systèmes externes depuis lesquels les messages arrivent – les fournisseurs – et les contextes qui consomment les messages publiés – les consommateurs -.

La relation est un texte libre où vous pourrez décrire succinctement la raison pour laquelle une dépendance existe.

Référez-vous à votre diagramme de flux des messages afin de voir avec quels autres contextes et systèmes externes votre contexte interagit.

Et après ?

Une fois que vous aurez rempli votre 1e canvas, profitez-en pour prendre un peu de recul avant de remplir le suivant. Regardez si les décisions que vous avez prises lors de vos discussions, n’ont pas d’impact sur la liste des contextes candidats que vous aviez imaginé au départ. Refaites un tour sur votre Event Storming et rectifiez au besoin.

N’oubliez pas que la modélisation est une activité itérative, comme Eric Evans le dit lui-même “il faut trois mauvais designs avant d’avoir trouvé le bon !”

Le canvas a été créé pour vous guider dans la découverte, la conception et la documentation des contextes bornés de votre domaine. Vous n’êtes toutefois pas obligés de le suivre à la lettre. Libre à vous de le modifier et l’adapter en fonction de vos besoins.

Tout au long de cette activité, pensez à noter les heuristiques que chacun a utilisé pour trouver et affiner la liste des contextes bornés de votre domaine. Cette liste, que vous pourrez mettre à jour régulièrement, vous servira à chaque fois que vous repartirez en mode exploratoire à la découverte des contextes bornés d’un domaine.

Bonne modélisation ! :)

---

Consultant et formateur

Si vous recherchez un accompagnement pour votre équipe ou une formation, je suis à votre disposition pour plus d’information, n’hésitez pas à me contacter !

Everybody likes options!

Who doesn’t?

In our day-to-day life, whenever you have to take a decision, you almost always have lots of options. If your goal is to go somewhere, if it’s near from where you are and if it’s sunny outside, you can go for a walk or by bicycle. If it’s rainy, you can pick up your car or take public transportation. If it’s far away, then you’ll have to book a train or a plane. Now your goal becomes booking a ticket and you still have tons of options! You don’t have too much money? Go with low cost companies! You still want to reduce the price? Well, do not put any luggage in the plane’s hold and take only your backpack. Then you can choose the flying class: economy, first, business, … you can choose whether to use your miles or any other loyalty card, choose between different flight schedule, even choose where you want to sit! And it’s almost the same for the train! Everything is up to you!

The same goes when your goal is simply to eat! You’re lazy? Go at the restaurant! What restaurant? You have tons of options: fast food, Asian food, Italian food, … unless you live somewhere where there’s no restaurant at all, then the only options you have stand in your fridge! But when you’re at the restaurant, have a look at the menu: you see all the options?

Whenever you have a goal, something to accomplish, you always think about all the possible ways to reach it. And if for any reason the option you did choose doesn’t work, well, you simply pick up the next one on the list.

We love to have all those options; we love to be able to pick up the one that fits to our need.

So why the hell, don’t we have such options when it comes to software development?

I don’t speak about the way you will implement something, I don’t speak about the technical decisions here. You might have some technical options in mind depending on what needs to be done (unless there’s an enterprise architect in the way…) I Speak about how to reach a business goal.

Worst-case scenario: you only have specifications that tell you what to do. In this nice MS Word document where everything is written in advance, you don’t need to search for options: you won’t find a single one. Just do it like it’s described, the choice have already been made. Even if you’d like to do something else, you cannot, simply because you don’t know the business goal to reach and what are the measurements to check to know if you succeed. Just shut up and code! :-)

At best, you have a user story:

As a Customer, I want a brand new Refer A Friend page so that I can invite my friends to join and receive a 10% discount

Actually, the real customer need behind this user story might tell you another story instead:

We really need to increase the number of our customers because if we don’t then we might be in big trouble pretty soon.

The thing is that the user story doesn’t tell you that.

Creating a “Refer A Friend” page is just an option amongst others to gain more customers. It’s no more than an assumption that this option will do the job. It has been chosen upfront by some business people. But what if they’d have asked you? Would you have chosen to create a “Refer A Friend” page or something different? At least I guess you would have brought some other options on the table.

It seems obvious but you cannot have options without knowing the goal to reach.

So to answer my own question: we don’t have options when it comes to software development just because we often don’t know the real goal behind a user story or some piece of specifications. We don’t know what really is the customer need we’re trying to fulfill when developing a new feature.

Usually, what is written is specifications or described in user stories is not a goal; it’s just a way to reach a goal, it’s just a single option an assumption that it will work.

Think about how things would go if military ground troops would act like developers. They’d receive their orders as specifications from the military command saying exactly what to do. A nice and clear step-by-step procedure, written a couple of months before the d-day in order to guide them once on the field. Just like a poor developer they would only have one way to succeed in hand, just a single option. But in the meantime things have changed. Once on the ground the troops got quickly caught in a trap. It’s not their fault, though: it was not written in the specs!

Military do the contrary instead: they mainly receive the goal to reach from the commanders. They might have some options to start with, but it’s also up to them to bring some new ones as the mission evolves. The commanders trust the troops! They know that they were trained to react and adapt the right way as things change.

To solve this problem in software development, well, there’s no secret: you’ll need to bridge the communication gap between business stakeholders and dev teams. Communication and trust are key to success.

If business wants to keep up with specifications, why not suggest going a bit further with Gojko Adzic‘s Specifications by example.  This will help you to to cooperatively define the specifications based on real examples.

If you’re tied to user stories, then they should definitely sound like business goal instead of solution ideas (which is often the case). One simple way would be to find out two options that bring the same benefit. But an easier way would be to look into impact mapping where stories are not considered as commitments but options!

© Özlem Yüce from “How to train your HIPPO”

But the best thing to do might be to follow Jeff Patton‘s advice:

We don’t need an accurate document, we need a shared understanding

Discovering things collaboratively using Jeff’s User Story Mapping or Alberto Brandolini‘s Event Storming might be the best way to find options. Working together with business people will obviously let you know the real customer goal to reach.

Now take your shovel and dig up some options!

You’re brilliant? Stay humble!

In France there’s a humorist who was really brilliant. He used to make everyone laugh while treating hot topics like religion, racism and such other hard-to-joke-with things. He was really smart. The way he was dealing with those near the edge themes was really impressive. This is really hard nowadays to be able to joke about those topics and he was doing it really well while condemning them and raising awareness.

But one day, for any reason, he crossed the line.

Everyone taught it was shocking on purpose; he was so smart that people taught he was only showing how much hate could be harmful! But he wasn’t… This feeling people had, thinking he was playing a role, only last a few months. Everyone understood that he was not that brilliant guy anymore.

He’s now banned from any TV show and many cities don’t even allow his to stand up in their theaters anymore.

But why am I speaking about that guy?

Well, it might be excessive but this story might be quite similar to things we experience in software development: Brilliant people don’t always deliver the right message.

I’m sure everyone knows someone brilliant. It might be your colleague, the one that writes code so fast and that knows everything. You know, the one that understands complex concepts faster than anyone and for whom everything seems so easy! Look around you, you see her/him, right? ;-)

It might also be someone you heard about. A book author or someone who invented something really powerful you use everyday at work or even someone who created a programming language on his own! Yes I’m speaking about all those brilliant few. The ones you almost don’t dare to speak to because you don’t want to ask stupid question and feel like an idiot!

Those brilliant people are so good at what they’re doing that if they state something than it might be the right thing to do!

But wait, what if it was not? What if those messages they were delivering were only good for people like them? Meaning they only apply to a few of us.

They are influencers. And being in that position, they ought to act accordingly. They must understand that delivering the wrong message could hurt a lot of people that don’t have the experience to argue against them. They will believe them, blindly.

When you have natural capabilities to understand quickly complex things or resolve difficult problems, do not feel like this is the case for everyone around you: it’s not.

A really well known brilliant guy did recently an anti Agile/Scrum talks that resonated with a lot of people. Because of who he is and because of what he has accomplished so far, he was considered as the messiah for many developers. But a majority of people who loved his talk forgot one important thing: this might be ok for him, but not for them!

This guy has obvious natural capabilities coupled with a lot of experience. But he forgot one important thing: brilliant people are also humble. Brilliant people are able to adapt their talk to the average level of the crowd. Brilliant people will teach others how to grow and improve themselves. Instead of thinking that because this is how they do this should also be everyone’s way; brilliant people know that things that might work for someone might not work for his neighbor; things often depend on the context.

The most important of all: Brilliant people do deliver the right message.

Eminent scientist, reputed programmer or even you, the one in the open space for whom everything is easy; if you want to be brilliant then try to be humble. Stop thinking that everyone is as smart as you are but do strive to help people around you become better.

The good enough software

A couple of days ago, I was having a coffee with one of my colleague and he told me that:

“Almost every time we’re asked to develop a new feature, we provide our project leader with 3 ways of doing it: the quick & dirty way, the way we’d do it if we’d have the time to and, finally, the one in the middle: the way that allows us to meet the deadline doing something acceptable. Most of the time the later is chosen.”

Even if he told me that he was not so happy with it, he also said that it’s how it is and that they did not have the choice if they wanted to meet the deadline :-(

This plague has a name: the good enough software.

Kevlin Henney has a nice definition for this, here it is:

The good enough in good enough software refers to intrinsic quality: defect management, code quality and performance are not prioritized or managed as critical qualities. Deadlines end up being the focus, starting with initial time to market. While such an approach can appear to pay benefits in the short term, such an approach makes little economic sense in the long run — accidental costs and delays arising from quality issues come to define the development rather than features. (from InfoQ)

As a developer you should not provide 3 different ways of doing things. You should not jeopardize your projects by lowering the level of quality you’d like to put into. It’s up to your project leader/manager to strive to reduce the number of functionalities instead, it’s part of their job and this is where negociation is encouraged! As a developer you should always focus on defect management, performance and craftsmanship the same way.

This is why worse is better.

Worse is better has been coined by Richard Gabriel and as stated on Wikipedia:

The idea is that quality does not necessarily increase with functionality. There is a point where less functionality (“worse”) is a preferable option (“better”) in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.

If you do care about this, and I know you do, but your management don’t, well, quit your job :-)

And while you’ll be doing job interviews, please ask people you’re gonna meet this simple question: Is code quality taken as a corporate asset? You’ll know if it’s worth applying for a job there!

Does your code speak business?

There are many books and manifestos or even books about those manifestos :-) the aim of which is to teach you how to be more efficient. They provide you with diverse recipes and tools to be more efficient as a person, as a developer but also as organizations.

All those writings also have another important thing in common; they all say that in order to be more efficient you constantly need to focus on delivering value or even steadily adding value.

I did a presentation during a Paris Software Craftsmanship Meetup, where I tried to define what exactly value is and the kind of things you could put in place (and things to avoid!) to bring it down to your code or even within your tests.

Here you go!

The Phoenix Project – 5 reasons why you should read it!

tl;dr: buy it here!  ;-)

#1: It’s well-written

First of all, I won’t pretend that I’m able to judge the book’s literary quality as English is not my mother tongue. But the read is really gripping and absorbing and it’s quite hard to stop reading it, you want to devour it! The authors managed to find the right tone and the right pace to tell an 300-ish pages IT story,  which is a performance in itself!

#2: It’s real

Well, almost :-) Even if this novel is a fiction the story sounds pretty real. It tells things that will certainly resonate with you if you’ve been involved in an IT project. Whether you are a developer, a project leader, part of the operation team, member of the compliance department, the security guy or even the CEO, it will certainly remind your own past experiences.

#3: It’s unique

As far as I know, it’s the only one of its kind. I’ve read Commitment by Olav Maassen, Chris Matts and Chris Geary but it’s a picture novel (and by the way, go get your copy if you haven’t read it yet!). There’s also The Goal by Eliyahu Goldratt and The Gold Mine by Freddy and Michael Ballé but even if I did not read them (yet!) they seem both more business oriented (correct me if I’m wrong!).

#4: It strikes home

If you’re in the situation the main character is facing at the beginning of the book, then you will obviously have some ideas to get things better. Some of you might realize that your fate is not fixed and that there are other way to work, more efficiently!

#5: It’s not just limited to the finding

As the story goes on, you might learn about new things. You’ll discover the power of DevOps and Continuous Delivery just to name a few. You’ll find out what the Value Stream is all about and how to increase its efficiency. What Lean can bring you.

Get your copy!

DDD is not architecture

While reviewing some résumés last week, my eyes were caught by this guy writing:

• I’ve recently been focused on migrating to a DDD architecture

And some lines further:

• Architecture redesign: Solution shifted first to MVC then DDD, multi-layered architecture implementation.

Apparently this guy tried to do some MVC but seemed not to be happy with it, so he decided to shift to DDD. This technique must certainly come from a secret chapter of Eric Evans’ Domain-Driven Design book that only this guy knows about! ;-)

Unfortunately this is not the first time I hear and see people confusing architecture and DDD.

A couple of weeks ago I went to a meetup where someone proposed to do a DDD Kata. I was quite enthusiast to participate and I started to imagine that we were going to do some Event Storming. Well, I must admit that I was quickly disappointed seeing the guy starting the kata by opening his favorite IDE. His idea was to do some code refactoring using DDD principles. To tell you the truth I was quite curious to see how he would manage to do so! The kata was similar to the Guilded Rose one; there was a lot of unreadable legacy code that you had to refactor to be able, at the end, to add a new feature without breaking the whole stuff. The guy quickly stated things like “as DDD tells us, let’s extract some interfaces so that we can put their implementations in another layer” Ouch! It took them some time (and a few remarks made by a couple of attendees) to realize that they were not doing any DDD at all.

So why do people keep on confusing DDD and architecture?

What I find as being the most likely explanation is that it’s due to the presence of the “design” term in Domain-Driven Design. But as Grady Booch says “All architecture is design, but not all design is architecture”.

DDD is not a technology; it’s a set of principles that will help you to deal with the complexity of an application domain by modeling it. DDD is focused on the domain and its logic where “Software architecture introduces structure and guidelines into a software system, leading to consistency and clarity” to quote Simon Brown.

But keep in mind that principles do impact your software architecture. Going with DDD will obviously lead you to choose the software architecture that will welcome it warmly. Architecture styles like Hexagonal Architecture or Onion Architecture will definitely help you to accomplish that as it will isolate the domain and avoid the business logic to be tightly coupled with any infrastructure related technology.

Should you go with DDD? Well, as it’s often the case, it depends! From my point of view it mainly depends on your domain complexity: the more complex it is the more you might benefit from DDD. But every choice comes with a cost; it will be up to you to evaluate the need and as Simon Brown says: “Principles are good, but make sure they’re realistic and don’t have a negative impact”!

---

Consultant et formateur

Si vous recherchez un accompagnement pour votre équipe ou une formation, je suis à votre disposition pour plus d’information, n’hésitez pas à me contacter !

Buy cheaper books!

Every week plenty of interesting books are released.

Besides the fact that I don’t have the time to read them all, it could start to be quite expensive trying to buy them all!

That’s why I became a big fan of “early release” programs most of the publishers are offering.

O’Reilly, Apress, Manning … they all have their own program which basically offers the same kind of things: an early access to a still-in-development version of forthcoming titles at a lower price!

The nice thing is that as soon as you bought an early release ebook, you will be warned about new version as they become available for download. You’ll even receive (most of the time) the completed ebook as soon as it got released.

Check-out the current roster of available early release books from:

• O’Reilly
• Manning
• Apress
• The Pragmatic Bookshelf

Do no forget to also have a look at Leanpub catalogue. Some of their books are work in progress too (I did not find a specific section on their site, though) You’ll also be warned as soon as a new version is online and you’ll be able to download the final version for free. They have some really reasonably priced bundles, nice free books to download and you can even set your price for paid version!

Happy Reading!

Extreme Programmers Paris #XProPa – Second meetup

Yesterday I went to the second Extreme Programmers Paris Meetup (#XProPa)

It started with an application code appreciation exercise. The idea behind this is was to go through some code and see how the developer who wrote it tried to be as clean as possible.

The code we went through has been presented by its author himself! Clément Boudereau brought his nice HardMock legacy code mocking framework’s code and explained us why he wrote it that way.

We needed first some explanations on what HardMock is all about before going deep into the code itself! Hardmock is a mocking framework that can produce integration test based mocks. It will work as a behavior recorder that will store the generated mock on a file on your hard drive. All you need to do is to write a complete integration test that might have to connect to a DB through DAL calls, or call any external services, and then extract all the interfaces for any dependencies needed and record the corresponding behaviors. HardMock seems to be a nice way to be able to refactor big balls of mud without having the need to spend as much time on refactoring hard to maintain unit tests as refactoring the legacy code itself!

Now that we knew a bit more about HardMock’s domain and its vocabulary it was time to see the code! Clément strived to make it as clean as possible: he made use of pretty well named variables and methods; he tried to be as SOLID as possible but at the same time he managed find the right balance between the need of abstraction and readability (like providing more than one constructor to users so they can directly call the one with the most common implementation)

At the end we saw a lot of well written code but the conclusion was that code was not like literature! Even if you know the domain, you can strive to be as clean as possible; it will be always hard to understand the whole story just by reading the code. And as Clément said, your code will never get clean enough; it’s an everlasting improving story!

The second part of the meetup was made of open space discussions about different topics people would like to speak about. I joined the Mob Programming discussion group where Thomas Pierrain told us the way they run their #SORLunchBox project and I also spoke about our own Mob Programming experience at my company.

As often during meetups, it was an open-minding night sharing thoughts with very talented and interesting people! Don’t wait no more and find out what meetups are next to you! See you there?

Bridge the gap between dev team and business people! – Idea #4

This article is the fourth out of an unlimited series (let’s say at least 5!) where I’m gonna try to give you some ideas and easy things to put in place in order to bring your team closer to business people.

Written so far:

• Let’s discuss!
• Impact Mapping
• Event Storming

Value Stream Mapping

First time I discovered Value Stream Mapping was when reading the very interesting “Lean Enterprise” book by Joanne Molesky, Barry O’Reilly and Jez Humble. The final version of the book will be released in December but the early release version is available for download at a lower price since a few months now.

A Value Stream Mapping is a method from lean-management that allows you to quickly visualize the flow of value delivered from the genesis of a project until the customer delivery. It has originated from manufacturing but it can easily be applied on software development as explained in “Lean Enterprise“.

The exercise is pretty straightforward, you just have to write down all the stages that are necessary to bring an idea to its delivery and write under each steps the Lead Time (LT) and Value Added Time (VA). The Lead Time is the elapsed time needed to arrive from a stage to another and the Value Added Time is the amount of time really spent on that step where value has been added (the real work)

When working with huge companies where there are a lot of processes and departments, the exercise might take some time to accomplish as you’d need to meet people from all the different department involved in order to collect all the data. For us it was quite easier as it took us only one and a half hour to end-up with this:

(Pink post-it notes represent process stages, LT and VA are written under each)

First thing to do is to select a recent representative project (the kind of project your company is used to do in terms of size, people involved …) and obviously one that has been released to the customer! Invite enough people to be able to determine all the steps and find out corresponding LT and VA. We were only 3 to perform the Value Stream Mapping (a Business Analyst, the Head of Development and myself). As soon as all the steps have been found out, we used time tracking and reporting tools to get the exact amount of time spent on each steps (the VA) and when exactly those started. Some of the steps might be done in parallel and iteratively, that’s why some sticky notes are under other ones (in that case the corresponding VA is the sum of the whole column).

As soon as you have written down everything, just sum up all the VA’s and LT’s (some conversion might be needed here as some figures might be in days and other in weeks or months) and divide the total VA by the total LT to find out the Value Stream efficiency rate. The lower it is, the bigger is the chance to easily find some process improvement ideas!

The very interesting part starts at the end of the exercise! Well, you know, everyone might have in mind where usually things are stuck and where you might need some improvement to speed the value flow. But having the Value Stream in front of you clearly helps to focus.

The Value Stream is the perfect medium to start collaborating. Invite a couple of key people to join (from development and business side) and talk together in order to find out what could be improved in order to speed up the flow of value delivered and avoid wasting precious time. List out all the ideas and try them! Redo the exercise later on and check if the efficiency rate increased!

You will get a better understanding between all the stakeholders of how work moves through the company. People from different departments and having different point of views join together and collaborate to improve the whole company’s efficiency.

Mission accomplished!