Forem: Ludovic Fleury

From Software Engineer to Startup CEO: What Really Changes

Ludovic Fleury — Tue, 07 Oct 2025 14:38:25 +0000

Two years ago, I took over the leadership of a growing cybersecurity startup. I had spent most of my career in startups, mostly on the tech side, as contributor and in tech management. Later on, I had few experience co-founding, failing and exiting startups. But this was the first time I stepped into the CEO role of a company already running at full speed.

Moving from CTO to CEO doesn’t change what you know, it changes the weight of what you carry.

At startup scale, any C-level sees the same picture: the same information, the same constraints, the same growth target. The difference is weight.

As CTO, my impact was company-wide but my leverage and burden were anchored in the “T.” I owned the tech: teams, delivery, roadmap. Everything else touched my work, but it wasn’t mine to carry.

As CEO, everything connects back to me. But my true responsibility is not to do everything. It’s to provide the full picture: clear enough to see, strong enough to believe, shared enough to commit, and resilient enough to fail within.

In a lean, flat and small organization there is no buffer. You are exposed to every micro and macro operation. The context-switching is relentless. What saved me was my past in delivery management in startups: the ability to prioritize instantly, balance urgent versus important, and keep moving.

Managing director: the difference with a founder, the similarities with middle management

It’s not my company. I have a board to answer to, the actual owners. In that sense, it isn’t so different from middle management, where as a VP of Engineering I reported to the C-suite.

The big difference is this: the board validates (or not) my strategy, but they don’t hand me theirs. Strategy is the core of my job. They collaborate, bring insight, and challenge my thinking, but in the end they endorse my call.

In that way, it’s close to “managing up” as a VP or director. You build a plan with your teams, you present it, you advocate for it. The difference is that at this level you don’t work under top-down targets. You define the targets yourself. And you own the outcome.

So the job feels strangely familiar, yet heavier: you still need to commit both ways, convincing the board above and the teams below. Top-down and bottom-up at the same time.

Like any role in my career, the relationship with your “bosses,” direct or indirect, matters a lot. It comes down to trust and cultural alignment. When I choose a job, I always look closely at the person above me and the culture they bring. That’s what provides the safe space to do my best work.

The obsession with the why

Why does this company exist? Why does this product sell? Why do customers stay? Why do these problems repeat? Asking why has always been my most reliable tool: in code, in management, in strategy.

I had co-founded companies before, mostly on the tech side. As a co-founder I picked up some basics in legal, contracts, HR. Those hard skills eased the workload, but they never made the difference. What makes a startup succeed is always the same: the value you bring to a market.

In my previous startups, that market understanding came from my business co-founders. Here, it was different. I had to ask a new set of questions: why does this market exist? Why does it buy at this price? Why now?

My first responsibility was to trace the chain of events that brought the company here, in order to shape the strategic question that matters most: why will this company still be relevant five years from now?

Not every why is worth chasing. Sometimes the answer changes everything. Sometimes there is no answer, and I am still learning to accept that.

Stepping outside the comfort zone and into the customer’s shoes

I did not know much about cybersecurity before. But throughout my career I have loved jumping into new domains: retail, e-commerce, social, payment, education, music, AI. That is one of the privileges of software engineering. You can keep coding in your familiar stack while solving entirely new problems and delivering completely different solutions.

The sales motion also felt familiar. Most of our growth came inbound, through digital channels I already understood as a builder: SEO, social, community. The team was mostly software engineers, echoing my past responsibilities. And the company was still in its earliest years, a stage I know best.

As a former tech, the product we offer is something I could imagine buying myself. In a way, I moved from being in the customer’s shoes to being the provider. I swear by dogfooding. Seeing your product through the eyes of a real customer is the most authentic driver of a truly customer-centric culture.

The big question then became: why didn’t I buy this product before? Some of those answers became the foundation of my strategy. But you also have to challenge it with another question: why am I not the target?

Observability, business-wide

To ask the right questions, I first needed the right ground truth. I spent several months digging to understand everything. Launching a startup is overwhelming, and documenting every decision is usually overlooked. But here, the founding team had been meticulous. A company built by engineers tends to put observability at its core, and it showed.

It wasn’t about fancy dashboards or over-engineered KPI frameworks. It was about raw data of what was done, when, how and how much. The kind of ground truth that makes it possible to really measure a business.

Observability is more than tools and data. Data without a story is noise. A story without data is fiction. The real value lies in interpretation, and that goes far beyond dashboards or metrics.

It lives in meeting notes, in memos, and ultimately in the people who experienced those datapoints. You have to ask them “why,” listen to their interpretation, align the stories, and surface the conflicts. That is where observability becomes understanding.

Velocity and the feedback loop

One of the first principles I learned in developer experience, I think it was from Basecamp or GitHub, was simple: the speed of the feedback loop defines performance.

That idea stuck with me. I became obsessed with shortening every loop: local setup time, CI execution, branching, release cycles. Later it became onboarding time, and how quickly a team could pivot.

The same principle drives me today, just on a wider scope. The units of measurement have changed. Sometimes they are quarters or years instead of minutes or hours. But the strategy is the same: reduce cycles from months to weeks, operations from hours to seconds.

Sales cycles, support response times, customer onboarding, releases, incident resolution. The faster the loop, the faster the company iterates. Speed not only makes a business more resilient, it makes the product more valuable. In many markets, speed is the feature.

Ask for help, from the right people

Stepping into new areas like marketing and sales was one of the biggest challenges. In management that usually means hiring the right talent. But when you have zero experience in a field, how do you even define talent? The whole logic of skill authority I used in tech did not translate directly.

Or maybe it did, just differently. I realized I already knew people who were true experts, not because of their followers or their books sales, but because they were operational, in the field, grounded in the day-to-day reality of building. That context made their insight invaluable because it connected to mine.

I cannot thank enough those who picked up my calls, answered my emails, replied to a LinkedIn message, shared a lunch, or a few minutes over coffee. People in marketing, in sales. Some even helped me qualify resumes. I owe them, big time.

