Architecture

This solution is loosely based on Clean Architecture. It’s by no means perfect, so we prefer to call it Lean Mean Clean Architecture. The inspiration is Jason Taylor’s Clean Architecture template, with some ideas taken further and others scaled back.

Dependencies point inwards

Application sits in the middle and depends on nothing. Presentation and Infrastructure sit around the outside, and both depend on Application. The outside can change without the middle noticing.

1. Presentation exposes the Application layer as a GraphQL schema. Each query and mutation resolver sends a command or query through Mediator and returns the result, DataLoaders batch the reviews of a whole page, and one error filter turns Application errors into GraphQL errors with codes.
2. Application owns the domain and the business logic. Commands and queries are validated and handled here, and each domain type has its own repository interface. Application doesn’t care what fulfils those contracts, as long as something does.
3. Infrastructure owns the data. It implements the repository interfaces and maps its own data models onto the Application entities, so persistence details don’t leak upwards.

There’s a little CQRS in the style of the commands and queries, but reads and writes use the same database underneath. CQRS-curious, if you like.

The one rule we bend

In textbook Clean Architecture, Presentation never references Infrastructure. Here it does, so it can wire up dependency injection without a fourth project whose only job is to call two methods.

To keep that from turning into a free-for-all, every class in Infrastructure is internal. Presentation can call AddInfrastructure and nothing else. If you try to new up a repository from a resolver, the compiler will politely decline.

What happens on a query

1. Hot Chocolate parses and validates the document against the schema, checks the depth and page sizes, then calls each resolver the query selects.
2. It sends a command or query through Mediator, with the request’s cancellation token. Fields like MovieSummary.reviews go through a DataLoader first, which collects every id on the page and sends one batch query instead.
3. The ValidationBehaviour runs every FluentValidation validator for the request. Any failure stops here with a ValidationException.
4. The handler calls a repository interface.
5. The repository in Infrastructure runs the query against SQLite with Entity Framework Core and maps the results back to Application entities.
6. The resolver returns the entities, Hot Chocolate picks the fields the client asked for and serialises them, and the response goes out with any errors in the errors array.

Same middle, different outside

Application and Infrastructure are identical in all five Clean templates. Only Presentation changes. See the family.