F# Inside, C# Outside: Architecting .NET Applications That AI Agents Can Safely Build en

AI coding agents write code fast, but they also drift: they bend rules, skip tests and blur architectural boundaries. This session shows how to build .NET Core applications where the architecture itself keeps agents (and humans) honest and trustworthy.

I will show you a recipe of a pure business core in F# and everything around it in familiar C#: ASP.NET Core minimal APIs, Marten for event sourcing and Wolverine for CQRS.
The core uses the Decider pattern (decide and evolve), and business failures are always valid values, not exceptions.
A thin facade exposes it to C#, which works well with F# unions.

Nothing of this is science fiction or vanishing words.
I've coded a real after-sales and repair application, for my company; we will look at the guardrails I've setup to make this work in an agentic workflow:

Executable specifications: Given / When / Then scenarios and property-based tests in F#, no mocks and no I/O.
Integration testing with self managed containers.
Architecture tests that fail the build when the domain depends on infrastructure or becomes mutable.
And of course even more for the harness.

You will leave with a structure you can get inspired, an honest view of the costs (tooling, onboarding, interop friction) and a rule of thumb for when this approach is worth it.

Tout ce que vous avez voulu savoir sur les Doublures de Tests sans jamais avoir osé le demander en fr

Vous vous posez des questions sur les doublures de tests ou ce qui est généralement et abusivement dénommé “mocks”.
Venez apprendre et comprendre ce que sont les bouchons, dummy, stubs, fake, spy et mock. Quand et pourquoi les utiliser en situation réaliste, et l’usage d’un fake versus un spy.

Tout ce que vous avez voulu savoir sur les Doublures de Tests sans jamais avoir osé le demander en fr

Vous vous posez des questions sur les doublures de tests ou ce qui est généralement et abusivement dénommé “mocks”.
Venez apprendre et comprendre ce que sont les bouchons, dummy, stubs, fake, spy et mock. Quand et pourquoi les utiliser en situation réaliste, et l’usage d’un fake versus un spy.

SOLID -> CUPID -> Cute DDD en fr

Do you think that SOLID is enough to satisfy clean code ?
Well, probably not.
This intensive, hands-on workshop invites you to push beyond and transforms a well known kata into modern, composable, and domain-focused code through a structured learning path.
We invite Participants to refactor the FizzBuzz kata, and give attention to the CUPID principles step-by-step.

Starting with a codebase that violates SOLID principles, we'll first refactor to CUPID-compliant design (Composable, Unix philosophy, Predictable, Idiomatic, Domain-based),
then shift to a functional programming paradigm that naturally aligns with domain modeling principles.
Along the way, participants will master modern C# idioms, immutable data structures, and algebraic patterns that support clear domain expression.

Mob Programming session. BYOB.

- **Prerequisites:** Familiarity with SOLID principles, basic refactoring techniques, and object-oriented design assumed.
- **Workshop Format:** Conducted as mob programming session with shared screen/projector. One driver codes while others navigate and discuss. All participants expected to actively contribute to collective decision-making process.
- **Workshop Scope:** Using the FizzBuzz kata as teaching vehicle. Initial codebase intentionally violates clean code principles for pedagogical purposes. Then, together, through little steps, we will refactor to cleaner and domain oriented code.
- **Learning Outcomes:** Workshop introduces concepts of CUPID and FP; always following the TDD principles.
- **Materials:** Code samples and slides provided with WTFPL.

Atelier Mob TDD et DDD, tester une architecture Hexagonale fr en

En 3 ou 4h, nous allons apprendre à mettre en oeuvre le TDD de manière concrète, avec une approche DDD pour un cas métier, et des adapters vers des services externes. Un cas simple qui fait se poser beaucoup de question. Préparez vous à être surpris.

Comprendre les tests unitaires et le besoin de doublures dans un début d’architecture hexagonale; clarifier ce que l’on appele doublure de tests.

workshop TDDD : Hexagonal testing with Doubles fr en