For everything else, it’s not that different from engineering. Marketing is a pipeline. Sales is a pipeline too. Of course, they’re very different kinds of pipelines, but conceptually the logic is the same: something goes in, and if the system works, something valuable comes out.

The same principles apply: observability, acting on information, iterating. The actions themselves are different, but that’s where talent comes in. It’s no different than in engineering management. As a manager, I would hire someone prolific in a technology I understood conceptually, but without being hands-on myself.

Performance is a culture

That has not changed. I have always believed performance is cultural. The difference now is that I joined a company already performing. That meant its culture was working. The real task was not to fix it, but to understand why it worked, and why some changes were still needed.

It is about continuity, not perpetuity. In engineering we talk about continuous integration and continuous deployment, frameworks that enable fast change. It is the same here. The goal is to build a company that embraces change, not one that changes everything for the sake of it. Like engineers say: “if it ain’t broken, don’t fix it.”

Conclusion

Software engineering and tech management gave me great tools to onboard into this new adventure. The agile manifesto is not about code, it's about value. That’s why its principles of iteration and collaboration apply just as well outside engineering.

Of course, it has its biases. But the key is to stay aware of them. And sometimes the most powerful thing you can say as a leader is simply: “I don’t know.” That’s not weakness. It’s awareness and honesty.

HTTP API Lean Workflow: from contract to documentation

Ludovic Fleury — Fri, 02 Jul 2021 18:04:23 +0000

How do we rely on open source software to achieve collaborative API design and produce our documentation?

TL:DR;

A contract-first approach enables high collaboration and removes overhead.
Versioning contracts with the code since they share the same lifecycle.
Stoplight.io DX is a powerful API IDE for OpenAPI.
Enriching the OpenAPI contract with markdown reduces the cost of maintenance.
Rely on Redoc to expose the contract as documentation with a standard UX & UI.

Context

At Golem.ai, we are maintaining a platform and several services following the SOA concepts. Our protocol between these services relies on REST API level 2.

These API are either:

consumed programmatically (internally and by our customers)
used by several web applications (addressing both our business analysts and customers)

Contract-first approach

There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

Designing API is a tough job. It's a highly structuring action where we define the boundary of "something". These boundaries exposes our knowledge and understanding about this "something": a service, a micro-service, a bounded context.

At Golem.ai, API design is not only about decision, responsibility & technicality. We advocate continuous collaboration to guarantee the quality & value of our APIs.

Adopting the dogfooding philosophy, we consume our own API. For every new feature, fix or improvement that impacts an endpoint, we follow this 3-step process:

Discovery: provider & consumer (example: backend & frontend) engineers sit together and discuss their technical challenges. Exploring code, questioning the shape (specification) and referring to the REST approach.
Agreement: ultimately, engineers will come out with a pragmatic and relevant solution. They update with Stoplight.io and version the OpenAPI contract with git. Usually, this contract has been drafted during the discovery by both parties.
Implementation: TDD is cheaper, our OpenAPI contracts include examples that provide a free mock for the client and free test assertion & server-side validation.

Adjustment: nothing is perfect and near perfection takes time and iteration. Developers can adjust an endpoint but they have to go again through steps 1, 2 & 3. Hopefully, adjustments are usually small and the whole process is short, 5 minutes tops: a slack message, a meeting using screen sharing and a quick discussion will lead to a git commit updating the OpenAPI contract.

Contract as Documentation

We needed more than a contract or a reference to on-board, assist, and guide developers using our API.

Documentation needs maintenance and its lifecycle is tightly bound to the implementation.

After assessing solutions on the market, we realised that most of the option would either involve changing our workflow or adding complexity to sync the documentation.

We finally decided to use our OpenAPI contract as documentation with Redoc (read more below).

The final workflow is simple, involving only the OpenAPI contract, versioned with the code. Our regular pipeline deploy the code and the documentation.

Side effects:

The code review validates everything: contract, code & documentation.
We didn't increase the complexity and the cost of our API.
Everything, from modelling to documenting, is tied to the lifecycle of the code: ideation, testing, release & deployment.

We ended up maximizing the value of every step of our API management, reducing the overhead for our developers, and removing conflict during integration. Collaboration versioned in an OpenAPI contract ensure predictable, meaningful, and enjoyable API development.

Tools: our API Stack

Stoplight.io

Stoplight.io is a game changing tool when it comes to managing & editing OpenAPI contracts.

We use the desktop application, so we can locally load our contract from our git repository into the editor.
Next level DX: none of our developers were familiar with OpenAPI and they didn’t have to be with stoplight: WYSIWYG for discovery, linter, direct edition in yaml/json, preview... Engineers can focus on the "what" & "why" rather than the "how".
Not intrusive: the desktop app lets you define your own convention, standard, directory structure, and workflow. It adapts to your needs and your organization doesn't have to fit the tool.
Provides a mock server locally. We can even quickly prototype our implementation: our local docker container fetches generated data complying to the defined contract.

Redoc

Redoc is a fantastic DIY tool, it leverages the markdown syntax and the OpenAPI description fields to enrich your contract. Basically, your contract is not only a reference, but becomes your documentation, example: this getting started.

As we maintained and documented several services, we needed to aggregate all our contracts/documentations under a single url (developers.golem.ai). This Fork by Volbrene solved this problem for us.

Once again, the stoplight studio desktop app is bliss, offering markdown edition & preview:

Git & Gitlab perk

API contracts are versioned in the same git repository as the related base code at /doc/OpenAPI.

Gitlab offers a nice perk based on a naming convention. Adding "openapi" in your contract file name enables a swagger-like preview in the gitlab code explorer.

Our engineering team is hiring in Paris, France. php/Symfony junior, contact us!

Many thanks to Azure: if you need proofreading contact her at heatherklamb@gmail.com

Domain Driven Design with PHP and Symfony

Ludovic Fleury — Tue, 02 Jun 2020 03:21:26 +0000

