HomeChallengesRepsProblemsLeaderboardTake a challenge

Modules and Shared Resources

The module graph is where the layering stops being a convention and becomes a rule. Wire it, and give every layer one shared vocabulary that ships inside the assembly.

Advanced25 min on the clock5 graded checks · 100 pointsLayered Architecture and Modular SystemsPro
Graded by reading your code against the checklist below.

What you build

  • An AbpModule per project, with DependsOn declaring the graph
  • Application.Contracts must NOT depend on the Domain module
  • The localization resource class in Domain.Shared
  • Register the resource and point it at its JSON
  • Embed the JSON with the virtual file system so the module carries it

Done means

The graph compiles bottom-up, and the contracts module cannot see an entity.

How it is graded

Published in full, before you start — every point is one of these and there is nothing else.

  1. Every project has an AbpModule with DependsOn+20Modules and their graph
  2. Contracts depends on Domain.Shared, never on Domain+25Modules and their graph
  3. The localization resource lives in Domain.Shared+20Shared resources across modules
  4. The resource is registered and pointed at its JSON+20Shared resources across modules
  5. The JSON is embedded with the virtual file system+15Shared resources across modules

What it teaches

Modules and their graphadvanced

Declaring what each module depends on turns a layering convention into something the compiler enforces, and it is the difference between a rule everyone agrees with and a rule nobody can break.

Shared resources across modulesintermediate

Text, enums and constants that several layers need have to live at the bottom of the dependency graph and travel with the module that owns them — otherwise a module installed elsewhere arrives without its own translations.

The rest of Layered Architecture and Modular Systems