.NET Architecture

The namespace reads like the qualified identifier, so Claimwick.Spending.Expenses.UseCases.SubmitExpense names the product module aggregate and use case without a map. Namespaces follow folders under litespec/workspace/naming#keep-namespaces-aligned-with-folders, so a reader moves from a Domain aggregate to its handler its repository and its endpoint by name alone. This provision binds litespec/backend/architecture#organize-code-by-module-aggregate-and-use-case for .NET.

The Expenses aggregate of the Spending module fills one branch:

Claimwick.Modules/Spending/Expenses/Domain/Expense.cs
Claimwick.Modules/Spending/Expenses/UseCases/SubmitExpense/SubmitExpenseCommandHandler.cs

The handler above lives in namespace Claimwick.Spending.Expenses.UseCases.SubmitExpense.

Reviewed forWhich types miss the product module aggregate use case namespace or name one outside its folder? Look at the namespaces beside the folders in the shared kernel and modules projects.

Marked guidance: a reviewer answers this question.

A closed set refuses the catch-all folder by construction: anything outside the table has no home and review refuses it. Product-wide plumbing lives in the product layer folders and cross-module contracts in each module Contracts folder, while litespec/backend/architecture#place-a-type-at-the-lowest-folder-that-holds-its-consumers decides between a use case folder and the aggregate module and product layer folders. Module folders mirror record homes: use cases sit in UseCases/ folders, reactions in On{Fact}/ folders beside the module use cases, and jobs in the module Jobs/ folder.

Checked bylitespec model check reports mark-folder-drift for a folder outside its closed set or naming no declared record.

Marked checkable: the tool named here checks it.

One use case stays flat in its folder, with its command query result handler validator endpoint and transport models side by side. Types used by two or more use cases of one aggregate live in the aggregate Application folder, types used by two or more aggregates in the module Application folder, and product-wide plumbing in the shared kernel Application folder. A module publishes its typed identifiers in Contracts/Identifiers/, its refusals in Contracts/Exceptions/, its integration events in Contracts/IntegrationEvents/ and its cross-module ports in Contracts/Ports/, so the public surface of a module stays visible at the module.

Reviewed forWhich commands queries results handlers validators or ports sit outside their Application folder or their Contracts kind folder? Look at the Application and Contracts folders beside the use case folders.

Marked guidance: a reviewer answers this question.

A public type is an offer to every assembly, so an implementation left public invites callers it was never written for. Messages, results, markers, and ports stay public only when another assembly uses them; handlers, validators, and implementations stay internal sealed. Assembly scanning reads internal types through the one public marker, so it never justifies widening visibility.

This provision binds litespec/backend/architecture#keep-implementation-types-hidden for .NET.

Checked bydotnet build reports LS2001 for an implementation type that is not internal sealed.

Marked checkable: the tool named here checks it.

Layers are roles played by folders and use case files, whatever project holds them. A file takes its layer from its folder and, inside a use case folder, from its role suffix. Global usings import namespaces for every file, so the rule reads them too and they hide coupling from nothing. This provision binds litespec/backend/architecture#point-dependencies-inward for .NET.

Domain touches no Application Infrastructure or WebApi type and none of the persistence web mediator logging and injection namespaces. Application touches no Infrastructure or WebApi type and no ASP.NET Core type. WebApi touches no Domain type outside typed identifiers and shared-kernel values and no repository.

Checked bydotnet build reports LS1001 for a Domain type naming an outer-layer type and LS2018 for an Application or WebApi type naming a type outside its layer.

Marked checkable: the tool named here checks it.

A use case folder holds one use case flat, so a reference between two such folders couples two slices that change for different reasons. A reaction or a use case that runs another use case sends that use case's command or query and reads its result, which is the published way in, so those types stay nameable. A type named by two use cases belongs in the aggregate module or shared kernel layer folder that holds every consumer naming it, under litespec/backend/architecture#place-a-type-at-the-lowest-folder-that-holds-its-consumers. The rule applies to files and to global usings alike.

Checked bydotnet build reports LS2019 for a use case folder naming a type in another use case folder, other than one whose outermost type ends in Command, Query, CommandResult or QueryResult.

Marked checkable: the tool named here checks it.

The Contracts folder is the public surface of a module, sorted by kind: typed identifiers in Identifiers/, the refusals of rules other modules enforce in Exceptions/, integration events in IntegrationEvents/, the commands and queries other modules send with their results in Commands/, and ports that other modules call in Ports/. Domain may name the typed identifiers and refusals; ports and integration events stay outside Domain. A module that needs another module data reads it through a read port in the owner Contracts/Ports/ folder that returns contract results keyed by typed identifier, or answers with its own query; it loads no foreign aggregate or repository. A command changes only its own module aggregates, and an act on another module aggregate runs as that module use case, dispatched or triggered by an integration event. A reaction to another module fact subscribes to the published integration event and never to the domain event.

Checked bydotnet build reports LS2020 for a module reference naming another module type outside its Contracts folder.

Marked checkable: the tool named here checks it.

The dependsOn list states which modules a module may know, so an undeclared edge is a boundary the design never allowed. The rule covers code references and record links alike, and the graph stays acyclic.

Reviewed forWhich module references name a module outside their owner dependsOn, or close a dependency cycle? Look at the cross-module references beside the module records.

Marked guidance: a reviewer answers this question.

Protocol endpoints, static assets, and development-only tooling have no use case folder to sit beside, so the host keeps them. Each still carries its mark, and the placement check accepts a host endpoint in the host.

Reviewed forWhich host endpoints without a handler sit outside their host project, or lack their mark? Look at the host endpoints beside the use case folders.

Marked guidance: a reviewer answers this question.