Personal take on Domain Driven Design with PHP and Symfony framework (2.x to 5.x)

This article was written in french here

Meaning is everything

DDD is gaining momentum in the Symfony & PHP community. I'm committed into a quest for "meaning" and so I'm a DDD evangelist.

Definition

DDD is a paradigm, an approach, a way.
Take a moment to reflect on the acronym because in order to get the pure value of DDD, you only need to understand these 3 words together: "Domain" "Driven Design" If you need to remember only one thing from DDD, it should be its name.

DDD isn't an software architecture or architectural style. DDD isn't about Entity, Value Object or Aggregate Root. They are convenient, and misleading, technicality in the object-oriented world.

DDD in essence is a shared understanding of the business domain crystallised in a base code by developers.

In practice

If business people would take the time to read a DDD code repository, they should understand 80% of it. Actually, high level language like PHP could be considered like a really poor subset of the english language. With DDD, the PHP code describe business rules, requirements, invariants in an "object-oriented english".

How does my code look like? Business domain processes described with a poor english:

$cashier->checkout($cart);
$cashier->charge($card);
$accountant->write($payment);
$compliance->verify($payment);

How does my classes look like? Business concepts written in a poor english:

namespace Legal\Company\France;

/**
 * French unique registration number for a specific establishments of a company
 * issued by INSEE
 * SIRET: "Système d'Identification du Répertoire des ETablissements"
 * 
 * @see https://www.economie.gouv.fr/entreprises/numeros-siren-siret
 */
Class Siret implements RegistrationNumber
{
    private Siren $siren;
    private Nic $nic;

    public function __construct(string $number)
    {
        try {
            $this->siren = new Siren(mb_substr($number, 0, 9));
            $this->nic = new Nic(mb_substr($number, 9));
        } catch (\Exception $exception) {
            throw new \DomainException('Invalid SIRET number');
        }
    }

    public function getNumber(): string
    {
        return $this->siren->getNumber() . $this->nic->getNumber()
    }
}

namespace Legal\Company\France;

/**
 * Unique registration number for a french company
 * Issued by INSEE, composing the first part of SIRET
 * Système d'Identification du Répertoire des ENtreprises
 *
 * @see https://bpifrance-creation.fr/encyclopedie/formalites-creation-dune-entreprise/formalites-generalites/numeros-didentification
 */
class Siren
{
    private string $number;

    public function __construct(string $number)
    {
         if (preg_match('/^[0-9]{9}$/', $number) !== 1) {
            throw new \DomainException('Invalid SIREN number');
         }

         $this->number = $number;
    }

    public function getNumber(): string
    {
        return $this->number;
    }
}

French developers might be familiar with the concepts examplified. However, if you aren't, it shouldn't take you too long to get a clear idea about the rules governing the french company registration numbers... simply by reading the code.

The direct benefits

More than readable code, we have expressive code translating literraly the business concepts & domain.

The code is also "immutable".
I didn't follow a best practice or a specific pattern, I just followed the french registration number rules. These numbers are immutable, so my code is immutable... and so these classes naturally fit the Value Object definition. It wasn't the goal of the implementation, it's a side effect of it.

Free your mind

Forget about "best practice", "design pattern", "fluent interface", "event dispatching", , MVC, SoC, SRP, SOA, RAD, CRUD, DRY...
Forget tech, Domain drives your design, domain comes first. Use your language (here PHP) to model the domain in the simplest possible way. Like a business expert will try to teach a toddler about a process, the devs are trying to make a machine process it while keeping the meaning explicit.

If you are using Entities with setter & getter, some Value Object in the /ValueObject/ namespace, you are missing the essence of DDD.

Again, DDD is not about respecting a specific way to implement stuff. DDD is about sharing the language between the code and the business domain.

Another value of DDD: the code has value at runtime AND at rest. The code is self-documenting a business process, acting as knowledge center for any human interacting with it.

DDD and Symfony

I started to read & implement DDD around 2014.
It took me a full year reading & implementing before I start to feel comfortable with my tooling (PHP/Symfony/Doctrine) and DDD. As Evans said:

"Don't fight your framework".

-- Domain-driven Design: Tackling Complexity in the Heart of Software

What is my "pragmatic" implementation of DDD with Symfony?
It really depends of the project & the complexity. But when I'm bootstrapping a new project or coaching a new dev, I usually rely on these simple guidelines:

I heavily rely on the command pattern, Symfony Messenger is a bliss
I do not use CQRS
I do not use ES
I use Behat & BDD at the Command/Handler level, full coverage.
I rarely use unit testing in project, 20-30% code coverage usually.

Why no CQRS & ES?

CQRS & ES are costly. They are extremely powerful solutions but you should use them only when it makes sense cost-wise & business-wise.

ES

Not so many php devs are used to Event Sourcing, and you won't find a lot able to design or use an Event Store properly. If you do not have a good model maturity remember that your events store directly reflects the history of your mistake, which might drastically increase the maintainability cost.

CQRS

CQRS truly shines at scale. This usually brings eventual consistency specificity between the write & read models. Do you really need this complexity and cost?

I implemented both patterns in different projects with PHP/Symfony, sometimes Doctrine, SQL & MongoDB

src structure

