SwapOrganizing A Modular Monolith Around UI Workflows
Swap.Htmx pairs naturally with a modular monolith because both approaches reward clear ownership.
The UI is server-driven. The workflows are server-owned. The modules can be organized around cohesive slices of behavior instead of around frontend-versus-backend boundaries.
That alignment matters more than it may seem at first.
Why the pairing works
In a modular monolith, each module can own:
- its routes,
- its views,
- its interaction patterns,
- its business rules,
- its integration points with other modules.
That maps well to server-rendered workflows because the place that decides what the UI should do is close to the place that knows the business rules.
The alternative many teams fall into
Without that module ownership, interaction logic gets spread across shared helpers, generic controllers, frontend glue, and cross-cutting conventions that nobody fully owns.
The result is usually not flexibility. It is ambiguity.
Events become module boundaries
One of the cleanest ways modules interact in a Swap.Htmx system is through meaningful events.
That lets one module announce that something happened without forcing every consuming screen to depend directly on internal details. It is a useful way to keep workflows coordinated without turning the app into a web of hard references.
The design goal
The goal is not to create as many modules as possible. The goal is to let a team answer simple questions quickly:
- which module owns this screen,
- where does this workflow live,
- what can react to this event,
- where should this partial or handler belong.
If those answers are hard to find, the structure is already under strain.