The quotes are now built the way this module teaches: a domain model, an application layer with ports, a contract for other contexts and adapters on the outside. Sales has made a start. The rest of the Kladde is still in the projects from K2 and K3: Kladde.Core with the rules for contacts and appointments, Kladde.Data with one KladdeDbContext for all tables, Kladde.Web with everything else.

In this lesson, every context from lesson 4.2.4 gets this shape. The result is called a modular monolith: one program, one deploy, one database, but cut into modules on the inside that know each other only through their contracts. An architecture test watches over it in the build, and an ADR records why the Kladde doesn't become a bundle of microservices.

What a module is

A module is a bounded context in code. It has three properties:

  • It has a public contract. Other modules know only its *.Contracts project: integration events and, where needed, queries. Everything else is none of their business.
  • It owns its data. Its tables live in a schema of their own. No other module reads or writes them, not even “just quickly” with a join. You decided that in lesson 4.2.6 as data ownership.
  • It is registered as a whole. One line in the composition switches on a module with all of its adapters.

A module is not a microservice. It runs in the same process, is delivered together with the others and shares the database. What it has in common with a microservice are the boundaries. That is exactly the point: the boundaries are the hard and valuable part, and distribution over the network is only one of several ways to enforce them.