src/Controller/: Symfony controller
src/Command/: Symfony CLI commands
src/Action/: Command + CommandHandler
src/Domain/: AR, Entity, VO, Repository Interface
src/*: Infrastructure, other stuff.

Having something called /Domain/ sucks. But it also works.
Usually I replace "Domain" by the actual Domain we are tackling like /Ecommerce/.

Multiple domains issue

The problem starts when you have multiple domains. Opinions are quite strong about Core & supporting domain. Me? I don't care. I put everything in /Domain/ and then split if needed without qualifying as "Core" or "Supporting":

/Domain/Payment
/Domain/Compliance
/Domain/Delivery

It's simple & it's consistent.

What's in the "Domain“ ?

Inside the src/Domain/, I put every class that implement a business domain concern/concept. Some are persisted classes, others aren't, we also have the domain service there.

Since src/Entity doesn't exist anymore, Doctrine configuration is customised to scan src/Domain. Annotations are used to configure the persistence mapping, because "locality" is great.

Obviously when the project gets bigger, I do reorganize the /Domain/ in order to reflect the business domain:

/Domain/Legal/Company/France/RegistrationNumber/Siret.php
/Domain/Legal/Company/France/RegistrationNumber/Siren.php
/Domain/Legal/Company/France/RegistrationNumber/Nic.php

Command to conquer

The good

I love the command pattern:

command handlers play well with hexagonal architecture
command handlers bring consistency to manipulate my model layer, they are the unique entrypoints.
command handlers bring consistency to the application service layer, as they are the application service
command handlers define the transactionnal boundaries of a business process/action
command handlers help to deal & design with Aggregate Root

The bad and the ugly

I do abuse command handlers in some circumstances:

When facing unknown specs, lack of understanding, lack of available knowledge, when I'm lazy or in a rush: I implement in the command handler code that would be moved later into domain services or domain objects.
When I need to synchronize several business processes together, I use handler instead of the SAGA hell
When an AR implementation is really tricky or costly with Doctrine/Symfony. I do leak the implementation in the handler (it's bad, don't do this at home)

It sounds probably terrible for purist. I'm really sorry and really okay with that as it worked for me.

Naming the command

Commands are named against the process, the business action or behavior they
implement. I do adapt to reflect the specific business needs:

src/Action/Checkout.php
src/Action/CheckoutHandler.php

src/Action/FraudulentPaymentDeclaration.php
src/Action/FraudulentPaymentDeclarationHandler.php

src/Action/Compliance/Registration.php
src/Action/Compliance/RegistrationHandler.php
src/Action/Compliance/FrenchEstablishmentRegistration.php
src/Action/Compliance/FrenchEstablishmentRegistrationHandler.php

Maybe I would have used an imperative form for the Command: Register instead of Registration

-- Florian Klein

Business process, domain process or domain action are usually called by a unique name. It is important to tak the time to identify exactly the noun used to qualify this process. It's not always possible.

A verb might be a symptom of a weak domain understanding, example:

MarkAsRead
ValidateStatus

It's an advice, a best effort. In reality, in my repo I do have a lot of command phrased with a verb.

Implementation details

Commands are expression of (domain) intents. They are designed as simple DTO accepting only primitives

easing hexagonal architecture & [port/adapter](port/adapter implementation. Commands are the boundary between primitives and domain concepts in my application:

namespace Action\Compliance;

use Domain\Geo\Address;
use Domain\Geo\Country;

class Registration
{
  private string $userId;
  private string $name;
  private string $addressLine1;
  private string $addressLine2;
  private string $addressZip;
  private string $addressLocality;
  private string $addressCountry;

  public function __construct(
    string $userId,
    string $name, 
    string $addressLine1, 
    string $addressLine2,
    string $addressZip,
    string $addressLocality,
    string $addressCountry
  ) {
    $this->userId = $userId
    // ... boring stuff
  }

  public function getUserId(): Uuid
  {
    return new Uuid($this->userId);
  }

  public function getName(): string
  {
    return $this->name;
  }

  public function getAddress(): Address
  {
    return new Address(
      $this->addressLine1,
      $this->addressLine2,
      $this->addressZip,
      $this->addressLocality,
      new Country($this->addressCountry)
    );
  }
}

I do add Symfony validation with annotation to my command in order to pre-validate and dispatch to the user any input errors. Yet when it comes to enforce business rules: my domain concept (mostly Value Object) carry the implementation and any violation raise exception.

Implementing commands this way, ease hexagonal:

commands can be used as a Symfony/Form model you know: the "data-class".
commands can be composed from arguments of a Symfony/Console CLI command.
commands can be composed by a RabbitMQ worker/consumer from a unserialized message
command can be composed by an event processed from a Symfony/EvenetListener
from web socket, etc...

Once my command is passed to its handler, we enter the domain kingdom. Only dmain object are used over there (VO, Entity). A domain object provides strong guarantees:

its state is consistent, always valid (according to the business rules)
its state is mostly immutable
its public API allows only expected states change, following the domain specification

Using these domain object is a delight and a relief: the cognitive load is really low and the confidence in the system is very high.

Few tips:

I do not use typed ID for each AR/Entity (UserId, BookId). It's a pain to maintain with Doctrine.
When to use a VO (domain object) over a primitive? If the concept is important/relevant for the domain, if the concept follows rules from the domain: it's a VO. Otherwise, primitives are good enough. We're still in PHP, not in Java.

Command handlers ?

Command handlers coordinate the domain concept altogether (VO, Entity, AR).

It usually relies on a repository to fetch the concerned AR.

The handler then calls methods on the domain object (AR, Entity). Since Doctrine is following data-mapping, the handler manage the persistence cycle. Somtimes it coordinate other infrastructure details, usually anything related to IO required to compose a correct state in order to perform a business action.

Symfony Messenger does the heavy lifting. You just need to dispatch the command into the bus. from your CLI-command, HTTP controller, RabbitMQ consumer and voila, your handler will be invoked with the command.

Since I do not use CQRS, most of my commands are synchronous over HTTP. Using Symfony/Messenger to get the last result of a command execution, I just need to add some serialization to get a REST representation for the HTTP response.

Bounded Contexts (BC)

I consider one git repo as one bounded context. My understanding might & will change later. I could split BC's later.

A lot of BC's might mean:

domain misunderstanding
unknown about the domain
high complexity

Organizing BC's

Microservice are a pain to orchestrate. If you've got a devops army good for you. If not, locality works again:

src/BC1/Controller/
src/BC1/Command/
src/BC1/Domain/

src/BC2/Controller/
src/BC2/Command/
src/BC2/Domain/

Why? Because splitting BC is risky. Synchronising BC is costly. Your understanding will develop and will require a lot of refactoring & iteration: moving code from "BC's" and "domains" back and forth. Once you reach model maturity, split your repo, do your microservice show.

Conclusion

These are tricks or compromises that I found efficient to standardise a DDD approach with PHP, Symfony & Doctrine. These are not what you should focus on.

These are what you might wanna use to never have to think about the "how" and just focus about the "what" & "why".

Bonus track

Can I share/re-use concepts over BC ?

First: Never ever share Entities across BC.
Second: VO sharing is tough, especially with Doctrine, you would need to add your domain via composer/vendor and add mapping via yaml.
Last: Domain sharing is so-so. Like you can share a Geo domain (ISO Country, ISO Phone, ISO Currency)... but that would be very generic supporting domain.

Why "core" domain sharing is bad? Because from 2 different BC's if a domain is exactly seen & envisioned with the same properties, rules, shapes... Well you have only one BC. Careful, it's not because 2 BC shares domain names that they mean the same thing.

Example: For HR dept(BC) and Tech management(BC), "Employee" (Domain) means something very different even if they share some similitude.

BC collaboration, synchronization?

This is where things get hairy. First of all, BC should be isolated, you shouldn't have any direct coupling.

Data-wise, either you go for 2 storages or 2 schemas if you're in SQL.
if you are cheap and share the same schema... do not make relation between your BC's tables.

The command pattern is really helpful there. Let say I have a checkout process with a BC about payment and another BC about compliance.

Lazy: I can call my 2 commands PaymentCharge & PaymentFraudAnalyze at the same level (HTTP controller, CLI-command). Pro: It guarantee the loose coupling. Cons: your controller/cli-command carry some app/service/business sync.

Best: Go for event. Use the Symfony dispatcher, don't build your own stuff. Explicitly dispatch an event from your Command Handler. Create a specific EventListener in BC2. DON'T be lazy, do not go for "command sourcing pattern". Your BC1 is emitting an event ("Mom I'm Done"), your BC2 is listening, then transforming to its own command.

You can also add static analysis to enforce coupling rules (ensure BC aren't mixed). If you keep BC isolated (Data storage) & sync BC's with event, you are building scalable BC's respecting microservice requirements. Meaning, you could quickly move and split your BCs across repo and your infra.

Domain Driven Design avec PHP & Symfony

Ludovic Fleury — Sun, 31 May 2020 16:00:56 +0000

english version available here

Partage d'observations, considérations & recommandations concernant les développements pilotés par le métier avec PHP et le framework Symfony (version 2.x à 5.x)

note: pas l'habitude de rédiger en français sur les sujets techniques. Les sources, liens & références seront souvent en anglais

Redonner du sens au développement

DDD gagne en popularité dans la communauté Symfony/PHP. J'évoquais précédemment ma quête insatiable de sens qui motive mon évangélisation toute particulière pour le DDD.

Définition

DDD c'est un paradigme, une approche, une méthode, une façon de penser et de voir.

La valeur du DDD réside dans sa définition: "développement piloté par le métier". Si vous ne devez retenir et comprendre qu'une seule chose du DDD: c'est bien son intitulé. Si vous restez concentré sur le métier, le contexte métier, les règles métiers, le vocabulaire métiers, les acteurs métiers dès que vous lancez votre IDE pour coder: votre code sera en accord avec les principes DDD.

Le DDD n'est pas une architecture logicielle ou un style architectural. Les "Entities", les "Value Objects" ou les "Aggregates Root" ne sont que des détails techniques trompeurs, uniquement utiles dans nos univers orientés objets.

Le DDD c'est essentiellement une compréhension du métier cristallisée dans un dépôt de code par les développeurs.

Concrètement

Si les chefs de projets, les "stakeholders" ou les responsables métiers prenaient le temps de lire le contenu d'un dépôt DDD, ils devraient normalement comprendre 80% du code.

En réalité les langages de programmation de haut niveau comme PHP peuvent être considérés comme une version extrêmement appauvrie de l'anglais. En DDD, le code PHP décrit une règle métier ou un concept métier en "anglais orienté-objet".

A quoi ressemble mon code ? A des instructions métiers écrites dans un très mauvais anglais :

$cashier->checkout($cart) // $caissier->encaisse($panier)
$cashier->charge($card) // $caissier->debite($carte)
$accountant->write($payment) // $comptable->ecrit($paiement)
$compliance->verify($payment) // $controlleurFinancier->verifie($paiement)

A quoi ressemble mes classes "domain" (métiers) ? Là encore, à des concepts métiers écrits dans un anglais particulier:

namespace Legal\Company\France;

/**
 * French unique registration number for a specific establishments of a company
 * issued by INSEE
 * SIRET: "Système d'Identification du Répertoire des ETablissements"
 * 
 * @see https://www.economie.gouv.fr/entreprises/numeros-siren-siret
 */