You're asking yourself: how to practically isolate my domain code from moving parts like databases or external systems, APIs... in the simplest way either. How can I do that without integration testing. Are Unit Test sufficient? Can I apply TDD literally?
I've heard about mock as a perfect solution to test my dependencies.
Well, we need to talk. Better than that: we need to code!
Let's work on a very concrete and representative example. And let's mob it!

Format: 3/4h ( live coding/workshop) ; fish bowl MOB programing
Isolate domain rules and invariants
Add external system and test then
Learn about test doubles : stubs, spy, fake, mocks
When and how to use it? How to avoid mocks.

We will work on Concrete examples:
- ask time / generate random values (like UUIDs)
- send a mail / print an invoice
- access to an external resource (like a file)
- invoke a read/write repository
- summon an API
Showing what’s legitimate and what’s beyond reason

Monads without Maths, but with Cats (live coding) en fr

You heard about Monads, but the maths behind it seems unreachable? Let's demystify it with an
hands on lab based on TDD and C#/Java/Kotlin (your choice) to simply have fun with Monads and never be afraid of them.
We will auto-learn about simplicity, clarity, Unix style, and fun(ctors).

PLan:
Common Issues in Code
Basic Principles of a Monad
A Simple Case: Option
Where to Find Monads?
Hands-on: TDD Mob Programming
What to Do with a Monad?
Further with Either... or Maybe
Let's Chain, Let's Bind...
Practical Case: Monads in a Web API
Further: Validation
Attention: Treat Your Monad with Respect
Comparison of Styles (What Is Complexity?)

https://docs.google.com/presentation/d/1VPWqxxqrudsR001B0mXeSCY3bdjvT_xdqbsCxj3Kqck/edit?usp=sharing

Les monades sans les maths (live coding) en fr

Les monades ne sont pas qu'un OVNI mathématique, mais un vrai paradigme de programmation qui peut s'utiliser à peu près partout dans votre code.
Quel que soit le langage. Peu importe les situations.
Je vous propose une brève intro orientée "pratique" et surtout du live coding avec du TDD pour démystifier la librairie LanguageExt que nous avons en C# / .Net

Vous allez voir, ça ne mord pas, ça ne griffe pas.

Etes vous prêt à arrêter de coder avec des null, des if, des loops, des exceptions et tout autre cochonnerie ?

slides:
https://docs.google.com/presentation/d/1VPWqxxqrudsR001B0mXeSCY3bdjvT_xdqbsCxj3Kqck/edit?usp=sharing

What is a testable architecture for APIs and cloud native ? en fr

Your APIs rely on architectural decisions.
Software architecture has so many facets, so many variations.
A true matter of style, a patchwork of proposals, influenced by fashion trends sometimes.
But how testable is yours?
And what is a good test, in your humble opinion?
What are the genuine characteristics of effective tests?
What are your expectations when it comes to bring your systems under tests?
Let's analyze those crucial, almost philosophical questions (I doubt, therefore I test? Or the opposite ?).
Integration(s), connascence and testability are crucial to question when time comes for architectural choices.

Qu'est ce qui rend une architecture logicielle testable ? en fr

On parle beaucoup de TDD, avec toujours, hélas, beaucoup de polémiques.
La qualité d'une solution logicielle, d'un produit fiable ne peut pas se résumer à une couverture de tests.
L'architecture logicielle a tant de style différents, tant de variations, de chapelles même.
Dans ce maelstrom de propositions, souvent trop influencées par des tendances de mode, laquelle choisir sous l'angle de la testabilité ?
Et d'abord, qu'est-ce qu'un bon test, selon votre humble avis ? Quelles sont les véritables caractéristiques de tests efficaces ?
Quelles sont vos attentes lorsqu'il s'agit de soumettre vos systèmes à des tests ? (couverture de code, expressivité, stabilité, vitesse de feedback, qualité des reports, lisibilité, maintenabilité).
Les tests sont aussi importants que votre code ? Sans aucun doute, ils subissent lourdement les conséquences de vos choix d'architecture logicielle.

