Enforcing boundaries with architecture tests – Blazor architecture at scale (W11, lesson 4)

What you learn in this lesson

spread the Kladde's boundaries across three lines: internal and project references, architecture tests over types, tests over the project graph

use ArchUnitNET to check that no module uses another module's implementation and that in an implementation only the module class itself is public

use the project files to check what the type check cannot see: references, cycles, a contract with references

compare NetArchTest and ArchUnitNET with data and recognize a rule that checks nothing

demonstrate a deliberately broken boundary and read the error message

A boundary that exists only in a document holds until the first deadline. Since W11.1 the Kladde has modules with contracts and a map of contexts; whoever writes a line in Kladde.Booking that touches Kladde.Contacts hears nothing about it as long as the compiler agrees. This lesson spreads the check across three lines, writes the second and third as tests that run with dotnet test, and breaks the boundary on purpose at the end, so that you know the messages before anyone on the team sees them for the first time.

Where the Kladde stands

The lesson presupposes W11.1: Kladde.slnx with the modules Kladde.Contacts, Kladde.Booking and Kladde.Tenders, each with a .Contracts project, plus Kladde.SharedKernel and the host Kladde.Web. From W11.1.2 the following applies: a module makes only its contract and its registration (AddBookingModule) public to the outside, everything else is internal. The test project tests/Kladde.Architecture.Tests already holds the tests of the context map from 0101; it references the three modules (not the host) and additionally reads the project files. Keep your names and carry the steps over.

What you learn in this lesson

Where the Kladde stands

This lesson belongs to course W11