Class Siret implements RegistrationNumber
{
    private Siren $siren;
    private Nic $nic;

    public function __construct(string $number)
    {
        try {
            $this->siren = new Siren(mb_substr($number, 0, 9));
            $this->nic = new Nic(mb_substr($number, 9));
        } catch (\Exception $exception) {
            throw new \DomainException('Invalid SIRET number');
        }
    }

    public function getNumber(): string
    {
        return $this->siren->getNumber() . $this->nic->getNumber()
    }
}

namespace Legal\Company\France;

/**
 * Unique registration number for a french company
 * Issued by INSEE, composing the first part of SIRET
 * Système d'Identification du Répertoire des ENtreprises
 *
 * @see https://bpifrance-creation.fr/encyclopedie/formalites-creation-dune-entreprise/formalites-generalites/numeros-didentification
 */
class Siren
{
    private string $number;

    public function __construct(string $number)
    {
         if (preg_match('/^[0-9]{9}$/', $number) !== 1) {
            throw new \DomainException('Invalid SIREN number');
         }

         $this->number = $number;
    }

    public function getNumber(): string
    {
        return $this->number;
    }
}

Les devs français sont sûrement familiers avec les concepts métiers ci-dessus. En revanche, si vous ne connaissez pas le fonctionnement des immatriculations de société en France, en lisant simplement ce code vous devriez avoir une idée assez claire sur le sujet.