Analysons ces questions cruciales, presque philosophiques, que dise je ! Je doute, donc je teste ? Ou l'inverse ?
L'intégration, la connascence et la testabilité sont des aspects cruciaux à questionner lorsque vient le temps des choix architecturaux.

.Net Core Testing: pushing the limits en

Let's discover and unleash the power of automated testing using xUnit with related technologies such as Containers and Benchmark Testing.
I invite you to a journey through several testing techniques, from simple to advanced.
We will cover solitary tests, then social tests, and going deeper into test containers and testing a rest API, but staying in the Unit test layer, not E2E. That's where we introduce UniTegration.
Live coding, real world enterprise oriented C# examples. Testing is believing.

https://docs.google.com/presentation/d/1lTZOmAj3TF0IgQi_aapyFcxdmEoXu8cw7epQ23jk8GQ/edit?usp=sharing

Code is the new Res Publica en fr

"A Battle for Power"

To you, code might just be a sequence of instructions executed by a machine or running in the cloud.
But in reality, it is much more than that.
Can we even begin to grasp what’s truly at stake?

Code is the vehicle that reveals how companies are structured — from their darkest corners to their brightest ideals.
It’s not just a technique; it’s a mirror.
What if, just once, we dared to look through it?

Because of the diversity in how code is produced in companies, the many possible forms of organization,
and the different credos and “chapels” created by code makers themselves,
I’ve witnessed countless conflicts and outcomes — some fortunate, others not — some polished, others left unfinished.
Code is a story written by humans — leads, engineers, testers, POs, SMs, EMs, CTOs…
And in the end, if things go well, something gets delivered: a product… or more.

I’ll reframe all of this in the broader context of human societies and the evolution of Work.
And I’ll try to answer these six questions:

What is code?

What stands behind the power to write code?

Is there a secret society inside your company?

What’s at stake in the struggle for power?

What forms does power take?

What are the techniques of power?

https://docs.google.com/presentation/d/1iqDs9J_DszTC1ytdnoa96W-GBaCErcKvK4-yG46oCsg/edit?usp=sharing

Le code est une Res Publica en fr

"Une bataille pour le pouvoir"

Pour vous, le code n'est surement qu'une suite d'instructions exécutées par une machine ou dans un cloud.
Mais il est en réalité tellement plus que cela.
Pouvons-nous même, nous faire une idée réelle de tout ce dont il est l'enjeu ?

Le code est le vecteur de l'organisation des entreprises, jusqu'à ses idéaux.
Ce n'est pas une technique, c'est un miroir.
Et si nous osions regarder au travers, pour une fois ?

À cause de la diversité à produire du code en entreprise, à cause de la multiplicité formes d'organisations possibles,
mais aussi des différents credo ou chapelles qu'ont créées les "faiseurs" de code; j'ai pu voir nombre de conflits, de résultats plus ou moins heureux, plus ou moins achevés.
Une histoire avec des humains, des chef-fes, des technicien-nes, des testeur-euses, des PO, des SM,EM. CTO...
au final, si tout se passe bien, un ou des produits…

Et aujourd'hui l'IA qui vient s'en emparer et nous en déposseder ... avec la promesse de la réduire comme simple commodité.

O' Really ???

Avant de spéculer, je remet tout cela en perspective avec les grandes Sociétés Humaines et l'organisation du Travail.
Et je répondrai à ces 6 questions :
Qu’est-ce que le code ?
Qu’est-ce que le pouvoir de faire du code ?
Y a-t-il une société secrète dans votre compagnie ?
Quels sont les enjeux du pouvoir ?
Quels sont les formes du pouvoir ?
Quelles sont les techniques du pouvoir ?

https://docs.google.com/presentation/d/1iqDs9J_DszTC1ytdnoa96W-GBaCErcKvK4-yG46oCsg/edit?usp=sharing

SOLID -> CUPID -> Cute DDD en fr

