Post-OOP Imperative Functional Java.
Model the process. Not the domain.

Most Java code still asks the wrong question:
"What is this domain object?"
But production systems fail, scale, and burn because of processes, not nouns.

If your system is a sequence of irreversible steps, model it as a sequence,
not as interacting objects pretending to be immortal.

This follows ideas from Railway-Oriented Programming (ROP):
errors and decisions are values, not control-flow side effects.

Modeling the process means you can read this top to bottom
and understand exactly what happens.
No debugger. No IDE magic. No tribal knowledge.

Control flow is explicit.
You see the execution order.
Nothing hides in constructors, annotations, or overrides.

Failure is a first-class concept.
Once it fails or decides early, nothing else runs.
No exception archaeology.

Processes > Objects.
Real systems are workflows where refactoring is safe.

Steps are reordered, removed, or replaced
without collapsing a class hierarchy.
Testing is trivial, small stepwise context — even for an AI.

Feed input. Assert final result.
No mocking five layers of indirection.

GraalVM / native-friendly.
No reflection rituals.
The compiler smiles.

Objects are great for long-lived entities.
User actions, payments, rules, and failures are short-lived processes.

I model what happens,
not what pretends to exist forever.

Influenced by:
Railway-Oriented Programming,
Functional Core / Imperative Shell,
Workflow / Saga patterns,
Command pipelines,
Unix philosophy,
and value-oriented libraries like Vanilla-DI.

Don't be stuck in axioms.

#PostOOP
#ImperativeFunctional
#ProcessOverObjects
#ModelTheProcess
#WorkflowFirst
#RailwayOrientedProgramming
#FunctionalCore
#ImperativeShell
#CommandPipeline
#ExplicitControlFlow
#ValueOrientedDesign
#ProcessModeling
#FailFast
#NoExceptionArchaeology
#ComposableSystems
#NativeFriendly
#GraalVM
#NoReflection
#DeterministicCode
#RefactorSafe
#SagaPattern
#UnixPhilosophy
#VanillaDI
#ModernJava
#ArchitectureMatters

In this session, Thomas Pierrain and Bruno Boucard explored the Functional Core, Imperative Shell pattern as an alternative to Hexagonal Architecture for protecting domain code. The recording includes a live-coding demo and a debate on the nature of Hexagonal Architecture.

You can rewatch the video on our website:
https://virtualddd.com/sessions/beyond-the-hexagonal-architecture-functional-core/

#DDD #SoftwareArchitecture #FunctionalCore #HexagonalArchitecture

Beyond the hexagonal architecture: Functional Core & ...

There are a few ways to split and protect your domain code from the intrusion of the technical stacks and other IT fads. After having promoted Hexagonal Architecture during all those years, we would like now to show one of its alternative: the Functional Core (combined with Imperative Shell). This short live-coding session will show you what it is and how it articulates with a cool domain. Also, and following some recent twitter discussions with Alistair Cockburn, we would like to finish this evening debating what hexagonal architecture is really about... Join us in this session with Thomas PIERRAIN - co-organizer of the #DDDFR user group and co-founder of 42skillz, and Bruno BOUCARD - developer, trainer, agile coach and speaker.

Virtual Domain-Driven Design
Simplify Your Code: Functional Core, Imperative Shell

This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT epis...

Google Testing Blog
@jonn Why is that? Is there too little training material that actually adheres to the "#functionalCore, #imperativeShell" design/architecture (cf. https://destroyallsoftware.com/talks/boundaries), or are #LLM|s not able to capture and reproduce that?
Boundaries