Les vertus

Le code est "expressif" pas seulement "lisible". Il traduit mot pour mot les concepts et le contexte métier.

Le code n'est pas seulement "expressif", il est également "immutable". Je ne me suis pas imposé un design pattern ou une "best practice". J'ai simplement respecté les règles des immatriculations d'entreprises françaises (SIRET, SIREN & NIC), ces numéros sont immuables donc mon code est immuable... et donc ces objets s'apparentent naturellement à des "Value Objects", chouette. Le fait qu'ils soient des VO n'est donc qu'une simple conséquence de l'implémentation des spécifications métiers!

La cuillère n'existe pas

Oubliez les "best practices", les "design patterns", les "fluent interface", "event dispatching", MVC, SoC, SRP, SOA, RAD, CRUD, DRY... Oubliez la tech, seul le métier pilote l'implémentation, le métier est l'unique priorité.

Utilisez votre langage (ici PHP) pour modéliser le métier le plus simplement possible. Tel l'expert qui explique son métier à un junior, le dev "explique" explicitement et clairement dans son code un process métier.

Si vous implémentez des Entités avec des setters & getters, des "Value Object" dans le namespace \ValueObject\, vous êtes en train de manquer l'essentiel du DDD.

J'insiste: le DDD ne s'intéresse pas à l'implémentation, DDD c'est le partage d'un langage commun entre le métier et le code.

Dernière remarque au sujet de la valeur du DDD:
Toutes les bases de code ont de la valeur au moment de l'exécution par la machine. Concernant les bases de code DDD, elles ont une très forte valeur même non-exécutées. Ce sont des centres de connaissance, des patrimoines métiers pour les personnes qui travaillent avec.

DDD et Symfony

J'ai découvert le DDD autour de 2014, il m'a fallu une année complète, intensive de lecture et d'implémentation pour me sentir à l'aise et "efficient" avec mes outils (PHP, Symfony & Doctrine). Car comme Evans le mentionne:

"Don't fight your framework".

-- Domain-driven Design: Tackling Complexity in the Heart of Software

En fonction des projets et de leur complexité, j'adapte mes implémentations. Mais généralement lorsque j'amorce un nouveau projet ou que je coach un nouveau dev sur le DDD, je suis ces grandes lignes directrices:

J'utilise & j'abuse du command pattern (Symfony Messenger est parfait)
Je n'utilise pas le pattern CQRS
Je n'utilise pas le pattern ES
J'utilise Behat & le BDD au niveau de mes commandes/handlers, couverture de test intégrale
Je n'utilise que très rarement les tests unitaires, 20-30% de couverture en général.

Pourquoi ni CQRS ni d'ES ?

Parce que ça coûte un rein! (voir l'article suivant qui présente la stack soft & hard d'un ES.)
Ce sont des solutions ultra puissantes. Mais à déployer uniquement lorsque cela fait sens (rapport coût & besoin).

ES

Je pense qu'il n'y a pas beaucoup de dev php qui sont familiers avec l'event sourcing, encore moins qui sont expérimentés pour créer, maintenir ou modéliser un event store correctement dans le temps. Souvent, au début d'un projet on manque de "maturité" modèle, on apprend, on refacto et on migre. Mais sur un event store, aucune migration. L'historique reflète directement les erreurs d'implémentation passées, ce qui multiplie drastiquement les coût de maintenance logicielle.

CQRS

Le CQRS c'est vraiment puissant quand on passe sur des problématiques/volumes de très grande échelle. Dans ce type de contexte, le CQRS apporte directement la complexité de la "Cohérence à terme" aka eventual consistency. Je vous laisse envisager le (sur)coût de cette spécificité.

j'ai eu des expériences avec les 2 patterns, séparément et simultanément, dans des projets DDD, avec Symfony, parfois Doctrine et SQL/MongoDB

La structure