Pensez-vous que SOLID suffit à satisfaire le clean code ? ...
probablement pas.
Cet atelier immersif et pratique vous invite à aller plus loin et transforme un kata bien connu en code moderne, composable et axé sur le domaine métier.
A travers un parcours d'apprentissage structuré, Nous invitons les participants à refactoriser le kata FizzBuzz, en portant attention aux principes CUPID étape par étape (Composable, philosophie Unix, Prévisible, Idiomatique, basé sur le Domaine),
Suite à cela, nous évoluerons vers un paradigme de programmation fonctionnelle qui s'aligne naturellement avec les principes de modélisation du domaine.
En chemin, les participants maîtriseront les idiomes C# modernes, les structures de données immuables et les motifs algébriques qui soutiennent une expression claire du domaine.

Session de Mob Programming. BYOB (Apportez votre propre cerveau).

Cet atelier pratique propose de dépasser les principes SOLID pour créer du code vraiment propre. Les participants refactoriseront le kata FizzBuzz en appliquant les principes CUPID (Composable, Unix philosophy, Predictable, Idiomatic, Domain-based) puis adopteront une approche de programmation fonctionnelle.
**Objectifs :**
- Transformer du code violant SOLID vers les principes CUPID
- Maîtriser les idiomes C# modernes et les structures immuables
- Découvrir les motifs algébriques pour l'expression du domaine

