modules.md

layout
default

Modules

Even if targeting a distributed architecture or a "modular monolith" - the notion of the module is key. A common starting point for a "modular monolith" is some version of feature slicing. Where a feature is either a command or query. This notion of a thin slice maps to the early days of "micro frontends" where a feature slice goes from a web component to a FaaS function.

Commonly these feature slices utilize a larger model, where aspects like business rules and transaction boundaries doesn't fit pure use-case slicing. The need for a other boundary starts emerging. The entry point might look familiar through commands and queries, with addition to support eventing. The module protects a model through a boundary façade with signatures for handling commands, queries, eventing (incoming/outgoing).

With this notion of a module, being part of a monolith or a distributed system start to look the same.

*"The modular monolith’s beauty is that the software architecture looks surprisingly similar to the microservices architecture you might draw if you were so inclined."

The usage of such approach lends itself quite good to having a "pure domain" or "functional core". Where we could keep infrastructure on the outside and adapt use cases to different protocols. (Related video)

But the hardest part still remains - how to explore, find, define and evolve the system boundaries using heuristics valuable for the product/system.