Modulith economics

Make the modulith tenable.

A modular monolith does not fail because modules can't be drawn. It fails on safe composition inside one deployable — modules still have to coordinate through events, lifecycle, state changes, ordering rules and side effects. That coordination layer is the integration cost.

Spring Modulith helps you define module boundaries in a modular monolith. Fluxtion addresses the harder part — the event-driven coordination inside those boundaries: how modules exchange events, preserve ordering, trigger dependent logic, and produce an auditable execution trace. The two are complementary: Spring Modulith structures the modules; Fluxtion makes the coordination between them generated, deterministic and auditable.

Integration cost is paid once by the supplier, not repeatedly by every consumer.

The shift: who pays, and when

In conventional event-driven systems the consumer pays the integration cost every time — understand the component, wire it into callbacks and schedulers, preserve ordering, connect lifecycle, handle propagation, add audit hooks, test the composed behaviour, and repeat for every use case.

With inferred orchestration, the supplier attaches the integration semantics to the component itself — event handlers, triggers, dependencies, lifecycle, exported services, metadata. The compiler infers the orchestration from that structure. The reusable unit is not just a Java component; it is a component with its orchestration metadata attached.

Integration cost	Traditional	Inferred orchestration
Component authoring	supplier writes logic	supplier writes logic + metadata
Integration	consumer hand-wires, repeatedly	compiler infers from metadata + graph
Marginal cost per consumer	high	near-zero (if metadata is correct)
Reliability	consumer's integration skill	verified supplier metadata + generated orchestration
Audit / replay	bolted on later	supported by the generated processor structure

From mechanism to platform

1
Mechanism. Fluxtion infers orchestration from annotated components and a known object graph.
2
Developer. No hand-written event-dispatch or dependency-propagation glue.
3
Architectural. A modulith becomes practical: modules compose into one generated, deterministic processor.
4
Commercial. The cost of making logic composable moves to the supplier, amortised across every consumer.
5
Platform. A library of annotated components can become a marketplace of auditable event-driven capabilities.

What this is — and isn't

It is

Near-zero marginal integration cost for the consumer — paid once by the supplier and amortised.
Reliable composition that is verifiable — unit-test the component, JUnit the graph, replay the decision.
Scoped to one deployable: closed-world, in-process composition.

It isn't

Not "zero" cost — semantic understanding, versioning and domain validation still matter.
Not automatic correctness — two valid components can still compose to the wrong outcome. It removes the plumbing, not the semantic responsibility.
Not cross-network: across process boundaries you're back to runtime wires (Mongoose, Flink).

The reliability of composing third-party components rests on the metadata being true. That is the same asset as the audit story: the generated code and replay evidence let those metadata claims be tested rather than trusted. Composition is made explicit, generated, testable, auditable and replayable.

Start inside one platform

The first home for supplier-paid integration is an internal platform. A central team ships approved, "golden" components — pricing, risk checks, eligibility, validation, monitoring, AI guardrails, regulatory controls — with their orchestration metadata attached. Product teams compose them into one deterministic, auditable processor without rebuilding the coordination layer each time. One buyer, no two-sided cold-start, governance built in.

Example — a pricing modulith

A central team supplies approved pricing, eligibility, risk and audit components — each carrying its event handlers, dependencies and lifecycle metadata. A product team composes them into one generated processor, instead of hand-wiring callbacks and ordering rules. The composition is testable, auditable, and replayable from its input events.

A cross-organisation marketplace — where buyers purchase composable, auditable capabilities rather than isolated libraries — is the expansion of the same idea, not the entry point.

Write the logic once. Attach the orchestration metadata once. Compose it many times.

How the orchestration is inferred Compose components in the browser See the regulated-AI proof path

modulith economics → regulated proof → audit / replay evidence.