The Kladde is by now a whole system: a module per context, aggregates in Orleans grains, a sales pipeline with event sourcing, outbox and inbox, a network and a governance in Bicep. Since module 4.3 you have built the code in it in a single style, ports and adapters. You built it that way because the lessons said so, and you saw what it brings. What you have not seen yet: how the same feature would look in another style, and what the difference is in numbers.

That is what module 4.10 is about. You build a small feature, the follow-up, four times: in layers, in clean architecture, hexagonal and as vertical slices. Afterwards every version gets the same change, and every time you measure the same things. At the end of the module you use these numbers to decide in an ADR which style the Kladde is built in from now on, and an architecture test keeps the decision in the build.

This lesson lays the groundwork. It clarifies what code architecture protects against in the first place, assigns the five styles to the problems they were invented against, and sets the measurement sheet. Nothing gets built yet except the exercise repository kladde-styles and its measuring tool.

Four earlier lessons carry this one. Lesson 4.1.1 described architecture as the decisions that are hard to reverse. Lesson 4.1.2 put changeability and testability next to the five pillars as quality goals, in your Kladde as Q6 and Q7. Lesson 4.3.3 showed the anemic model, lesson 4.3.5 ports and adapters, and lesson 4.3.6 brought the rules of direction into the build with an architecture test built on reflection. None of that comes again here, but you need it to read on.

What code architecture protects against

A program nobody changes anymore needs no code architecture. It runs or it doesn't. Architecture in the code pays off only because code changes: a rule becomes different, a field is added, a database is replaced, a second way into the same feature appears. The question to every style is therefore the same, and it comes from your quality goal Q6:

When one thing changes, how many places have to change with it, and how expensive is it to check the change?

Three things follow that a code architecture is supposed to protect against:

  • Against ripple effects. A business change should happen in one place, not in ten. Every additional place is a chance to forget one.
  • Against expensive tests. Whoever can check a rule only by setting up a database, a web server and a token checks it less often. Q7 demands that the tests run without a network and in a minute.
  • Against getting stuck to technology. Database, framework and cloud service change rarely, but when they do, the change should not touch the business rules. That is the idea behind the line in Q6: "Kladde.Core uses 0 assemblies of EF Core, ASP.NET Core, SqlClient or Azure."

None of this is free. Every boundary in the code is one more type, one more mapping, one more project. A style is good if it draws exactly the boundaries your changes need, and no others. Finding that out is the work of this module.