src/Controller/: Symfony controller
src/Command/: Symfony CLI commands
src/Action/: Command + CommandHandler
src/Domain/: AR, Entity, VO, Repository Interface
src/*: Infrastructure, other stuff.

Loin d'être idéal, le répertoire nommé /Domain/ est plutôt pratique. On peut remplacer le mot "Domain" par le nom spécifique du métier qu'on est en train d'adresser, par exemple: /Ecommerce/.

Le débat sur la pluralité des "domains"

Les questions existentielles apparaissent dès qu'on manipule plusieurs domaines dans son projet. Il y a des écoles & courants de pensées sur la question de l'existence du Core Domain et la séparation des Supporting Domains. De mon côté, c'est tranché, ces derniers sont organisés sans distinction particulière dans /Domain/:

/Domain/Payment
/Domain/Compliance
/Domain/Delivery

Problème réglé, c'est cohérent (consistent), ça gagne à tous les coups.

Le contenu du "Domain"?

A l'intérieur de src/Domain/, j'ai l'ensemble des concepts métiers utiles à l'implémentation. Il y a certaines classes qui sont persistantes (en base de données), d'autres non. On y trouve également les services métiers.

Comme src/Entity n'existe plus, la configuration de Doctrine est modifiée pour scanner le répertoire src/Domain/ dans son ensemble. Les annotations sont utilisées pour définir le mapping en base, car la localité, c'est également valable pour mon cerveau.

Evidemment, lorsque le projet s'alourdi, il ne faut pas hésiter à ré-organiser /Domain/ en reflétant les besoins métiers:

/Domain/Legal/Company/France/RegistrationNumber/Siret.php
/Domain/Legal/Company/France/RegistrationNumber/Siren.php
/Domain/Legal/Company/France/RegistrationNumber/Nic.php

Commande qui conquiert

L'usage

J'utilise systématiquement le command pattern pour les raisons suivantes:

les command handler s'inscrivent parfaitement dans les architectures hexagonales
les command handler offrent de la cohérence sur la manipulation de ma couche "modèle“, ils en sont les uniques points d'entrée.
les command handlers clarifient les frontières transactionnelles d'une opération métier.
les command handlers normalisent la couche de service applicative
les command handler soulagent les prises de tête sur les Aggregate Root

J'abuse pas mal de ces command handlers car je les détourne parfois de leur but premier:

L'abus

Lorsque j'ai beaucoup d'inconnus, d'incertitudes, un manque de compréhension, ou simplement lorsque je suis fainéant ou pressé: je les utilise pour stocker du code métier temporairement, à vocation à être déplacé ultérieurement dans des services métiers ou des objets métiers.
Lorsque je dois synchroniser plusieurs process métier entre eux: je les utilise au lieu d'implémenter des films d'horreur nommés SAGA
Lorsque l'implémentation d'un AR est particulièrement subtile, difficile ou coûteuse avec Symfony/Doctrine, je code une partie de cette logique dans un handler (ça craint, vraiment à éviter).

Cela doit sonner très faux aux oreilles des puristes, mea maxima culpa. J'ai fait mon deuil & je suis complètement dans l'acceptation car ça fonctionne très bien pour moi.

Le naming

Les commandes sont nommées d'après les processus métiers, les actions métiers qu'elles représentent. L'organisation s'adapte évidemment selon les besoins spécifiques:

src/Action/Checkout.php
src/Action/CheckoutHandler.php

src/Action/FraudulentPaymentDeclaration.php
src/Action/FraudulentPaymentDeclarationHandler.php

src/Action/Compliance/Registration.php
src/Action/Compliance/RegistrationHandler.php
src/Action/Compliance/FrenchEstablishmentRegistration.php
src/Action/Compliance/FrenchEstablishmentRegistrationHandler.php

Maybe I would have used an imperative form for the Command: Register instead of Registration

-- Florian Klein

Un process métier, une action métier porte généralement un nom. Il est important de prendre le temps d'identifier clairement une action métier par son nom. Ce n'est pas toujours possible.

Un verbe est un indicateur d'une potentielle faiblesse de compréhension du métier, exemple:

MarkAsRead
ValidateStatus

Attention, c'est une direction, dans mes dépôts il arrive très souvent d'avoir des commandes débutant par un verbe.

Détail d'implémentation des commandes

Les commandes sont donc les expressions d'une intention (métier). Elles sont modélisées & implémentées comme de simple DTO qui n'acceptent que des primitives facilitant l'architecture hexagonale ainsi que l'application port/adapter. Les commandes représentent la frontière entre les primitives et les concepts métiers dans mon application:

namespace Action\Compliance;

use Domain\Geo\Address;
use Domain\Geo\Country;

class Registration
{
  private string $userId;
  private string $name;
  private string $addressLine1;
  private string $addressLine2;
  private string $addressZip;
  private string $addressLocality;
  private string $addressCountry;

  public function __construct(
    string $userId,
    string $name, 
    string $addressLine1, 
    string $addressLine2,
    string $addressZip,
    string $addressLocality,
    string $addressCountry
  ) {
    $this->userId = $userId
    // ... boring stuff
  }

  public function getUserId(): Uuid
  {
    return new Uuid($this->userId);
  }

  public function getName(): string
  {
    return $this->name;
  }

  public function getAddress(): Address
  {
    return new Address(
      $this->addressLine1,
      $this->addressLine2,
      $this->addressZip,
      $this->addressLocality,
      new Country($this->addressCountry)
    );
  }
}

J'ajoute généralement de la validation Symfony sur les commandes pour gérer les erreurs "de forme" et avertir l'utilisateur. Là encore, via des annotations. En revanche, les règles métiers fortes sont toujours exprimées & implémentées dans les objets métiers (domain), une violation de ces règles entraîne systématiquement une levée d'exception.

Avec cette approche, l'implémentation de l'architecture hexagonale est enfantine:

Les Symfony/Form peuvent déclarer le DTO commande comme model, la fameuse data-class
Les commandes (CLI) de Symfony/Console peuvent initialiser le DTO commande avec ces arguments
Un Worker/Consumer RabbitMQ peut désérialiser un message et le transformer en DTO commande
Un Symfony/EventListener peut transformer un Event en DTO commande
Web Socket, etc...

En revanche, une fois que ma commande est transmise à son Handler, ce dernier manipule essentiellement des objets métiers (VO, Entity). Un objet métier fournit des garanties fortes:

Un état systématiquement valide (d'après les règles métiers)
Un état quasi-systématiquement immuable (immutable).
Une API publique autorisant uniquement des changements d'état prévus & spécifiés par le métier

Manipuler ce type d'objet métier est un réel bonheur, un soulagement: la charge cognitive est très faible, inversement à la confiance dans le système, très forte.

Quelques remarques :

Pas de typage spécifique pour les ID des AR et des entités (UserId, BookId, ...). Pénible à maintenir avec Doctrine. Dans certains projets très complexes, il m'est arrivé d'en utiliser.
Comment arbitrer entre VO (objet métier) et primitive?
Si le métier porte de l'importance à un concept, si le métier à des règles spécifiques liées à un concept : VO. Sinon, les primitives sont suffisantes. Cela reste du PHP, pas du Java.

Les command handlers ?

Le rôle des command handlers est de coordonner AR, les Entités, en bref, de coordonner les concepts métiers entre eux.

Très souvent ils utilisent un repository pour hydrater l'AR concerné par l'action, la commande métier.

Le handler appelle ensuite des méthodes sur les objets métiers (AR/Entité). Doctrine implémentant le data-mapping, le handler gère également les cycles de la couche de persistance. En sus, certains handlers coordonnent d'autres détails d'infrastructure. Très souvent relatifs aux IO nécessaires à la composition d'un état métier correct (satisfaisant) répondant au pré-requis d'une action métier souhaitée.

Symfony/Messenger prend entièrement à sa charge la gestion des commandes et des handlers. Depuis un controlleur HTTP, une Symfony/Commande ou encore un Worker RabitMQ, il suffit d'injecter le bus et de dispatch votre commande.

En cas de process métiers (trop) longs, passer les traitements des commandes en asynchrones ne nécessite quasiment aucun effort d'implémentation. Une simple modification de la configuration de Symfony/Messenger:

la commande est envoyée via un RabbitMQ.
Le handler connecté en tant que "consumer" de la queue.

Comme nous n'utilisons pas CQRS, une forte majorité des exécutions de commandes est synchrone, il suffit d'utiliser les fonctionnalités de Symfony/Messenger pour récupérer le résultat d'un handler, ajouter un peu de sérialisation pour obtenir une belle représentation REST pour une réponse HTTP.

Les Bounded Contexts (BC)

Par défaut, je considère qu'un dépôt git représente 1 BC. Ma compréhension évolue souvent lors d'un projet. Ou tout simplement, le projet grandi, grossi et se découvre également de nouveaux BC's.

Il m'arrive très souvent de séparer des contextes a posteriori. La présence de plusieurs contextes peut signifier:

une incompréhension du métier
de fortes incertitudes sur le périmètre métier
une extrême complexité

Organiser ses BC's

Les micro-services, c'est comme le CQRS: ça coûte un rein, si c'est mal orchestré: ça en coute deux. Si votre équipe dispose d'une armée de devops, vous avez de la chance. Sinon, le principe de localité, ça marche aussi:

src/BC1/Controller/
src/BC1/Command/
src/BC1/Domain/

src/BC2/Controller/
src/BC2/Command/
src/BC2/Domain/

Pourquoi? Séparer ou délimiter des BC's est une opération très définissante. Très risquée également. Synchroniser des BC's entre eux est relativement coûteux.

De cette façon, vous pouvez faire évoluer vos BC's, itérer, comprendre, refactoriser et déplacer du code de domain en domain, de BC en BC. Lorsque vous atteignez la "maturité modèle" et maitrisez la compréhension métier. Vous avez toute la liberté de séparer vos BC sur plusieurs dépôts... et de jouer avec K8s.

Conclusion

Il est temps de prendre du recul à nouveau après cette plongée parfois très détaillée des techniques adoptées pour DDD & Symfony. Rappelez-vous le but de cet article et son message: "Oubliez la tech & concentrez vous sur le métier"

Ces détails techniques sont un condensé de connaissances, d'expériences, d'astuces ou de compromis rassemblés au fil des années pour gérer simplement une approche DDD en synergie avec l'écosystème PHP et Symfony. Mais encore une fois: c'est le moins important du DDD.

Ces méthodes sont à disposition dans l'espoir de ne plus s'attarder sur le "comment" du code. Mais de concentrer les efforts & la valeur sur le "quoi" et le "pourquoi".

EDIT JUNE 2nd
Lucas Courot a réagi via twitter sur 3 points:

les commandes asynchrones
le coût de gherkin (Behat)
les notifications en place des exceptions

Un échange de plusieurs tweets résume nos idées, opinions, divergentes ou convergentes, toujours intéressantes.

Big ball of mud

Ludovic Fleury — Sat, 31 Aug 2019 16:15:14 +0000

Like many passionate people who program, I love progress. I'm fascinated by inventions and hyped by innovations.

I truly believe that professionals in our sector are curious about technology with varying degrees.

Many soft-skills or traits shape our work style. Rigorous, for instance, improves the robustness of our task. Creativity sparks crazy or smart hacks. Determination energizes our tough sprint.

Curiosity powers us, combine it with passion and this premix could kick off any profile into any sector.

Curiosity calls for discovery, innovation and progress. Obviously I never innovated, technically-speaking. Most of my “mind-blowing” or “life-changing” tech discoveries which pulsed my career were in fact established ideas that were theorised decades ago.

Curiosity fertilizes technical debt, risk we couldn’t afford, knowledge we partially understood, patterns naively implemented.

Bringing new tech, the last storage engine, the last framework and the last orchestrator is already a risk and you've got enough rants on Twitter for any of them.

Worse… I’ve witnessed lately that devs would bring in architectures or software engineering principles hyped by the community.

This. Is. A. Nightmare. Behind is a great intention, beyond is a technical debts factor on almost each commit.

Few years ago, when a junior would build and run a Web based application: the code could be spaghetti and the dedicated Debian, a public trash.
Now, imagine the same junior:

a backend language/framework with CQRS/ES using NoSQL and SQL, probably some messaging bus.
a frontend framework. The whole frontend ecosystem is trying to reach maturity at the moment.
a container orchestrator deployed in the cloud relying on 3 to 10 services.

A decade ago, rookies were crafting artisanal mess. Now, they produce industrial disasters. I'm no better and would surely be a 10x on that field.

The problem is always the same: "meaning", the lack of.
In our code, in our commit message, in our acronymized best-practices, in our company, in our team.

Internet is so real-time and crowded that trends are wrongly positioned as standards.

In the last 5 years, php was stormed by DDD (domain driven design). Amazing. Now the reality will be more like a repository that’s totally messed up with the infra layer, app layer, core domain, aggregate root, services.

DDD is trying to solve something so obvious that we missed the benefits of it, while paying the cost of the upfront complexity (+ the debt).

This is one specific example but others crossed my paths regarding dev, ops, data…

Stay focused on the meaning.

What's the meaning of what I'm doing.
What's the meaning of this feature at this stage of the project in this business context.
What's the meaning of this pattern/tech.
What's the meaning of these 400 LOC and 300K dependencies for this Hello World.

Iterate on your knowledge as well, failing is learning. Innovation is great: you bring it, you own the risk.

A big ball of mud or a serverless microservice won't define a meaning or express any.

The machine is still stupid, so our job is mostly to give it a meaning, meaningfully.

Thanks to Azurrex for the proofreading