**Format :** Session de mob programming collaborative (pas besoin d'ordi)
**Public :** Développeurs C# intermédiaires.
L'atelier démontre qu'au-delà des principes SOLID traditionnels, d'autres approches peuvent mieux servir la clarté et la maintenabilité du code, particulièrement dans un contexte orienté DDD.

from SOLID to CUPID DDD — refactor Anemic Legacy to Expressive Domain Models en

Most real-world codebases share the same symptoms: bloated controllers, anemic models, cross-cutting concerns tangled together, and a growing gap between business language and the code that's supposed to reflect it.

In this workshop, we'll tackle a realistic eCommerce ccore domain in C# / Java / Python codebase — mixing too many concerns in a single monolithic model — and progressively reshape it using CUTE DDD: a pragmatic framework where design decisions are Contextual, language is Ubiquitous, models are Testable, and code is Expressive.

No slides-only theory. You'll read real messy code, run tests, review the code and refactor incrementally, assisted by your favorite LLM.
Beware, our harness is strong and it won't let you write any foolness 🤓

Participants can bring their own laptop, pair programming
But anyone is welcome without, and do a nice MOB programming session with us.

— leaving with concrete techniques you can apply on Monday morning.

Participants will go through the full DDD journey: from Event Storming and Domain Storytelling to identify Bounded Contexts, to Context Mapping to clarify boundaries, and finally to tactical patterns — Value Objects, Aggregates, Ports & Adapters, and making illegal states unrepresentable. Refactor against contexts, immutability, purity and ADTs.

From Dogma to Culture: redefining Modern Software Architecture for the Future en fr

In 2026, software architecture can no longer be approached as a top‑down, slow, and disconnected discipline.

By taking a critical look at historical approaches (TOGAF, big upfront design, Waterfall cycles) and today’s challenges (technical debt, microservices complexity, integration issues, security, performance), I’ll share a pragmatic, team‑centered, delivery‑focused perspective — one that reflects what developers actually experience every day.

The modern architect is no longer a technical oracle or a guardian of abstract standards. She/he is a cultural facilitator, responsible for ensuring flow, coherence, code sustainability, and for creating the conditions that allow teams to deliver frequently, confidently, and safely.

This session reframes architecture as a narrative and socio‑technical function: “build the right thing, build the thing right, with the right people.”

My goal is to offer a clear synthesis of what developers expect from architecture and architects today: less dogma, more purpose; less control, more collaboration; less rigidity, more adaptability.

And above all, a shared culture that withstands time, change… and AI.
I’ll show why this is a cornerstone for the present — and for what comes next.

l'Architecture vue par les Devs de 2026 ... et du futur en fr

En 2026, l’architecture logicielle ne peut plus être pensée comme une discipline descendante, lente et déconnectée du terrain.

À travers une analyse critique des approches historiques (TOGAF, big upfront design, cycles Waterfall) et des difficultés contemporaines (dette technique, complexité microservices, problèmes d’intégration, sécurité, performance), je vous propose une vision pragmatique, centrée sur l’équipe et le delivery, celle qu’un développeur vit réellement au quotidien.

L’architecte moderne n’est plus un oracle technique ni un gardien de standards abstraits : il devient un facilitateur culturel, garant des flux, de la cohérence, de la soutenabilité du code, et du cadre qui permet aux équipes de livrer fréquemment, sereinement et en sécurité.

Cette session redéfinit l’architecture comme une fonction narrative et socio‑technique : “build the right thing, build the thing right, with the right people”.

Mon but est de vous apporter une synthèse claire de ce que les développeurs attendent aujourd’hui de l’architecture et des architectes : moins de dogme, plus de sens ; moins de contrôle, plus de collaboration ; moins de rigidité, plus d’adaptabilité.

Et surtout, une culture partagée qui résiste au temps, au changement… et à l’IA.
Je vous montrerai que c'est là une clé de voute pour les temps actuels et à venir.

Stop Paranoid Defensive Programming: Trust Your Types en fr

"Classic" defensive programming is noisy: if checks everywhere, cascading try/catch, null verified ten times over, a diffuse paranoia that bloats the code without ever making it truly reliable.

What if we stopped? Instead of defending against bad data, let's make bad data impossible to represent.

Two pillars:

The always-valid model: an object can only exist in a valid state. We parse at the boundaries, we build value objects that refuse to be born invalid, and the rest of the code has nothing left to check.
Advanced type systems (ADTs, sum types, Result, explicit states): expected failures live in the signatures, not in invisible exceptions. The type checker becomes your safety net, not your personal discipline.
The result: less defensive code, more confidence. The happy path becomes readable again, error paths become explicit, and robustness shifts from runtime to design.

These principles are not tied to a single language: they apply to any object-oriented language with an expressive type system. You'll leave with one simple conviction: the best line of defensive code is the one you no longer have to write.

What Attendees Will Take Away
Recognize and remove redundant defensive code
Design "always-valid" value objects that refuse to exist in an invalid state
Encode expected failures in the types (Result, ADTs) instead of invisible exceptions
Model a domain so that illegal states are impossible to construct
Apply these principles beyond a single language, across any typed OO ecosystem

Stop au code parano: la programmation défensive n'est pas celle que vous croyez! en fr

La programmation défensive “classique” est bruyante : des if partout, des try/catch en cascade, des null vérifiés dix fois, une paranoïa diffuse qui alourdit le code sans jamais le rendre vraiment fiable.

Et si on arrêtait ? Plutôt que de se défendre contre les mauvaises données, rendons les mauvaises données impossibles à représenter.

Deux piliers :

L’always valid model : un objet ne peut exister que dans un état valide. On parse aux frontières, on construit des value objects qui refusent de naître invalides, et le reste du code n’a plus rien à vérifier.
Les systèmes de types évolués (ADT, types sommes, Result, états explicites) : les échecs attendus vivent dans les signatures, pas dans des exceptions invisibles. Le type checker devient votre filet de sécurité, pas votre discipline personnelle.
Le résultat : moins de code défensif, plus de confiance.
Le chemin nominal redevient lisible, les chemins d’erreur deviennent explicites, et la robustesse passe du runtime au design.
Les chemins de votre code se parsèment d'aiguillages. Efficaces, lisibles, sécurisés.

Ces principes ne sont pas propres à un langage : ils s’appliquent à tout langage orienté objet doté d’un système de types expressif. Vous repartirez avec une conviction simple : la meilleure ligne de code défensive est celle que vous n’avez plus besoin d’écrire.

Ce que les participants repartiront avec :

- Reconnaître et supprimer le code défensif redondant
- Concevoir des value objects “always valid” qui se refusent à exister invalides
- Encoder les échecs attendus dans les types (Result, ADT) plutôt que dans des exceptions invisibles
- Modéliser un domaine pour rendre les états illégaux impossibles à construire
- Appliquer ces principes au-delà d’un seul langage, dans tout écosystème OO typé.