Executive summary
andresantarosa/CleanArchitectureExample scores 34 out of 100, but it is rated At risk while a critical security finding is open; the score itself is unchanged.
The weakest lens counts most in the score, and here that is Security and Compliance, which scores 22 and is rated Critical. Its Data Protection dimension scores 0 out of 10, and until that reaches 4, Security and Compliance can't be rated higher than Adequate. The first actions are to resolve the 1 Vulnerable finding(s) in Dependency Hygiene and to resolve the 14 Outdated finding(s) in Dependency Hygiene, and if Security and Compliance rose to 70, the score would rise from 34 to about 42.
16 findings are critical: eight in Dependency Vulnerabilities, four in Aggregate boundaries, two in Domain ↔ infrastructure boundary, one in Dependency Hygiene and one in Explicit Debt.
Watchdog couldn't measure Code Coverage, Test Reliability and Runtime accessibility in this code, so those dimensions are left out of the score. The product code is 2,372 lines, which would take an estimated 0.1 person-years, around €4,300, to rebuild.
If Security and Compliance rose from 22 to 70, the lowest score rated Strong, the score would rise from 34 to about 42.
New since the last survey: 53 findings
- Explicit Debt · Dead code: FromString CleanArchitectureExample.Domain/Enums/BookSituationEnum.cs
- Explicit Debt · Dead code: FromValue CleanArchitectureExample.Domain/Enums/BookSituationEnum.cs
- Explicit Debt · Dead code: GetPreCommitEvents CleanArchitectureExample.Domain/Interfaces/Events/IEventDispatcher.cs
- Explicit Debt · Dead code: AddPreCommitEvent CleanArchitectureExample.Domain/Interfaces/Events/IEventDispatcher.cs
- Explicit Debt · Dead code: RemovePreCommitEvent CleanArchitectureExample.Domain/Interfaces/Events/IEventDispatcher.cs
- Explicit Debt · Dead code: GetAfterCommitEvents CleanArchitectureExample.Domain/Interfaces/Events/IEventDispatcher.cs
- Explicit Debt · Dead code: RemoveAfterCommitEvent CleanArchitectureExample.Domain/Interfaces/Events/IEventDispatcher.cs
- Explicit Debt · Dead code: GetAllAuthors CleanArchitectureExample.Domain/Interfaces/Persistence/Repositories/IAuthorRepository.cs
- Explicit Debt · Dead code: GetBookByISBN CleanArchitectureExample.Domain/Interfaces/Persistence/Repositories/IBookRepository.cs
- Explicit Debt · Dead code: GetAllBook CleanArchitectureExample.Domain/Interfaces/Persistence/Repositories/IBookRepository.cs
- Explicit Debt · Dead code: GetByTitle CleanArchitectureExample.Domain/Interfaces/Persistence/Repositories/IBookRepository.cs
- Explicit Debt · Dead code: CleanNotifications CleanArchitectureExample.Domain.Core/DomainNotification/IDomainNotifications.cs
- Explicit Debt · Dead code: IsLowerThan CleanArchitectureExample.Domain.Core/Validators/AssertionsConcern.cs
- Explicit Debt · Dead code: IsLowerThan CleanArchitectureExample.Domain.Core/Validators/AssertionsConcern.cs
- Explicit Debt · Dead code: IsLowerThan CleanArchitectureExample.Domain.Core/Validators/AssertionsConcern.cs
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Static Analysis (SAST) · REDACTED
- Access Controls · No authorization REDACTED
- Access Controls · No authorization REDACTED
- Access Controls · No authorization REDACTED
- Access Controls · No authorization REDACTED
- Access Controls · No authorization REDACTED
- Access Controls · No authorization REDACTED
- Access Controls · No authorization REDACTED
- Access Controls · No authorization REDACTED
- Cancellation propagation · Async method without CancellationToken: AddAuthor CleanArchitectureExample.Persistence/Repositories/AuthorRepository.cs
- Cancellation propagation · Async method without CancellationToken: GetAllAuthors CleanArchitectureExample.Persistence/Repositories/AuthorRepository.cs
- Cancellation propagation · Async method without CancellationToken: GetAuthorById CleanArchitectureExample.Persistence/Repositories/AuthorRepository.cs
- Cancellation propagation · Async method without CancellationToken: Add CleanArchitectureExample.Persistence/Repositories/BookLoanRepository.cs
- Cancellation propagation · Async method without CancellationToken: GetByLoanId CleanArchitectureExample.Persistence/Repositories/BookLoanRepository.cs
- Cancellation propagation · Async method without CancellationToken: AddBook CleanArchitectureExample.Persistence/Repositories/BookRepository.cs
- Cancellation propagation · Async method without CancellationToken: GetAllBook CleanArchitectureExample.Persistence/Repositories/BookRepository.cs
- Cancellation propagation · Async method without CancellationToken: GetBookByISBN CleanArchitectureExample.Persistence/Repositories/BookRepository.cs
- Cancellation propagation · Async method without CancellationToken: GetById CleanArchitectureExample.Persistence/Repositories/BookRepository.cs
- Cancellation propagation · Async method without CancellationToken: GetByTitle CleanArchitectureExample.Persistence/Repositories/BookRepository.cs
- Cancellation propagation · Async method without CancellationToken: AddPerson CleanArchitectureExample.Persistence/Repositories/PersonRepository.cs
- Cancellation propagation · Async method without CancellationToken: GetAll CleanArchitectureExample.Persistence/Repositories/PersonRepository.cs
- Cancellation propagation · Async method without CancellationToken: GetByDocument CleanArchitectureExample.Persistence/Repositories/PersonRepository.cs
- Cancellation propagation · Async method without CancellationToken: GetAll CleanArchitectureExample.Persistence/Repositories/ReadOnlyRepository/BookLoanReadOnlyRepository.cs
- Cancellation propagation · Async method without CancellationToken: Commit CleanArchitectureExample.Persistence/UnitOfWork/UnitOfWork.cs
- Cancellation propagation · Async method without CancellationToken: FireAfterCommitEvents CleanArchitectureExample.Application/Events/EventDispatcher.cs
- Cancellation propagation · Async method without CancellationToken: FirePreCommitEvents CleanArchitectureExample.Application/Events/EventDispatcher.cs
- Cancellation propagation · Async method without CancellationToken: SendCommand CleanArchitectureExample.Application/Orchestration/Orchestrator.cs
- Cancellation propagation · Async method without CancellationToken: SendQuery CleanArchitectureExample.Application/Orchestration/Orchestrator.cs
- Cancellation propagation · Async method without CancellationToken: SendEmail CleanArchitectureExample.Service/Communication/EmailServices.cs
- Cancellation propagation · Async method without CancellationToken: SendSms CleanArchitectureExample.Service/Communication/SmsServices.cs
- Domain ↔ infrastructure boundary · Domain depends on infrastructure: HttpContextServiceProviderProxy CleanArchitectureExample.Application/DomainNotifications/HttpContextServiceProviderProxy.cs
Fixed since the last survey: 2 findings
- Exception handling · Swallowed exception (caught, then discarded) CleanArchitectureExample.Domain/Enums/BookSituationEnum.cs
- Exception handling · Swallowed exception (caught, then discarded) CleanArchitectureExample.Persistence/UnitOfWork/UnitOfWork.cs
Rebuild cost: about €4,300 · Estimate
| Cost to rebuild | €1,500 to €7,200, for 24 to 75 hours of work, about 0.1 person-years for one engineer |
|---|---|
| Difficulty of the problem | Very high, judged from the kind of software and how it is built. Code that solves a harder problem, such as payments or medical bookings, costs more per line to write. |
| Quality factor | ×0.7 at a score of 34. Better code takes more work to write, so the factor is ×1.0 at a score of 70, lower below it and higher above it. |
| Size | Small: 2,372 lines of product code, of which 47% is declarations and boilerplate, 47% straight logic and 5% logic with branches |
Top priorities
Diagnosis: what the measurements show together
Architecture — module dependency graph
Architecture: which parts of the code depend on which
| uses → | 1 CrossCutting | 2 Domain.Base | 3 Domain.Core.DomainNotification | 4 Domain.Core.Validators | 5 Domain.Enums | 6 Domain.Interfaces.Events | 7 Domain.Interfaces.Persistence | 8 Domain.Interfaces.Persistence.UnitOfWork | 9 Domain.Interfaces.Requests | 10 Domain.Interfaces.Services.Communication | 11 WebAPI | 12 Application.DomainNotifications | 13 Application.Events | 14 Application.Orchestration | 15 Domain.Entities | 16 Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.Events | 17 Service.Communication | 18 Domain.Interfaces.Persistence.Repositories | 19 Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository | 20 Persistence.Context | 21 Persistence.EntityConfig | 22 Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor | 23 Domain.RequestHandlers.BookHandlers.Commands.AddBook | 24 Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan | 25 Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook | 26 Domain.RequestHandlers.BookLoanHandlers.Queries | 27 Domain.RequestHandlers.PersonHandlers.Commands.AddPerson | 28 Domain.RequestHandlers.PersonHandlers.Queries.GetAll | 29 Persistence.Repositories | 30 Persistence.Repositories.Base | 31 Persistence.UnitOfWork | 32 Persistence.Repositories.ReadOnlyRepository | 33 WebAPI.Controllers |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 CrossCutting | |||||||||||||||||||||||||||||||||
| 2 Domain.Base | |||||||||||||||||||||||||||||||||
| 3 Domain.Core.DomainNotification | |||||||||||||||||||||||||||||||||
| 4 Domain.Core.Validators | |||||||||||||||||||||||||||||||||
| 5 Domain.Enums | |||||||||||||||||||||||||||||||||
| 6 Domain.Interfaces.Events | |||||||||||||||||||||||||||||||||
| 7 Domain.Interfaces.Persistence | |||||||||||||||||||||||||||||||||
| 8 Domain.Interfaces.Persistence.UnitOfWork | |||||||||||||||||||||||||||||||||
| 9 Domain.Interfaces.Requests | |||||||||||||||||||||||||||||||||
| 10 Domain.Interfaces.Services.Communication | |||||||||||||||||||||||||||||||||
| 11 WebAPI | |||||||||||||||||||||||||||||||||
| 12 Application.DomainNotifications | 1 | ||||||||||||||||||||||||||||||||
| 13 Application.Events | 1 | ||||||||||||||||||||||||||||||||
| 14 Application.Orchestration | 1 | 1 | 1 | ||||||||||||||||||||||||||||||
| 15 Domain.Entities | 3 | 1 | |||||||||||||||||||||||||||||||
| 16 Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.Events | 2 | ||||||||||||||||||||||||||||||||
| 17 Service.Communication | 1 | 2 | |||||||||||||||||||||||||||||||
| 18 Domain.Interfaces.Persistence.Repositories | 4 | ||||||||||||||||||||||||||||||||
| 19 Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository | 1 | ||||||||||||||||||||||||||||||||
| 20 Persistence.Context | 10 | ||||||||||||||||||||||||||||||||
| 21 Persistence.EntityConfig | 5 | ||||||||||||||||||||||||||||||||
| 22 Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor | 1 | 1 | |||||||||||||||||||||||||||||||
| 23 Domain.RequestHandlers.BookHandlers.Commands.AddBook | 1 | 1 | 2 | ||||||||||||||||||||||||||||||
| 24 Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan | 1 | 1 | 2 | 3 | |||||||||||||||||||||||||||||
| 25 Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook | 1 | 1 | 1 | ||||||||||||||||||||||||||||||
| 26 Domain.RequestHandlers.BookLoanHandlers.Queries | 1 | 1 | |||||||||||||||||||||||||||||||
| 27 Domain.RequestHandlers.PersonHandlers.Commands.AddPerson | 1 | 1 | 1 | ||||||||||||||||||||||||||||||
| 28 Domain.RequestHandlers.PersonHandlers.Queries.GetAll | 1 | 1 | |||||||||||||||||||||||||||||||
| 29 Persistence.Repositories | 1 | 4 | 4 | 5 | |||||||||||||||||||||||||||||
| 30 Persistence.Repositories.Base | 1 | 1 | |||||||||||||||||||||||||||||||
| 31 Persistence.UnitOfWork | 1 | 1 | |||||||||||||||||||||||||||||||
| 32 Persistence.Repositories.ReadOnlyRepository | 1 | 1 | 1 | 1 | |||||||||||||||||||||||||||||
| 33 WebAPI.Controllers | 5 | 1 | 1 | 1 | 1 | 1 |
12→3 Application.DomainNotifications uses Domain.Core.DomainNotification✕
- Connections
- 1 pair of types, where a type in Application.DomainNotifications uses a type in Domain.Core.DomainNotification.
- The types involved
CleanArchitectureExample.Application.DomainNotifications.HttpContextServiceProviderProxy→CleanArchitectureExample.Domain.Core.DomainNotification.IContainer
- Direction
- Application.DomainNotifications uses Domain.Core.DomainNotification, so a change to Domain.Core.DomainNotification can break Application.DomainNotifications, while a change to Application.DomainNotifications can't break Domain.Core.DomainNotification.
- Position
- Below the diagonal: Application.DomainNotifications uses a module listed above it, which is the healthy direction.
13→6 Application.Events uses Domain.Interfaces.Events✕
- Connections
- 1 pair of types, where a type in Application.Events uses a type in Domain.Interfaces.Events.
- The types involved
CleanArchitectureExample.Application.Events.EventDispatcher→CleanArchitectureExample.Domain.Interfaces.Events.IEventDispatcher
- Direction
- Application.Events uses Domain.Interfaces.Events, so a change to Domain.Interfaces.Events can break Application.Events, while a change to Application.Events can't break Domain.Interfaces.Events.
- Position
- Below the diagonal: Application.Events uses a module listed above it, which is the healthy direction.
14→3 Application.Orchestration uses Domain.Core.DomainNotification✕
- Connections
- 1 pair of types, where a type in Application.Orchestration uses a type in Domain.Core.DomainNotification.
- The types involved
CleanArchitectureExample.Application.Orchestration.Orchestrator→CleanArchitectureExample.Domain.Core.DomainNotification.IDomainNotifications
- Direction
- Application.Orchestration uses Domain.Core.DomainNotification, so a change to Domain.Core.DomainNotification can break Application.Orchestration, while a change to Application.Orchestration can't break Domain.Core.DomainNotification.
- Position
- Below the diagonal: Application.Orchestration uses a module listed above it, which is the healthy direction.
14→6 Application.Orchestration uses Domain.Interfaces.Events✕
- Connections
- 1 pair of types, where a type in Application.Orchestration uses a type in Domain.Interfaces.Events.
- The types involved
CleanArchitectureExample.Application.Orchestration.Orchestrator→CleanArchitectureExample.Domain.Interfaces.Events.IEventDispatcher
- Direction
- Application.Orchestration uses Domain.Interfaces.Events, so a change to Domain.Interfaces.Events can break Application.Orchestration, while a change to Application.Orchestration can't break Domain.Interfaces.Events.
- Position
- Below the diagonal: Application.Orchestration uses a module listed above it, which is the healthy direction.
14→8 Application.Orchestration uses Domain.Interfaces.Persistence.UnitOfWork✕
- Connections
- 1 pair of types, where a type in Application.Orchestration uses a type in Domain.Interfaces.Persistence.UnitOfWork.
- The types involved
CleanArchitectureExample.Application.Orchestration.Orchestrator→CleanArchitectureExample.Domain.Interfaces.Persistence.UnitOfWork.IUnitOfWork
- Direction
- Application.Orchestration uses Domain.Interfaces.Persistence.UnitOfWork, so a change to Domain.Interfaces.Persistence.UnitOfWork can break Application.Orchestration, while a change to Application.Orchestration can't break Domain.Interfaces.Persistence.UnitOfWork.
- Position
- Below the diagonal: Application.Orchestration uses a module listed above it, which is the healthy direction.
15→2 Domain.Entities uses Domain.Base✕
- Connections
- 3 pairs of types, where a type in Domain.Entities uses a type in Domain.Base.
- The types involved
CleanArchitectureExample.Domain.Entities.Author→CleanArchitectureExample.Domain.Base.BaseEntityCleanArchitectureExample.Domain.Entities.Person→CleanArchitectureExample.Domain.Base.BaseEntityCleanArchitectureExample.Domain.Entities.PersonPhone→CleanArchitectureExample.Domain.Base.BaseEntity
- Direction
- Domain.Entities uses Domain.Base, so a change to Domain.Base can break Domain.Entities, while a change to Domain.Entities can't break Domain.Base.
- Position
- Below the diagonal: Domain.Entities uses a module listed above it, which is the healthy direction.
15→5 Domain.Entities uses Domain.Enums✕
- Connections
- 1 pair of types, where a type in Domain.Entities uses a type in Domain.Enums.
- The types involved
CleanArchitectureExample.Domain.Entities.Book→CleanArchitectureExample.Domain.Enums.BookSituationEnum
- Direction
- Domain.Entities uses Domain.Enums, so a change to Domain.Enums can break Domain.Entities, while a change to Domain.Entities can't break Domain.Enums.
- Position
- Below the diagonal: Domain.Entities uses a module listed above it, which is the healthy direction.
16→10 Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.Events uses Domain.Interfaces.Services.Communication✕
- Connections
- 2 pairs of types, where a type in Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.Events uses a type in Domain.Interfaces.Services.Communication.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.Events.LoanEffetivatedEventSendMail→CleanArchitectureExample.Domain.Interfaces.Services.Communication.IEmailServicesCleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.Events.LoanEffetivatedEventSendSms→CleanArchitectureExample.Domain.Interfaces.Services.Communication.ISmsServices
- Direction
- Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.Events uses Domain.Interfaces.Services.Communication, so a change to Domain.Interfaces.Services.Communication can break Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.Events, while a change to Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.Events can't break Domain.Interfaces.Services.Communication.
- Position
- Below the diagonal: Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.Events uses a module listed above it, which is the healthy direction.
17→6 Service.Communication uses Domain.Interfaces.Events✕
- Connections
- 1 pair of types, where a type in Service.Communication uses a type in Domain.Interfaces.Events.
- The types involved
CleanArchitectureExample.Service.Communication.SmsServices→CleanArchitectureExample.Domain.Interfaces.Events.IEventDispatcher
- Direction
- Service.Communication uses Domain.Interfaces.Events, so a change to Domain.Interfaces.Events can break Service.Communication, while a change to Service.Communication can't break Domain.Interfaces.Events.
- Position
- Below the diagonal: Service.Communication uses a module listed above it, which is the healthy direction.
17→10 Service.Communication uses Domain.Interfaces.Services.Communication✕
- Connections
- 2 pairs of types, where a type in Service.Communication uses a type in Domain.Interfaces.Services.Communication.
- The types involved
CleanArchitectureExample.Service.Communication.EmailServices→CleanArchitectureExample.Domain.Interfaces.Services.Communication.IEmailServicesCleanArchitectureExample.Service.Communication.SmsServices→CleanArchitectureExample.Domain.Interfaces.Services.Communication.ISmsServices
- Direction
- Service.Communication uses Domain.Interfaces.Services.Communication, so a change to Domain.Interfaces.Services.Communication can break Service.Communication, while a change to Service.Communication can't break Domain.Interfaces.Services.Communication.
- Position
- Below the diagonal: Service.Communication uses a module listed above it, which is the healthy direction.
18→15 Domain.Interfaces.Persistence.Repositories uses Domain.Entities✕
- Connections
- 4 pairs of types, where a type in Domain.Interfaces.Persistence.Repositories uses a type in Domain.Entities.
- The types involved
CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IAuthorRepository→CleanArchitectureExample.Domain.Entities.AuthorCleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IBookLoanRepository→CleanArchitectureExample.Domain.Entities.BookLoanCleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IBookRepository→CleanArchitectureExample.Domain.Entities.BookCleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IPersonRepository→CleanArchitectureExample.Domain.Entities.Person
- Direction
- Domain.Interfaces.Persistence.Repositories uses Domain.Entities, so a change to Domain.Entities can break Domain.Interfaces.Persistence.Repositories, while a change to Domain.Interfaces.Persistence.Repositories can't break Domain.Entities.
- Position
- Below the diagonal: Domain.Interfaces.Persistence.Repositories uses a module listed above it, which is the healthy direction.
19→15 Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository uses Domain.Entities✕
- Connections
- 1 pair of types, where a type in Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository uses a type in Domain.Entities.
- The types involved
CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository.IBookLoanReadOnlyRepository→CleanArchitectureExample.Domain.Entities.BookLoan
- Direction
- Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository uses Domain.Entities, so a change to Domain.Entities can break Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository, while a change to Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository can't break Domain.Entities.
- Position
- Below the diagonal: Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository uses a module listed above it, which is the healthy direction.
20→15 Persistence.Context uses Domain.Entities✕
- Connections
- 10 pairs of types, where a type in Persistence.Context uses a type in Domain.Entities.
- The types involved
CleanArchitectureExample.Persistence.Context.ApplicationDbContext→CleanArchitectureExample.Domain.Entities.AuthorCleanArchitectureExample.Persistence.Context.ApplicationDbContext→CleanArchitectureExample.Domain.Entities.BookCleanArchitectureExample.Persistence.Context.ApplicationDbContext→CleanArchitectureExample.Domain.Entities.BookLoanCleanArchitectureExample.Persistence.Context.ApplicationDbContext→CleanArchitectureExample.Domain.Entities.PersonCleanArchitectureExample.Persistence.Context.ApplicationDbContext→CleanArchitectureExample.Domain.Entities.PersonPhoneCleanArchitectureExample.Persistence.Context.ApplicationDbContextReadOnly→CleanArchitectureExample.Domain.Entities.AuthorCleanArchitectureExample.Persistence.Context.ApplicationDbContextReadOnly→CleanArchitectureExample.Domain.Entities.BookCleanArchitectureExample.Persistence.Context.ApplicationDbContextReadOnly→CleanArchitectureExample.Domain.Entities.BookLoanCleanArchitectureExample.Persistence.Context.ApplicationDbContextReadOnly→CleanArchitectureExample.Domain.Entities.PersonCleanArchitectureExample.Persistence.Context.ApplicationDbContextReadOnly→CleanArchitectureExample.Domain.Entities.PersonPhone
- Direction
- Persistence.Context uses Domain.Entities, so a change to Domain.Entities can break Persistence.Context, while a change to Persistence.Context can't break Domain.Entities.
- Position
- Below the diagonal: Persistence.Context uses a module listed above it, which is the healthy direction.
21→15 Persistence.EntityConfig uses Domain.Entities✕
- Connections
- 5 pairs of types, where a type in Persistence.EntityConfig uses a type in Domain.Entities.
- The types involved
CleanArchitectureExample.Persistence.EntityConfig.AuthorConfig→CleanArchitectureExample.Domain.Entities.AuthorCleanArchitectureExample.Persistence.EntityConfig.BookConfig→CleanArchitectureExample.Domain.Entities.BookCleanArchitectureExample.Persistence.EntityConfig.BookLoanConfig→CleanArchitectureExample.Domain.Entities.BookLoanCleanArchitectureExample.Persistence.EntityConfig.PersonConfig→CleanArchitectureExample.Domain.Entities.PersonCleanArchitectureExample.Persistence.EntityConfig.PersonPhoneConfig→CleanArchitectureExample.Domain.Entities.PersonPhone
- Direction
- Persistence.EntityConfig uses Domain.Entities, so a change to Domain.Entities can break Persistence.EntityConfig, while a change to Persistence.EntityConfig can't break Domain.Entities.
- Position
- Below the diagonal: Persistence.EntityConfig uses a module listed above it, which is the healthy direction.
22→9 Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor uses Domain.Interfaces.Requests✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor uses a type in Domain.Interfaces.Requests.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor.AddAuthorCommandResponseViewModel→CleanArchitectureExample.Domain.Interfaces.Requests.IRequestResponse
- Direction
- Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor uses Domain.Interfaces.Requests, so a change to Domain.Interfaces.Requests can break Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor, while a change to Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor can't break Domain.Interfaces.Requests.
- Position
- Below the diagonal: Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor uses a module listed above it, which is the healthy direction.
22→18 Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor uses Domain.Interfaces.Persistence.Repositories✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor uses a type in Domain.Interfaces.Persistence.Repositories.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor.AddAuthorCommandHandler→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IAuthorRepository
- Direction
- Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor uses Domain.Interfaces.Persistence.Repositories, so a change to Domain.Interfaces.Persistence.Repositories can break Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor, while a change to Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor can't break Domain.Interfaces.Persistence.Repositories.
- Position
- Below the diagonal: Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor uses a module listed above it, which is the healthy direction.
23→9 Domain.RequestHandlers.BookHandlers.Commands.AddBook uses Domain.Interfaces.Requests✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.BookHandlers.Commands.AddBook uses a type in Domain.Interfaces.Requests.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookHandlers.Commands.AddBook.AddBookCommandResponseViewModel→CleanArchitectureExample.Domain.Interfaces.Requests.IRequestResponse
- Direction
- Domain.RequestHandlers.BookHandlers.Commands.AddBook uses Domain.Interfaces.Requests, so a change to Domain.Interfaces.Requests can break Domain.RequestHandlers.BookHandlers.Commands.AddBook, while a change to Domain.RequestHandlers.BookHandlers.Commands.AddBook can't break Domain.Interfaces.Requests.
- Position
- Below the diagonal: Domain.RequestHandlers.BookHandlers.Commands.AddBook uses a module listed above it, which is the healthy direction.
23→15 Domain.RequestHandlers.BookHandlers.Commands.AddBook uses Domain.Entities✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.BookHandlers.Commands.AddBook uses a type in Domain.Entities.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookHandlers.Commands.AddBook.AddBookCommandValidators→CleanArchitectureExample.Domain.Entities.Author
- Direction
- Domain.RequestHandlers.BookHandlers.Commands.AddBook uses Domain.Entities, so a change to Domain.Entities can break Domain.RequestHandlers.BookHandlers.Commands.AddBook, while a change to Domain.RequestHandlers.BookHandlers.Commands.AddBook can't break Domain.Entities.
- Position
- Below the diagonal: Domain.RequestHandlers.BookHandlers.Commands.AddBook uses a module listed above it, which is the healthy direction.
23→18 Domain.RequestHandlers.BookHandlers.Commands.AddBook uses Domain.Interfaces.Persistence.Repositories✕
- Connections
- 2 pairs of types, where a type in Domain.RequestHandlers.BookHandlers.Commands.AddBook uses a type in Domain.Interfaces.Persistence.Repositories.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookHandlers.Commands.AddBook.AddBookCommandHandler→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IAuthorRepositoryCleanArchitectureExample.Domain.RequestHandlers.BookHandlers.Commands.AddBook.AddBookCommandHandler→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IBookRepository
- Direction
- Domain.RequestHandlers.BookHandlers.Commands.AddBook uses Domain.Interfaces.Persistence.Repositories, so a change to Domain.Interfaces.Persistence.Repositories can break Domain.RequestHandlers.BookHandlers.Commands.AddBook, while a change to Domain.RequestHandlers.BookHandlers.Commands.AddBook can't break Domain.Interfaces.Persistence.Repositories.
- Position
- Below the diagonal: Domain.RequestHandlers.BookHandlers.Commands.AddBook uses a module listed above it, which is the healthy direction.
24→6 Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses Domain.Interfaces.Events✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses a type in Domain.Interfaces.Events.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.RequestLoanCommandHandler→CleanArchitectureExample.Domain.Interfaces.Events.IEventDispatcher
- Direction
- Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses Domain.Interfaces.Events, so a change to Domain.Interfaces.Events can break Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan, while a change to Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan can't break Domain.Interfaces.Events.
- Position
- Below the diagonal: Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses a module listed above it, which is the healthy direction.
24→9 Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses Domain.Interfaces.Requests✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses a type in Domain.Interfaces.Requests.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.RequestLoanCommandResponseViewModel→CleanArchitectureExample.Domain.Interfaces.Requests.IRequestResponse
- Direction
- Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses Domain.Interfaces.Requests, so a change to Domain.Interfaces.Requests can break Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan, while a change to Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan can't break Domain.Interfaces.Requests.
- Position
- Below the diagonal: Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses a module listed above it, which is the healthy direction.
24→15 Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses Domain.Entities✕
- Connections
- 2 pairs of types, where a type in Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses a type in Domain.Entities.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.RequestLoanCommandValidator→CleanArchitectureExample.Domain.Entities.BookCleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.RequestLoanCommandValidator→CleanArchitectureExample.Domain.Entities.Person
- Direction
- Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses Domain.Entities, so a change to Domain.Entities can break Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan, while a change to Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan can't break Domain.Entities.
- Position
- Below the diagonal: Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses a module listed above it, which is the healthy direction.
24→18 Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses Domain.Interfaces.Persistence.Repositories✕
- Connections
- 3 pairs of types, where a type in Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses a type in Domain.Interfaces.Persistence.Repositories.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.RequestLoanCommandHandler→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IBookLoanRepositoryCleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.RequestLoanCommandHandler→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IBookRepositoryCleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.RequestLoanCommandHandler→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IPersonRepository
- Direction
- Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses Domain.Interfaces.Persistence.Repositories, so a change to Domain.Interfaces.Persistence.Repositories can break Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan, while a change to Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan can't break Domain.Interfaces.Persistence.Repositories.
- Position
- Below the diagonal: Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan uses a module listed above it, which is the healthy direction.
25→9 Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses Domain.Interfaces.Requests✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses a type in Domain.Interfaces.Requests.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook.ReturnBookCommandResponseViewModel→CleanArchitectureExample.Domain.Interfaces.Requests.IRequestResponse
- Direction
- Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses Domain.Interfaces.Requests, so a change to Domain.Interfaces.Requests can break Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook, while a change to Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook can't break Domain.Interfaces.Requests.
- Position
- Below the diagonal: Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses a module listed above it, which is the healthy direction.
25→15 Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses Domain.Entities✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses a type in Domain.Entities.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook.ReturnBookCommandValidator→CleanArchitectureExample.Domain.Entities.BookLoan
- Direction
- Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses Domain.Entities, so a change to Domain.Entities can break Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook, while a change to Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook can't break Domain.Entities.
- Position
- Below the diagonal: Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses a module listed above it, which is the healthy direction.
25→18 Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses Domain.Interfaces.Persistence.Repositories✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses a type in Domain.Interfaces.Persistence.Repositories.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook.ReturnBookCommandHandler→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IBookLoanRepository
- Direction
- Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses Domain.Interfaces.Persistence.Repositories, so a change to Domain.Interfaces.Persistence.Repositories can break Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook, while a change to Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook can't break Domain.Interfaces.Persistence.Repositories.
- Position
- Below the diagonal: Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook uses a module listed above it, which is the healthy direction.
26→9 Domain.RequestHandlers.BookLoanHandlers.Queries uses Domain.Interfaces.Requests✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.BookLoanHandlers.Queries uses a type in Domain.Interfaces.Requests.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Queries.BookLoanGetAllQueryResponseViewModel→CleanArchitectureExample.Domain.Interfaces.Requests.IRequestResponse
- Direction
- Domain.RequestHandlers.BookLoanHandlers.Queries uses Domain.Interfaces.Requests, so a change to Domain.Interfaces.Requests can break Domain.RequestHandlers.BookLoanHandlers.Queries, while a change to Domain.RequestHandlers.BookLoanHandlers.Queries can't break Domain.Interfaces.Requests.
- Position
- Below the diagonal: Domain.RequestHandlers.BookLoanHandlers.Queries uses a module listed above it, which is the healthy direction.
26→19 Domain.RequestHandlers.BookLoanHandlers.Queries uses Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.BookLoanHandlers.Queries uses a type in Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Queries.BookLoanGetAllQueryHandler→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository.IBookLoanReadOnlyRepository
- Direction
- Domain.RequestHandlers.BookLoanHandlers.Queries uses Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository, so a change to Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository can break Domain.RequestHandlers.BookLoanHandlers.Queries, while a change to Domain.RequestHandlers.BookLoanHandlers.Queries can't break Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository.
- Position
- Below the diagonal: Domain.RequestHandlers.BookLoanHandlers.Queries uses a module listed above it, which is the healthy direction.
27→9 Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses Domain.Interfaces.Requests✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses a type in Domain.Interfaces.Requests.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.PersonHandlers.Commands.AddPerson.AddPersonCommandResponseViewModel→CleanArchitectureExample.Domain.Interfaces.Requests.IRequestResponse
- Direction
- Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses Domain.Interfaces.Requests, so a change to Domain.Interfaces.Requests can break Domain.RequestHandlers.PersonHandlers.Commands.AddPerson, while a change to Domain.RequestHandlers.PersonHandlers.Commands.AddPerson can't break Domain.Interfaces.Requests.
- Position
- Below the diagonal: Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses a module listed above it, which is the healthy direction.
27→15 Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses Domain.Entities✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses a type in Domain.Entities.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.PersonHandlers.Commands.AddPerson.AddPersonCommandValidator→CleanArchitectureExample.Domain.Entities.Person
- Direction
- Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses Domain.Entities, so a change to Domain.Entities can break Domain.RequestHandlers.PersonHandlers.Commands.AddPerson, while a change to Domain.RequestHandlers.PersonHandlers.Commands.AddPerson can't break Domain.Entities.
- Position
- Below the diagonal: Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses a module listed above it, which is the healthy direction.
27→18 Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses Domain.Interfaces.Persistence.Repositories✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses a type in Domain.Interfaces.Persistence.Repositories.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.PersonHandlers.Commands.AddPerson.AddPersonCommandHandler→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IPersonRepository
- Direction
- Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses Domain.Interfaces.Persistence.Repositories, so a change to Domain.Interfaces.Persistence.Repositories can break Domain.RequestHandlers.PersonHandlers.Commands.AddPerson, while a change to Domain.RequestHandlers.PersonHandlers.Commands.AddPerson can't break Domain.Interfaces.Persistence.Repositories.
- Position
- Below the diagonal: Domain.RequestHandlers.PersonHandlers.Commands.AddPerson uses a module listed above it, which is the healthy direction.
28→9 Domain.RequestHandlers.PersonHandlers.Queries.GetAll uses Domain.Interfaces.Requests✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.PersonHandlers.Queries.GetAll uses a type in Domain.Interfaces.Requests.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.PersonHandlers.Queries.GetAll.GetAllPeopleQueryViewModel→CleanArchitectureExample.Domain.Interfaces.Requests.IRequestResponse
- Direction
- Domain.RequestHandlers.PersonHandlers.Queries.GetAll uses Domain.Interfaces.Requests, so a change to Domain.Interfaces.Requests can break Domain.RequestHandlers.PersonHandlers.Queries.GetAll, while a change to Domain.RequestHandlers.PersonHandlers.Queries.GetAll can't break Domain.Interfaces.Requests.
- Position
- Below the diagonal: Domain.RequestHandlers.PersonHandlers.Queries.GetAll uses a module listed above it, which is the healthy direction.
28→18 Domain.RequestHandlers.PersonHandlers.Queries.GetAll uses Domain.Interfaces.Persistence.Repositories✕
- Connections
- 1 pair of types, where a type in Domain.RequestHandlers.PersonHandlers.Queries.GetAll uses a type in Domain.Interfaces.Persistence.Repositories.
- The types involved
CleanArchitectureExample.Domain.RequestHandlers.PersonHandlers.Queries.GetAll.GetAllPeopleQueryHandler→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IPersonRepository
- Direction
- Domain.RequestHandlers.PersonHandlers.Queries.GetAll uses Domain.Interfaces.Persistence.Repositories, so a change to Domain.Interfaces.Persistence.Repositories can break Domain.RequestHandlers.PersonHandlers.Queries.GetAll, while a change to Domain.RequestHandlers.PersonHandlers.Queries.GetAll can't break Domain.Interfaces.Persistence.Repositories.
- Position
- Below the diagonal: Domain.RequestHandlers.PersonHandlers.Queries.GetAll uses a module listed above it, which is the healthy direction.
29→7 Persistence.Repositories uses Domain.Interfaces.Persistence✕
- Connections
- 1 pair of types, where a type in Persistence.Repositories uses a type in Domain.Interfaces.Persistence.
- The types involved
CleanArchitectureExample.Persistence.Repositories.BaseRepository→CleanArchitectureExample.Domain.Interfaces.Persistence.IRepository
- Direction
- Persistence.Repositories uses Domain.Interfaces.Persistence, so a change to Domain.Interfaces.Persistence can break Persistence.Repositories, while a change to Persistence.Repositories can't break Domain.Interfaces.Persistence.
- Position
- Below the diagonal: Persistence.Repositories uses a module listed above it, which is the healthy direction.
29→15 Persistence.Repositories uses Domain.Entities✕
- Connections
- 4 pairs of types, where a type in Persistence.Repositories uses a type in Domain.Entities.
- The types involved
CleanArchitectureExample.Persistence.Repositories.AuthorRepository→CleanArchitectureExample.Domain.Entities.AuthorCleanArchitectureExample.Persistence.Repositories.BookLoanRepository→CleanArchitectureExample.Domain.Entities.BookLoanCleanArchitectureExample.Persistence.Repositories.BookRepository→CleanArchitectureExample.Domain.Entities.BookCleanArchitectureExample.Persistence.Repositories.PersonRepository→CleanArchitectureExample.Domain.Entities.Person
- Direction
- Persistence.Repositories uses Domain.Entities, so a change to Domain.Entities can break Persistence.Repositories, while a change to Persistence.Repositories can't break Domain.Entities.
- Position
- Below the diagonal: Persistence.Repositories uses a module listed above it, which is the healthy direction.
29→18 Persistence.Repositories uses Domain.Interfaces.Persistence.Repositories✕
- Connections
- 4 pairs of types, where a type in Persistence.Repositories uses a type in Domain.Interfaces.Persistence.Repositories.
- The types involved
CleanArchitectureExample.Persistence.Repositories.AuthorRepository→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IAuthorRepositoryCleanArchitectureExample.Persistence.Repositories.BookLoanRepository→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IBookLoanRepositoryCleanArchitectureExample.Persistence.Repositories.BookRepository→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IBookRepositoryCleanArchitectureExample.Persistence.Repositories.PersonRepository→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.IPersonRepository
- Direction
- Persistence.Repositories uses Domain.Interfaces.Persistence.Repositories, so a change to Domain.Interfaces.Persistence.Repositories can break Persistence.Repositories, while a change to Persistence.Repositories can't break Domain.Interfaces.Persistence.Repositories.
- Position
- Below the diagonal: Persistence.Repositories uses a module listed above it, which is the healthy direction.
29→20 Persistence.Repositories uses Persistence.Context✕
- Connections
- 5 pairs of types, where a type in Persistence.Repositories uses a type in Persistence.Context.
- The types involved
CleanArchitectureExample.Persistence.Repositories.AuthorRepository→CleanArchitectureExample.Persistence.Context.ApplicationDbContextCleanArchitectureExample.Persistence.Repositories.BaseRepository→CleanArchitectureExample.Persistence.Context.ApplicationDbContextCleanArchitectureExample.Persistence.Repositories.BookLoanRepository→CleanArchitectureExample.Persistence.Context.ApplicationDbContextCleanArchitectureExample.Persistence.Repositories.BookRepository→CleanArchitectureExample.Persistence.Context.ApplicationDbContextCleanArchitectureExample.Persistence.Repositories.PersonRepository→CleanArchitectureExample.Persistence.Context.ApplicationDbContext
- Direction
- Persistence.Repositories uses Persistence.Context, so a change to Persistence.Context can break Persistence.Repositories, while a change to Persistence.Repositories can't break Persistence.Context.
- Position
- Below the diagonal: Persistence.Repositories uses a module listed above it, which is the healthy direction.
30→7 Persistence.Repositories.Base uses Domain.Interfaces.Persistence✕
- Connections
- 1 pair of types, where a type in Persistence.Repositories.Base uses a type in Domain.Interfaces.Persistence.
- The types involved
CleanArchitectureExample.Persistence.Repositories.Base.BaseRepositoryReadOnly→CleanArchitectureExample.Domain.Interfaces.Persistence.IRepository
- Direction
- Persistence.Repositories.Base uses Domain.Interfaces.Persistence, so a change to Domain.Interfaces.Persistence can break Persistence.Repositories.Base, while a change to Persistence.Repositories.Base can't break Domain.Interfaces.Persistence.
- Position
- Below the diagonal: Persistence.Repositories.Base uses a module listed above it, which is the healthy direction.
30→20 Persistence.Repositories.Base uses Persistence.Context✕
- Connections
- 1 pair of types, where a type in Persistence.Repositories.Base uses a type in Persistence.Context.
- The types involved
CleanArchitectureExample.Persistence.Repositories.Base.BaseRepositoryReadOnly→CleanArchitectureExample.Persistence.Context.ApplicationDbContextReadOnly
- Direction
- Persistence.Repositories.Base uses Persistence.Context, so a change to Persistence.Context can break Persistence.Repositories.Base, while a change to Persistence.Repositories.Base can't break Persistence.Context.
- Position
- Below the diagonal: Persistence.Repositories.Base uses a module listed above it, which is the healthy direction.
31→8 Persistence.UnitOfWork uses Domain.Interfaces.Persistence.UnitOfWork✕
- Connections
- 1 pair of types, where a type in Persistence.UnitOfWork uses a type in Domain.Interfaces.Persistence.UnitOfWork.
- The types involved
CleanArchitectureExample.Persistence.UnitOfWork.UnitOfWork→CleanArchitectureExample.Domain.Interfaces.Persistence.UnitOfWork.IUnitOfWork
- Direction
- Persistence.UnitOfWork uses Domain.Interfaces.Persistence.UnitOfWork, so a change to Domain.Interfaces.Persistence.UnitOfWork can break Persistence.UnitOfWork, while a change to Persistence.UnitOfWork can't break Domain.Interfaces.Persistence.UnitOfWork.
- Position
- Below the diagonal: Persistence.UnitOfWork uses a module listed above it, which is the healthy direction.
31→20 Persistence.UnitOfWork uses Persistence.Context✕
- Connections
- 1 pair of types, where a type in Persistence.UnitOfWork uses a type in Persistence.Context.
- The types involved
CleanArchitectureExample.Persistence.UnitOfWork.UnitOfWork→CleanArchitectureExample.Persistence.Context.ApplicationDbContext
- Direction
- Persistence.UnitOfWork uses Persistence.Context, so a change to Persistence.Context can break Persistence.UnitOfWork, while a change to Persistence.UnitOfWork can't break Persistence.Context.
- Position
- Below the diagonal: Persistence.UnitOfWork uses a module listed above it, which is the healthy direction.
32→15 Persistence.Repositories.ReadOnlyRepository uses Domain.Entities✕
- Connections
- 1 pair of types, where a type in Persistence.Repositories.ReadOnlyRepository uses a type in Domain.Entities.
- The types involved
CleanArchitectureExample.Persistence.Repositories.ReadOnlyRepository.BookLoanReadOnlyRepository→CleanArchitectureExample.Domain.Entities.BookLoan
- Direction
- Persistence.Repositories.ReadOnlyRepository uses Domain.Entities, so a change to Domain.Entities can break Persistence.Repositories.ReadOnlyRepository, while a change to Persistence.Repositories.ReadOnlyRepository can't break Domain.Entities.
- Position
- Below the diagonal: Persistence.Repositories.ReadOnlyRepository uses a module listed above it, which is the healthy direction.
32→19 Persistence.Repositories.ReadOnlyRepository uses Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository✕
- Connections
- 1 pair of types, where a type in Persistence.Repositories.ReadOnlyRepository uses a type in Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository.
- The types involved
CleanArchitectureExample.Persistence.Repositories.ReadOnlyRepository.BookLoanReadOnlyRepository→CleanArchitectureExample.Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository.IBookLoanReadOnlyRepository
- Direction
- Persistence.Repositories.ReadOnlyRepository uses Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository, so a change to Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository can break Persistence.Repositories.ReadOnlyRepository, while a change to Persistence.Repositories.ReadOnlyRepository can't break Domain.Interfaces.Persistence.Repositories.ReadOnlyRepository.
- Position
- Below the diagonal: Persistence.Repositories.ReadOnlyRepository uses a module listed above it, which is the healthy direction.
32→20 Persistence.Repositories.ReadOnlyRepository uses Persistence.Context✕
- Connections
- 1 pair of types, where a type in Persistence.Repositories.ReadOnlyRepository uses a type in Persistence.Context.
- The types involved
CleanArchitectureExample.Persistence.Repositories.ReadOnlyRepository.BookLoanReadOnlyRepository→CleanArchitectureExample.Persistence.Context.ApplicationDbContextReadOnly
- Direction
- Persistence.Repositories.ReadOnlyRepository uses Persistence.Context, so a change to Persistence.Context can break Persistence.Repositories.ReadOnlyRepository, while a change to Persistence.Repositories.ReadOnlyRepository can't break Persistence.Context.
- Position
- Below the diagonal: Persistence.Repositories.ReadOnlyRepository uses a module listed above it, which is the healthy direction.
32→30 Persistence.Repositories.ReadOnlyRepository uses Persistence.Repositories.Base✕
- Connections
- 1 pair of types, where a type in Persistence.Repositories.ReadOnlyRepository uses a type in Persistence.Repositories.Base.
- The types involved
CleanArchitectureExample.Persistence.Repositories.ReadOnlyRepository.BookLoanReadOnlyRepository→CleanArchitectureExample.Persistence.Repositories.Base.BaseRepositoryReadOnly
- Direction
- Persistence.Repositories.ReadOnlyRepository uses Persistence.Repositories.Base, so a change to Persistence.Repositories.Base can break Persistence.Repositories.ReadOnlyRepository, while a change to Persistence.Repositories.ReadOnlyRepository can't break Persistence.Repositories.Base.
- Position
- Below the diagonal: Persistence.Repositories.ReadOnlyRepository uses a module listed above it, which is the healthy direction.
33→14 WebAPI.Controllers uses Application.Orchestration✕
- Connections
- 5 pairs of types, where a type in WebAPI.Controllers uses a type in Application.Orchestration.
- The types involved
CleanArchitectureExample.WebAPI.Controllers.AuthorController→CleanArchitectureExample.Application.Orchestration.IOrchestratorCleanArchitectureExample.WebAPI.Controllers.BaseController→CleanArchitectureExample.Application.Orchestration.RequestResultCleanArchitectureExample.WebAPI.Controllers.BookController→CleanArchitectureExample.Application.Orchestration.IOrchestratorCleanArchitectureExample.WebAPI.Controllers.BookLoanController→CleanArchitectureExample.Application.Orchestration.IOrchestratorCleanArchitectureExample.WebAPI.Controllers.PersonController→CleanArchitectureExample.Application.Orchestration.IOrchestrator
- Direction
- WebAPI.Controllers uses Application.Orchestration, so a change to Application.Orchestration can break WebAPI.Controllers, while a change to WebAPI.Controllers can't break Application.Orchestration.
- Position
- Below the diagonal: WebAPI.Controllers uses a module listed above it, which is the healthy direction.
33→22 WebAPI.Controllers uses Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor✕
- Connections
- 1 pair of types, where a type in WebAPI.Controllers uses a type in Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor.
- The types involved
CleanArchitectureExample.WebAPI.Controllers.AuthorController→CleanArchitectureExample.Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor.AddAuthorCommand
- Direction
- WebAPI.Controllers uses Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor, so a change to Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor can break WebAPI.Controllers, while a change to WebAPI.Controllers can't break Domain.RequestHandlers.AuthorsHandlers.Commands.AddAuthor.
- Position
- Below the diagonal: WebAPI.Controllers uses a module listed above it, which is the healthy direction.
33→23 WebAPI.Controllers uses Domain.RequestHandlers.BookHandlers.Commands.AddBook✕
- Connections
- 1 pair of types, where a type in WebAPI.Controllers uses a type in Domain.RequestHandlers.BookHandlers.Commands.AddBook.
- The types involved
CleanArchitectureExample.WebAPI.Controllers.BookController→CleanArchitectureExample.Domain.RequestHandlers.BookHandlers.Commands.AddBook.AddBookCommand
- Direction
- WebAPI.Controllers uses Domain.RequestHandlers.BookHandlers.Commands.AddBook, so a change to Domain.RequestHandlers.BookHandlers.Commands.AddBook can break WebAPI.Controllers, while a change to WebAPI.Controllers can't break Domain.RequestHandlers.BookHandlers.Commands.AddBook.
- Position
- Below the diagonal: WebAPI.Controllers uses a module listed above it, which is the healthy direction.
33→24 WebAPI.Controllers uses Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan✕
- Connections
- 1 pair of types, where a type in WebAPI.Controllers uses a type in Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.
- The types involved
CleanArchitectureExample.WebAPI.Controllers.BookLoanController→CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.RequestLoanCommand
- Direction
- WebAPI.Controllers uses Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan, so a change to Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan can break WebAPI.Controllers, while a change to WebAPI.Controllers can't break Domain.RequestHandlers.BookLoanHandlers.Commands.RequestLoan.
- Position
- Below the diagonal: WebAPI.Controllers uses a module listed above it, which is the healthy direction.
33→25 WebAPI.Controllers uses Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook✕
- Connections
- 1 pair of types, where a type in WebAPI.Controllers uses a type in Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook.
- The types involved
CleanArchitectureExample.WebAPI.Controllers.BookLoanController→CleanArchitectureExample.Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook.ReturnBookCommand
- Direction
- WebAPI.Controllers uses Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook, so a change to Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook can break WebAPI.Controllers, while a change to WebAPI.Controllers can't break Domain.RequestHandlers.BookLoanHandlers.Commands.ReturnBook.
- Position
- Below the diagonal: WebAPI.Controllers uses a module listed above it, which is the healthy direction.
33→27 WebAPI.Controllers uses Domain.RequestHandlers.PersonHandlers.Commands.AddPerson✕
- Connections
- 1 pair of types, where a type in WebAPI.Controllers uses a type in Domain.RequestHandlers.PersonHandlers.Commands.AddPerson.
- The types involved
CleanArchitectureExample.WebAPI.Controllers.PersonController→CleanArchitectureExample.Domain.RequestHandlers.PersonHandlers.Commands.AddPerson.AddPersonCommand
- Direction
- WebAPI.Controllers uses Domain.RequestHandlers.PersonHandlers.Commands.AddPerson, so a change to Domain.RequestHandlers.PersonHandlers.Commands.AddPerson can break WebAPI.Controllers, while a change to WebAPI.Controllers can't break Domain.RequestHandlers.PersonHandlers.Commands.AddPerson.
- Position
- Below the diagonal: WebAPI.Controllers uses a module listed above it, which is the healthy direction.
At a glance — Code Health
At a glance — Architecture
At a glance — Maturity
At a glance — Readiness
At a glance — Security
At a glance — Domain Modelling
At a glance — Event-Driven
At a glance — Performance
Security & Compliance — OWASP Top-10 mapping
| OWASP category | Findings | Severity |
|---|---|---|
| A03:2025 — Software Supply Chain Failures | 10 | High / Critical |
| A05:2025 — Injection | 8 | Medium |
Roadmap
Begin by addressing the most critical security gaps by encrypting sensitive data at rest and implementing strict default-deny access controls on all endpoints. Next, resolve the single vulnerable dependency to eliminate immediate risk, followed by updating the ten deprecated packages to ensure long-term stability. Finally, clear the remaining outdated dependencies across the persistence, test, and web API projects to maintain overall system hygiene.
| Do this | Helps | Effort | Dimension |
|---|---|---|---|
| Resolve the 1 Vulnerable finding(s) in Dependency Hygiene. | +5.0 pts | Low | Dependency Hygiene |
| Resolve the 14 Outdated finding(s) in Dependency Hygiene — start with REDACTED (4), REDACTED (4), REDACTED (3). | +7.0 pts | Medium | Dependency Hygiene |
| Encrypt sensitive data at rest (ASP.NET Core Data Protection / column encryption) and manage keys in a vault. Skip if delegated to infra (Postgres TDE, KMS, etc.). | +6.3 pts | Medium | Data Protection |
| Protect endpoints by default-deny: [Authorize] + role/policy authorization, or imperative guard methods (throw-on-violation) called from every handler. | +6.3 pts | Medium | Access Controls |
| Resolve the 10 Deprecated finding(s) in Dependency Hygiene — start with REDACTED (4), REDACTED (3), REDACTED (2). | +6.2 pts | Medium | Dependency Hygiene |
| Resolve the 1 End-of-life runtime finding(s) in Platform End-of-Life — start with REDACTED. | +3.1 pts | Low | Platform End-of-Life |
| Resolve the 6 High CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (3), REDACTED, REDACTED. | +3.0 pts | Low | Dependency Vulnerabilities |
| Resolve the 8 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED (3), REDACTED (2), REDACTED. | +2.7 pts | Low | Static Analysis (SAST) |
File quality
| File | Score | Band | Worst signal |
|---|---|---|---|
| REDACTED | 0.0 | Slop | Dependency Vulnerabilities: Critical CVE: REDACTED |
| REDACTED | 2.0 | Slop | Dependency Vulnerabilities: High CVE: REDACTED |
| REDACTED | 3.6 | Slop | Dependency Vulnerabilities: High CVE: REDACTED |
| REDACTED | 3.8 | Slop | Dependency Vulnerabilities: Critical CVE: REDACTED |
| REDACTED | 6.3 | Mixed | Static Analysis (SAST): Medium: REDACTED |
| CleanArchitectureExample.Domain/Interfaces/Events/IEventDispatcher.cs | 6.5 | Mixed | Explicit Debt: Dead code: GetPreCommitEvents |
| CleanArchitectureExample.Domain/Interfaces/Persistence/Repositories/IBookRepository.cs | 6.9 | Mixed | Explicit Debt: Dead code: GetBookByISBN |
| CleanArchitectureExample.Domain.Core/Validators/AssertionsConcern.cs | 6.9 | Mixed | Explicit Debt: Dead code: IsLowerThan |
| REDACTED | 6.9 | Mixed | Static Analysis (SAST): Medium: REDACTED |
| CleanArchitectureExample.Domain/Enums/BookSituationEnum.cs | 7.3 | Mixed | Explicit Debt: Dead code: FromString |
| CleanArchitectureExample.Service/Communication/SmsServices.cs | 7.6 | Mixed | Explicit Debt: WriteOnlyPrivateField |
| REDACTED | 7.9 | Mixed | Static Analysis (SAST): Medium: REDACTED |
| REDACTED | 7.9 | Mixed | Static Analysis (SAST): Medium: REDACTED |
| REDACTED | 7.9 | Mixed | Static Analysis (SAST): Medium: REDACTED |
| CleanArchitectureExample.Domain/Interfaces/Persistence/Repositories/IAuthorRepository.cs | 8.2 | Near-clean | Explicit Debt: Dead code: GetAllAuthors |
| CleanArchitectureExample.Domain.Core/DomainNotification/IDomainNotifications.cs | 8.2 | Near-clean | Explicit Debt: Dead code: CleanNotifications |
| CleanArchitectureExample.Persistence/Context/ApplicationDbContext.cs | 8.5 | Near-clean | Code Duplication: Duplicated block (11 lines × 2) |
| README.md | 9.1 | Near-clean | Documentation Quality: Documentation: no project overview |
| CleanArchitectureExample.CrossCutting/CleanArchitectureExample.CrossCutting.csproj | 9.5 | Near-clean | Dependency Hygiene: Outdated: AutoMapper.Extensions.Microsoft.DependencyInjection |
| CleanArchitectureExample.Domain.Core/CleanArchitectureExample.Domain.Core.csproj | 9.5 | Near-clean | Dependency Hygiene: Outdated: MediatR |
How the grades work
A definite problem that already costs you something and drags the score down: a missing authorisation check, a dependency with a known exploit, a build that does not reproduce. Failure here tends to cause failures elsewhere.
Likely wrong, but not failing yet. It degrades the codebase over a longer horizon and can cause failures elsewhere — not urgent this week, not something to carry for two years either.
Recorded, with no effect on how the codebase functions. Present so the survey is complete, not because it needs doing.
Something this survey could not settle from the outside, and which could be critical or serious. Either a control was required and no positive evidence of it exists in the repository — a backup job that nothing shows was ever restored from proves nothing about restores — or our own analysis could not run over that part of the tree. This is not a clean result. These are excluded from the score rather than awarded a pass, so the number on the cover neither rewards nor penalises them: if you act on this survey without resolving them, you carry that risk yourself. Each one is named under Limitations.
Methodology & how to trust this report
Watchdog is a deep, periodic assessment — run each sprint, monthly, or quarterly, taking the time to go wider and deeper than a quick check and surfacing in one coherent report what you'd otherwise piece together from a dozen separate tools. It scores deterministically: the same commit yields the same score, every run. 85 of 90 evaluated dimensions are computed purely by tools and static analysis (confidence 1.0); 5 documentation/naming judgement(s) are LLM-assisted and labelled advisory. Overall confidence is 0.9 — the weighted average across measured dimensions; it falls as more of the score leans on LLM-assisted judgement and rises when it's fully tool-backed.
What we checked — 90 dimensions across the health lenses
- Can you open the finding? Real findings cite a repo-relative file and line you can open at the cited line — never an absolute scratch path. Here, 131 of 159 do; the remainder are repo-wide signals — a dimension-level measurement, not a single line.
- Is there a tool behind the number? Every score below names the method that produced it — Roslyn, git, a scanner, or (for a handful of documentation/naming dimensions) an LLM labelled sampled · advisory — not a narrative.
- Does re-running give the same result? Run it again on the same commit and the score — and this report, byte for byte — is identical. A report whose numbers move between runs is describing the run, not the code.
Tools & methods
| Method | Backs | Version | Evaluator |
|---|---|---|---|
| Roslyn static analysis | Complexity, cohesion, coupling, dead code, API surface, layering | 5.3.0 | ✓ deterministic |
| Native secret scanner | Hardcoded secrets / credentials | 1.0.0 | ✓ deterministic |
| Watchdog duplication detector (in-process) | Code duplication | 1.0.0 | ✓ deterministic |
| Coverage (coverlet / dotnet-coverage) | Line & branch coverage | 10.0.400 | ✓ deterministic |
| NuGet / dotnet | Outdated, vulnerable & deprecated dependencies | 10.0.400 | ✓ deterministic |
| git / LibGit2Sharp | Churn hotspots, knowledge concentration, history | 2.43.0 · 0.31.0 | ✓ deterministic |
| gitleaks · semgrep · trivy | Secrets in history, SAST, CVEs, IaC & container, PII / GDPR | 1.86.0 · 0.69.3 | ✓ deterministic |
| LLM (sampled · advisory) | Documentation quality, ADR conformance, naming — sampled over a bounded sample; advisory, never a deterministic measurement | Local LLM | ◐ LLM · sampled · advisory |
Run transparency — what happened this run
- D8 Code Coverage — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Coverage NOT MEASURED: the analyzer environment could not build/run the test suite (a target framework / SDK band or targeting pack the analyzer image doesn't carry). This is OUR limitation, not a defect in the repo — coverage is excluded from the score rather than counted as a near-zero. We track the analyzer-image gap so it can be closed; in the meantime, no coverage collector was found in your CI either, so there is no existing report to hand us — add a collector to your test run and commit (or publish into the working tree) its Cobertura/OpenCover/lcov output, and real coverage will be read. You can widen what we reach: optional: add a coverage collector to your test run and commit (or publish into the working tree) its Cobertura/OpenCover/lcov output, and the real number is read on the next scan.
- D11 Test Reliability — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Test reliability not scored — the test tier(s) ran but surfaced none of this repository's 34 test method(s) to the runner, so flakiness couldn't be exercised. This is an analysis-environment limitation, not a finding about the tests.
- D15 Churn × Complexity Hotspots — measured, with a gap in what it reached — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. Git history depth insufficient — this repository has 12 commit(s), too few for a reliable trend signal. The clone is complete, so there is no deeper history to fetch: the signal returns as the project accumulates history.
- D16 Bus Factor — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. Single-contributor repository — bus factor is not applicable (1 contributor(s) across 12 commit(s) sampled, automation and bot accounts excluded). Concentration needs a team to concentrate: with one contributor there is nobody to spread the knowledge to, so there is nothing here for the owner to act on.
- D22 Internal API Consistency — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. The loaded project set declares no packable project and no `.Contracts` project, so there is no intentionally-exposed surface for API consistency to be judged over.
- D34 Knowledge Freshness — not measured this run — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. Too few commits to judge knowledge freshness (12 commit(s) sampled).
- D35 Change Coupling — measured, with a gap in what it reached — This is a true statement about the repository that carries nothing for its owner to act on, so it is reported here rather than as a defect in their code. Git history depth insufficient — this repository has 12 commit(s), too few for a reliable change-coupling signal. The clone is complete, so there is no deeper history to fetch: the signal returns as the project accumulates history.
- AXR1 Runtime accessibility — not measured this run — Watchdog could not measure this here. That is a gap on our side — a collector, parser or image we have not built yet — and it is neither a defect in this repository nor evidence that the check would have passed. Render strategy: boot via ToolchainServer (CleanArchitectureExample.WebAPI). the service exited before it opened a port — `ASPNETCORE_URLS=http://127.0.0.1:0 ASPNETCORE_ENVIRONMENT=Development dotnet run --no-build --no-launch-profile --project 'REDACTED'`: share/dotnet The following frameworks were found: 6.0.36 at [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] 7.0.20 at [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] 8.0.27 at [/usr/sha…; runtime evidence skipped (launch chosen because REDACTED is a Microsoft.NET.Sdk.Web project).
Limitations & what we did not check
Watchdog assesses the repository exactly as committed, and only the repository. By design it does not reach outside the source tree: the live cloud account, the running CI/CD pipeline, the host's branch-protection and approval rules, the production configuration, or a restore actually exercised against a backup are all out of scope. That boundary is a feature, not a gap — a repo-relative, deterministic scan re-runs identically on any commit and every finding opens at a real file and line, where a live audit can neither be reproduced nor traced. The visible consequence is that controls which leave no in-repo evidence are reported as "not evidenced" and excluded from the score rather than awarded a number a static scan cannot justify.
Per-dimension blind spots
- D1 Cyclomatic Complexity: Cyclomatic complexity counts branches statically — it cannot tell an essential decision tree from accidental tangle, nor see complexity that lives in data or configuration (large switch-case token tables, DSL lexers/parsers, data-as-code rule tables) rather than control flow: a tokenizer's many single-character cases read as high complexity though each branch is trivial.
- D2 Cognitive Complexity: Cognitive-complexity heuristics approximate how hard code is to follow; genuine domain difficulty and well-named intent that eases reading are not captured.
- D3 God Classes: "God class" is sized by members and responsibilities visible in the type — a deliberately broad facade over a coherent subsystem can read the same as an accidental grab-bag. For front-end JS the file-length check is cohesion-aware (a single-responsibility module — one class/IIFE — earns a 3× threshold), but cohesion is approximated from top-level declarations, not true dependency structure.
- D4 Code Duplication: Duplication is token-similarity — an in-process token-stream comparison over sliding windows, with type-aware normalization — so it finds copy-paste, not semantic duplication expressed differently. Committed machine-written code (scaffolded migrations, designer/codegen output, protobuf/OpenAPI stubs, model snapshots) is EXCLUDED — its repetition is the tool's, not the team's — so the score reflects hand-written duplication only.
- D5 Coupling: Coupling is measured between projects/assemblies — runtime coupling through DI, reflection, messaging or shared databases is invisible to a static reference graph.
- D6 Cohesion (LCOM4): LCOM4 cohesion is syntactic — it infers connectivity from which methods touch which fields/methods by name, not from real runtime behaviour or intent.
- D9 Test Distribution: The test-pyramid shape is inferred from project/folder naming and references, with a single test host bucketed per-file by its path tier and content signals — a suite that names tiers unconventionally and gives no per-file signal can still be mis-bucketed.
- D10 Test Quality: Assertion density is structural — it cannot tell a meaningful behavioural assertion from a trivial one, only that an assertion is present.
- D12 Dependency Hygiene: Dependency health reads manifests and lockfiles — a vulnerability in a vendored/copied dependency, or risk from how a dependency is actually used, is outside this view.
- D13 Secret Scanning: Secret detection is signature- and entropy-based on the current tree — a secret that does not match a known pattern, or one already rotated, will not be flagged (a clean scan is "nothing matched", not "no secrets exist").
- D14 License Compliance: License compatibility is checked against declared package metadata and a policy — mislabelled or missing license metadata, and obligations that depend on how you distribute, are not resolved here.
- D15 Churn × Complexity Hotspots: Churn hotspots come from git history — a freshly imported or squashed repository has no churn signal, and recent rewrites can mask a historically risky file.
- D17 Explicit Debt: Acknowledged-debt signals (TODO/FIXME, suppressions, dead code) are textual — undocumented debt that nobody marked, and debt that lives in design rather than annotations, is invisible. Committed machine-written code (scaffolded migrations, designer/codegen output, generated stubs) is excluded — it is never the team's dead code to delete.
- D18 Solution Shape: Build integrity reflects whether the solution compiled in this environment — a build that needs a private feed, a specific SDK, or a generated file absent from the repo can read as broken when it is merely unreproducible here.
- D19 Documentation Quality: Documentation quality is judged by an LLM over a bounded sample of docs — it reads what is written, not whether the docs match the running system, and it is advisory, not a measurement. Its critique rows are drawn from a closed category vocabulary and each row means the same thing in every run, so two scans can be compared row by row; the SET that fires is still a sample, and does not repeat exactly. Measured on one frozen input, six scans at one engine SHA: 2-5 critique rows per scan, 8 distinct rows across the six, 3 of those 8 seen in only one scan. So a D19 row is evidence about the documentation, but a COUNT of D19 rows is not a quantity — never read a change in it as an improvement or a regression.
- D20 ADR Quality: ADR quality is an LLM read of the decision records present — it cannot know about decisions made and never recorded, and its verdict is sampled and advisory.
- D21 Naming Consistency: Naming quality is an LLM judgement over a bounded sample — it assesses clarity/consistency of the names it sees, not domain-correctness, and is advisory.
- D24 Comment Value: Comment value (WHY vs WHAT) is an LLM judgement over a bounded sample — it is advisory and cannot weigh a comment against the precise code change it was written to explain.
- D26 Project Cohesion: Project focus is sized from members/namespaces per project — a project that is broad by deliberate design reads the same as one that has sprawled.
- D27 Navigability: Indirection/navigability is structural — it measures hops to follow a call, not whether that indirection buys real flexibility or just ceremony.
- D28 Secrets (history): Secret-history scanning sweeps the git log for known patterns — a secret that predates the available history, or never matched a signature, is not found (clean means "nothing matched in the history we can see").
- D29 Static Analysis (SAST): SAST findings are pattern-based (semgrep) — it finds classes of bug it has rules for; logic flaws, auth/authorization gaps and issues needing runtime context are out of reach (and clean means "no rule matched").
- D30 Dependency Vulnerabilities: CVE matching depends on accurate package/version metadata and on the advisory databases — a vulnerability with no published advisory, or in code not declared as a dependency, is not seen. Coverage needs a RESOLVED graph: an unpinned requirements.txt, or a pom without a resolved build, yields partial coverage rather than a clean verdict. An ecosystem the analyzer cannot scan is reported as unmeasured, never as clean.
- D35 Change Coupling: Change coupling is co-change in COMMITS — files split across separate commits, or coupled only through a shared config/build step, read as uncoupled, and a sweeping commit (rename/format) is excluded so it doesn't couple everything. It shows that files change together, not WHY: a high coupling can be a healthy cohesive pair as readily as a hidden leak.
- D44 Platform End-of-Life: The support table is FROZEN, so it goes out of date by losing RECALL: a release that ended support after the table was written is missed until the table is refreshed, and this dimension reading 10 is not evidence that a platform is current. Only platforms the repository DECLARES in a place this pass reads are seen — a runtime named only in a Dockerfile (D31's subject), in a CI workflow (D29's), or in a file this pass does not parse (go.mod, a Gemfile ruby directive) is invisible here, which is why a repository declaring none of them abstains rather than scoring. Only frameworks with a PUBLISHED support policy are tracked: React, Flask and Express publish none, so their age cannot be judged and their absence from a report is not a statement that they are supported.
- AX10 Code composition: Role is inferred from namespace/folder convention, not semantics — a domain concept living in a folder named "Services" reads as application, and the split is lines-of-code, not business value. The business-logic-share score is a SOFT, FLOORED signal: it contributes to the Architecture lens but is floored at the Critical gate, so an infrastructure-heavy design (a gateway, an ETL, a driver) is legitimately low without being nuked to zero.
- AX9 CQS / query purity: Handlers are found by interface/name convention — a query handler using neither is not seen. Mutation is a resolved write/publish invocation (SaveChanges/repository/bus), so a write hidden behind a hand-rolled wrapper, reflection, or a string-keyed service locator resolves to a non-persistence type and isn't flagged; it detects that a query writes state, not whether the write is a legitimate read-side cache update. Clean means "no resolved write/publish in a query body", not a proof of CQS purity.
- DM4 Rich vs anemic model: Behaviour is detected as state mutation inside a method body — a method that enforces an invariant by validating-and-throwing without mutating reads as a query, and mutation delegated through an interface the scan can't resolve isn't credited; entities with zero public properties still drop out of the population. It detects that state changes, not whether the rule is correct.
- DM6 Domain ↔ infrastructure boundary: Infrastructure reached through a hand-rolled wrapper, a domain-named facade, reflection, or a string-keyed service locator resolves to a non-infra type and isn't seen; the body scan is symbol resolution over syntax, not full dataflow. A clean result means "no resolved infra reference in a domain body", not a proof of purity.
- ED5 Idempotency: Idempotency is judged from the handler body's visible writes and guards — a guard enforced by a database unique constraint, a broker's exactly-once delivery, or a domain method whose no-op-when-applied logic the scan can't follow may read as at-risk; the at-risk candidates are confirmed by a SAMPLED LLM verdict (advisory, not exhaustive) and degrade to heuristic-only when no model is configured. It flags the at-least-once double-apply SHAPE, not a runtime proof of a duplicate effect.
- M4 Documentation accuracy: Onboarding quality is an LLM read of the docs/setup present — it cannot run the onboarding or measure how long a real new joiner takes; the verdict is sampled and advisory.
The LLM boundary
Dimensions
D1 · Cyclomatic Complexity
0 method(s) exceeded the cyclomatic complexity threshold of 15.
D2 · Cognitive Complexity
0 method(s) exceeded the cognitive complexity threshold of 15.
D3 · God Classes
0 god class(es) detected.
D4 · Code Duplication
1 duplicated block group(s) detected.
What to do
- Resolve the 1 Duplicated block (11 lines × 2) finding(s) in Code Duplication — start with ApplicationDbContext.cs. — One of this dimension's main actionable groups (1 warning-level).
- Stand up a CI pipeline, then gate Code Duplication in it to reach Verified (currently Documented). — This repository has no CI pipeline, so there is nothing to add a gate to yet — the pipeline comes first. Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
D5 · Coupling
8 projects, 0 dependency cycle(s), 0 unstable depended-on project(s).
D6 · Cohesion (LCOM4)
0 of 7 classes have LCOM4 above 3.
D9 · Test Distribution
34 test methods: 34 unit, 0 integration, 0 BDD, 0 e2e.
D10 · Test Quality
0 skipped, 0 zero-assertion, 1 mock references across 34 tests.
D12 · Dependency Hygiene
22 outdated, 1 vulnerable, 10 deprecated packages.
What to do
- Resolve the 14 Outdated finding(s) in Dependency Hygiene — start with REDACTED (4), REDACTED (4), REDACTED (3). — One of this dimension's main actionable groups (14 recommendation-level).
- Resolve the 10 Deprecated finding(s) in Dependency Hygiene — start with REDACTED (4), REDACTED (3), REDACTED (2). — One of this dimension's main actionable groups (10 warning-level).
- Resolve the 1 Vulnerable finding(s) in Dependency Hygiene. — One of this dimension's main actionable groups (1 issue-level).
- Stand up a CI pipeline, then gate Dependency Hygiene in it to reach Verified (currently Documented). — This repository has no CI pipeline, so there is nothing to add a gate to yet — the pipeline comes first. Hardens enforcement from Documented toward Verified — provenance only; does not change the score.
D13 · Secret Scanning
Secret scan ran and found no leaked secrets.
D14 · License Compliance
0 of 250 packages use a banned license. ★ DEPTH: this repository's MSBuild projects declare 22 direct `PackageReference`(s), and 228 further package(s) were reached beyond them by closing the graph over nuget.org's own nuspec dependency graph — so a banned licence pulled in only by a dependency's OWN dependencies is inside this verdict. A package whose licence nuget.org could not be asked for is not graded, and version ranges are taken at their lower bound, so this is the closure as that graph states it rather than a restored consumer's exact resolution.
D15 · Churn × Complexity Hotspots
No churn × complexity hotspots in the window.
D17 · Explicit Debt
1 deducted debt markers + 15 dead symbols across 2372 LoC in the .NET projects (1.1/KLoC) → score 7.8.
What to do
- Resolve the 15 Dead code finding(s) in Explicit Debt — start with IEventDispatcher.cs (5), IBookRepository.cs (3), AssertionsConcern.cs (3). — One of this dimension's main actionable groups (15 warning-level).
- Resolve the 1 WriteOnlyPrivateField finding(s) in Explicit Debt — start with SmsServices.cs. — One of this dimension's main actionable groups (1 issue-level).
- Stand up a CI pipeline, then gate Explicit Debt in it to reach Verified (currently Documented). — This repository has no CI pipeline, so there is nothing to add a gate to yet — the pipeline comes first. Hardens enforcement from Documented toward Prevented — provenance only; does not change the score.
D18 · Solution Shape
8 projects, 96 source files, 3194 hand-written lines of code (2372 production / 822 test — the split is derived per file: test is what its project, its own path, or a compile-guarded region marks as test, and a file carrying no test signal counts as production), plus 1751 generated (machine-written code — designer, scaffolded and tool-emitted files — excluded from quality), 16 inter-project edges.
D19 · Documentation Quality
The repository's single README is a self-contained study-documentation for CleanArchitectureExample that describes the project (itself) in pseudo-code terms plus lists applied concepts and tools. It does not explain what the project does or how to use its contents; it is an ideal personal-study README but lacks the overview, installation/usage, contribution guidance, and licence of a real documentation set.
What to do
- Resolve the 3 Documentation finding(s) in Documentation Quality — start with README.md (3). — One of this dimension's main actionable groups (3 recommendation-level).
D20 · ADR Quality
No architecture decision records were found.
What to do
- Resolve the 1 No ADRs found finding(s) in ADR Quality. — One of this dimension's main actionable groups (1 recommendation-level).
D21 · Naming Consistency
4 naming inconsistencies across 200 sampled symbols.
What to do
- Resolve the 1 The event class is named 'LoanEffetivatedEvent' (containing a typo for… finding(s) in Naming Consistency. — One of this dimension's main actionable groups (1 recommendation-level).
- Resolve the 1 The field '_orquestrator' in BookController contains a typo… finding(s) in Naming Consistency. — One of this dimension's main actionable groups (1 recommendation-level).
- Resolve the 1 The field 'retryPolice' in EmailServices is a typo for 'retryPolicy'.… finding(s) in Naming Consistency. — One of this dimension's main actionable groups (1 recommendation-level).
D24 · Comment Value
32 valuable / 0 redundant across 91 sampled comments.
D26 · Project Cohesion
0 of 8 projects flagged as possibly oversized/incoherent.
D27 · Navigability
98 % of calls cross a namespace and 6 % go through an interface, but 100 % of collaborators are co-located — so a call's collaborators sit together and tracing stays easy. Baseline: small — navigation cost is tolerated.
D28 · Secrets (history)
gitleaks scanned the full history AND the current working tree and found no secrets.
D29 · Static Analysis (SAST)
8 finding(s): 0 critical, 0 high, 8 medium, 0 low.
What to do
- Resolve the 8 REDACTED finding(s) in Static Analysis (SAST) — start with REDACTED (3), REDACTED (2), REDACTED. — One of this dimension's main actionable groups (8 warning-level).
D30 · Dependency Vulnerabilities
10 finding(s): 2 critical, 6 high, 2 medium, 0 low.
What to do
- Resolve the 6 High CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (3), REDACTED, REDACTED. — One of this dimension's main actionable groups (6 issue-level).
- Resolve the 2 Critical CVE finding(s) in Dependency Vulnerabilities — start with REDACTED, REDACTED. — One of this dimension's main actionable groups (2 issue-level).
- Resolve the 2 Medium CVE finding(s) in Dependency Vulnerabilities — start with REDACTED (2). — One of this dimension's main actionable groups (2 warning-level).
D35 · Change Coupling
No strong hidden change-coupling between production files.
D39 · IL Efficiency
0 of 189 first-party methods have an oversized IL body.
D44 · Platform End-of-Life
1 end-of-life runtime(s) and 0 end-of-life framework(s), read from 8 platform declaration(s) and 0 dependency declaration(s). This dimension reads what the repository says about ITSELF — a pinned target framework, a version file, a capped requires-python, a Rust toolchain pin, a framework major a constraint cannot move off. A FLOOR is deliberately never charged: `requires-python = ">=3.8"` states what the package SUPPORTS, not what it runs on, and a well-maintained library declares exactly that while running its own CI on a current release. The end-of-life facts are FROZEN and dated, so this dimension needs no network and answers identically inside a closed scan fence; as the table ages it loses recall and never precision, because a statement about support that ended in the past cannot become false. The OS layer of a container image is D31's question and the toolchain a CI workflow installs is D29's; this row is neither.
What to do
- Resolve the 1 End-of-life runtime finding(s) in Platform End-of-Life — start with REDACTED. — One of this dimension's main actionable groups (1 warning-level).
Frontend & cross-cutting dimensions
AX1 · Captive dependencies
AX10 · Code composition
AX2 · Stateful singletons
AX3 · Project dependency cycles
AX4 · Dependency direction
AX5 · Architecture & structure
AX6 · Interface segregation
AX8 · Test isolation
AX9 · CQS / query purity
C1 · Data Protection
- No data-protection or encryption usage (ASP.NET Data Protection, AES, column encryption, PBKDF2) was found — sensitive data at rest may be unprotected. If TDE/KMS/vault is delegated to infrastructure, ignore.
What to do
- Encrypt sensitive data at rest (ASP.NET Core Data Protection / column encryption) and manage keys in a vault. Skip if delegated to infra (Postgres TDE, KMS, etc.).
- Enforce HTTPS (UseHttpsRedirection / RequireHttpsMetadata) so data in transit is always encrypted.
C2 · Access Controls
- No [Authorize]/policies and no imperative guard methods (throw-on-violation) were found — endpoints may be unprotected.
- `AuthorController.AddAuthor` serves requests and nothing authorizes it: no [Authorize] or RequireAuthorization on it or its controller/group, no fallback policy, no auth-gate middleware and no imperative guard in this codebase. — REDACTED:25
- `BaseController.ReturnRequestResult` serves requests and nothing authorizes it: no [Authorize] or RequireAuthorization on it or its controller/group, no fallback policy, no auth-gate middleware and no imperative guard in this codebase. — REDACTED:18
- `BookController.AddBook` serves requests and nothing authorizes it: no [Authorize] or RequireAuthorization on it or its controller/group, no fallback policy, no auth-gate middleware and no imperative guard in this codebase. — REDACTED:25
- `BookLoanController.Loan` serves requests and nothing authorizes it: no [Authorize] or RequireAuthorization on it or its controller/group, no fallback policy, no auth-gate middleware and no imperative guard in this codebase. — REDACTED:27
- `BookLoanController.ReturnBook` serves requests and nothing authorizes it: no [Authorize] or RequireAuthorization on it or its controller/group, no fallback policy, no auth-gate middleware and no imperative guard in this codebase. — REDACTED:35
- `BookLoanController.GetAllLoans` serves requests and nothing authorizes it: no [Authorize] or RequireAuthorization on it or its controller/group, no fallback policy, no auth-gate middleware and no imperative guard in this codebase. — REDACTED:43
- `PersonController.AddPerson` serves requests and nothing authorizes it: no [Authorize] or RequireAuthorization on it or its controller/group, no fallback policy, no auth-gate middleware and no imperative guard in this codebase. — REDACTED:26
- `PersonController.GetAll` serves requests and nothing authorizes it: no [Authorize] or RequireAuthorization on it or its controller/group, no fallback policy, no auth-gate middleware and no imperative guard in this codebase. — REDACTED:34
What to do
- Protect endpoints by default-deny: [Authorize] + role/policy authorization, or imperative guard methods (throw-on-violation) called from every handler.
DM1 · Aggregate boundaries
- `Book` references the aggregate root `BookLoan` directly (via `BookLoans`) — hold its `BookLoanId` instead. — CleanArchitectureExample.Domain/Entities/Book.cs:34
- `BookLoan` references the aggregate root `Book` directly (via `Book`) — hold its `BookId` instead. — CleanArchitectureExample.Domain/Entities/BookLoan.cs:26
- `BookLoan` references the aggregate root `Person` directly (via `Taker`) — hold its `PersonId` instead. — CleanArchitectureExample.Domain/Entities/BookLoan.cs:27
- `Person` references the aggregate root `BookLoan` directly (via `BookLoans`) — hold its `BookLoanId` instead. — CleanArchitectureExample.Domain/Entities/Person.cs:37
What to do
- Reference other aggregates by their strongly-typed id, never by object reference, so each aggregate stays an independent consistency boundary.
DM10 · One transaction, one aggregate
DM11 · Constructible invalid state
- `Book`'s public constructor takes `title`, `releaseYear`, `edition`, `iSBN` as raw primitives, and neither of the two things that would make that safe was found. What was searched, so you can tell an absence from a miss: for VALIDATION, the constructor body was scanned for `throw`, `Guard.`, `Ensure.`, `ArgumentNullException`, `ArgumentException`, `CheckRule` or `Requires.` — a guard reached through a helper method those tokens do not name is not seen; for a FACTORY, only this type's OWN static members were read, and only names beginning `Create`, `Of`, `From`, `New` or `Build` — one inherited from a base type, one on a companion builder, or one called `Parse`, `Make` or `Rehydrate` is not seen. If either exists, this row is wrong. If neither does, a caller can build a `Book` that breaks the rules it exists to enforce, and every rule downstream then has to cope with a state the model said was impossible. Guard in the constructor, take value objects that validate themselves, or make the constructor private behind a `Create` that can refuse. — CleanArchitectureExample.Domain/Entities/Book.cs:14
- `Person`'s public constructor takes `document`, `name`, `email` as raw primitives, and neither of the two things that would make that safe was found. What was searched, so you can tell an absence from a miss: for VALIDATION, the constructor body was scanned for `throw`, `Guard.`, `Ensure.`, `ArgumentNullException`, `ArgumentException`, `CheckRule` or `Requires.` — a guard reached through a helper method those tokens do not name is not seen; for a FACTORY, only this type's OWN static members were read, and only names beginning `Create`, `Of`, `From`, `New` or `Build` — one inherited from a base type, one on a companion builder, or one called `Parse`, `Make` or `Rehydrate` is not seen. If either exists, this row is wrong. If neither does, a caller can build a `Person` that breaks the rules it exists to enforce, and every rule downstream then has to cope with a state the model said was impossible. Guard in the constructor, take value objects that validate themselves, or make the constructor private behind a `Create` that can refuse. — CleanArchitectureExample.Domain/Entities/Person.cs:18
What to do
- Give each aggregate one way in that can refuse — a guarded constructor, value-object parameters that validate themselves, or a private constructor behind a factory that returns a failure.
DM12 · Ambient inputs in the domain
- `Book` reads `DateTime.Now` inside `Validate`. The rule this feeds is not a function of its inputs: it cannot be tested at the instant that matters without moving the machine clock, and two reads inside one operation can observe different times. Pass the instant in as a parameter, or inject `TimeProvider`. — CleanArchitectureExample.Domain/Entities/Book.cs:37
- `BookLoan` reads `DateTime.Now` inside `ValidateLend`, `ReturnBook`. The rule this feeds is not a function of its inputs: it cannot be tested at the instant that matters without moving the machine clock, and two reads inside one operation can observe different times. Pass the instant in as a parameter, or inject `TimeProvider`. — CleanArchitectureExample.Domain/Entities/BookLoan.cs:36
What to do
- Pass the instant into the domain method that needs it, or inject `TimeProvider` (BCL, .NET 8+) and read it there — then a test can choose the moment a rule is evaluated at.
DM2 · Strongly-typed ids
- `Book.BookId` is a raw `Guid` — give it a strongly-typed id: a dedicated single-field type wrapping the `Guid`, in whatever form your language spells that. — CleanArchitectureExample.Domain/Entities/Book.cs:24
- `Book.AuthorId` is a raw `Guid` — give it a strongly-typed id: a dedicated single-field type wrapping the `Guid`, in whatever form your language spells that. — CleanArchitectureExample.Domain/Entities/Book.cs:29
- `BookLoan.BookLoanId` is a raw `Guid` — give it a strongly-typed id: a dedicated single-field type wrapping the `Guid`, in whatever form your language spells that. — CleanArchitectureExample.Domain/Entities/BookLoan.cs:18
- `BookLoan.BookId` is a raw `Guid` — give it a strongly-typed id: a dedicated single-field type wrapping the `Guid`, in whatever form your language spells that. — CleanArchitectureExample.Domain/Entities/BookLoan.cs:19
- `BookLoan.TakerId` is a raw `Guid` — give it a strongly-typed id: a dedicated single-field type wrapping the `Guid`, in whatever form your language spells that. — CleanArchitectureExample.Domain/Entities/BookLoan.cs:20
- `Person.PersonId` is a raw `Guid` — give it a strongly-typed id: a dedicated single-field type wrapping the `Guid`, in whatever form your language spells that. — CleanArchitectureExample.Domain/Entities/Person.cs:30
What to do
- Adopt strongly-typed ids across the domain — finish the migration or document the boundary; primitive ids invite transposed-argument bugs.
DM4 · Rich vs anemic model
DM5 · Encapsulated state
- `Book` exposes its own state through a mutable collection (BookLoans) — a caller can add to or remove from it directly, without passing through the methods that enforce the invariants. — CleanArchitectureExample.Domain/Entities/Book.cs:10
- `Person` exposes publicly writable state (PhoneNumbers, BookLoans). — CleanArchitectureExample.Domain/Entities/Person.cs:11
What to do
- Make entity setters private/init-only and hand collections out as IReadOnlyList/IReadOnlyCollection over a private backing field; change state only through methods that enforce the invariants (Marten/EF can bind via constructor or private setters).
DM6 · Domain ↔ infrastructure boundary
- `HttpContextServiceProviderProxy` (domain layer) names `IHttpContextAccessor` from `Microsoft.AspNetCore.Http` — a HTTP type (in a member signature). The domain should own a port and let an infrastructure adapter implement it. (×2) — CleanArchitectureExample.Application/DomainNotifications/HttpContextServiceProviderProxy.cs:11, CleanArchitectureExample.Application/DomainNotifications/HttpContextServiceProviderProxy.cs:13
What to do
- Invert domain→infrastructure dependencies: declare interfaces in the domain, implement them in infrastructure (Dependency Inversion).
DM7 · Repository granularity
DM8 · Value-object opportunities
- The parameters [message, value1, value2] travel together across 6 signatures and were confirmed as a coherent concept by the model — that's a missing value object. Extracting them into one type (e.g. `Address`, `Money`, `Coordinate`) removes repetition, prevents argument-order mistakes, and gives the concept a home for its rules. — CleanArchitectureExample.Domain.Core/Validators/AssertionsConcern.cs:26
What to do
- Extract recurring primitive parameter clusters into value objects so the concept (and its rules) lives in one place.
DM9 · Scattered domain decisions
ED1 · Handler temporal coupling
ED2 · Event/command shape
ED3 · Event naming
ED4 · Outbox / dual-write
ED5 · Idempotency
GD1 · Unfinished & placeholder code
IC1 · Incompleteness & stubs
- `ReturnRequestResult` is declared `async` but never awaits anything, so it runs synchronously while pretending to be asynchronous. Drop `async` or do the real async work. — REDACTED:18
- A line of code has been commented out rather than removed — dead weight that rots and confuses. Delete it (version control remembers). — CleanArchitectureExample.WebAPI/Startup.cs:34
What to do
- Clear the softer debt: remove commented-out code and dead branches, re-enable or delete skipped tests, and replace blanket warning suppressions with targeted ones.
M1 · Documentation (README)
What to do
- Add a build/run (quick start) section to the root README — the first thing a newcomer needs.
- Explain in the README how to run the tests. Add a section called Testing to the README in the repository's top folder, saying how to run the test suite.
- Add a README to the 8 of 8 project(s) that lack one — worth up to 2 pts.
M2 · Architecture documentation
- No Architecture Decision Records found — no conventional ADR directory, no numbered `NNNN-title` documents in any markup this check reads, and nothing ADR-shaped by content. Design rationale recorded elsewhere (a design-notes tree, a mailing list, pull-request discussion) is not visible to this check and is not re-findable per decision, so a future maintainer cannot ask why one choice was made and get an answer.
- No C4/Structurizr/PlantUML/Mermaid/Graphviz/D2 diagram, no drawn diagram named for the architecture, no file named `architecture` or `design` in any markup this check reads, and nothing in the README, docs or contributor guides that announces the shape — no `## Architecture` heading, no "architecture overview"/"high-level design" phrasing, no "the architecture is …" introduction, no guided code tour. A shape laid out in prose that never names itself as the architecture is not visible to this check, and neither is one kept outside the repository, so this row reports the absence of a re-findable shape document — not evidence that nobody wrote the shape down.
What to do
- Record your significant design decisions. Write one short document per decision, giving its date, the situation, the decision and its consequences, and keep them together with your other design documents. A docs/adr folder with each file named by number and title is the easiest place to find them.
- Add a C4 context/container diagram (Structurizr, PlantUML or Mermaid) or an architecture.md overview.
M3 · Folder & project structure
- Production code isn't grouped under a src/ folder — it's spread across several top-level directories, so there's no one place that says 'this is the product'.
What to do
- Group production code under src/ (or split deliberately, e.g. backend/ + frontend/) so production and tooling code aren't mixed at the root.
M4 · Documentation accuracy
P1 · CI/CD gates
- No CI workflow found (.github/workflows, azure-pipelines.yml, .gitlab-ci.yml, …) — changes aren't gated by an automated build/test.
What to do
- Add a CI workflow that builds and runs the test suite on every push/PR.
P2 · Observability
- No logging call was found in the 112 `.cs` file(s) this check read. Each was searched for the framework names `ILogger`, `Serilog`, `NLog` and `log4net`; for a call on a receiver whose name ends in `Logger`; for a `System.Diagnostics` write; for a level-gated log facade; and for the builder spellings that CONFIGURE logging for everyone else (`AddLogging(`, `ConfigureLogging(`, `UseSerilog(`, `UseNLog(`, `.Logging.Add…(`); and for emission through an `EventSource`, `ActivitySource` or `DiagnosticSource` (`WriteEvent(`, `StartActivity(`, `.Write("event", …)`). That walk sees only `.cs` documents from projects the workspace loaded, so it cannot see logging in source that did not load, in another language, or through a repo-local wrapper whose name does not end in `Logger` — this is 'no logging found by this walk', not a verdict that nothing here logs. If it is right, production issues will be hard to diagnose.
What to do
- Adopt ILogger (or Serilog) and log at meaningful points across the projects.
- Consider OpenTelemetry tracing/metrics and a health-check endpoint for operability.
P3 · Security & performance tooling
- No static application security testing detected. For this repository's stack, add CodeQL's csharp pack, or a .NET security analyzer package (or `semgrep --config=auto`, which runs on any language) — this repository has no CI pipeline yet, so run it locally to clear the existing findings, then make it a step of the first workflow you add so a regression fails the build. What was searched, so you can tell an absence from a miss: the 0 CI workflow file(s) in this repository, and the scanner and linter configuration checked in beside them. A scan that runs outside CI, one configured in your forge's web UI rather than in a committed file, or a tool whose name is none of those this check carries, is not seen — if that is your case the row is wrong, and saying so is more useful than adding a second scanner.
What to do
- Run what this repository's stack ships: CodeQL's csharp pack, or a .NET security analyzer package — or `semgrep --config=auto`, which runs on any language — locally for now, since there is no CI pipeline here yet, and as a step of the first workflow you add so a security regression fails the build instead of landing.
- Enable Dependabot/Renovate or a dependency-review gate.
- Add gitleaks/trufflehog in CI to block PRs that introduce committed secrets.
P8 · Schema migrations
PF3 · Async & latency hygiene
S1 · Web-Security Posture
- None of the 11 security response headers the OWASP Secure Headers Project recommends (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, …) is configured — defense in depth, even when a reverse proxy could set them. (−2.0 on this card.)
- This web host's pipeline is composed here and adds no security response header (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, a frame policy) to what it serves. — CleanArchitectureExample.WebAPI/Program.cs:20
- No UseHttpsRedirection/UseHsts and no reverse-proxy signal — transport security is unverified at the app layer. (−2.0 on this card.)
- This web host's pipeline is composed here with no UseHttpsRedirection/UseHsts, and nothing says a reverse proxy terminates TLS in front of it. — CleanArchitectureExample.WebAPI/Program.cs:20
What to do
- Add security response headers (Content-Security-Policy first, then Strict-Transport-Security, X-Content-Type-Options and a frame policy) — defense in depth, even when a reverse proxy could set them.
- Enforce HTTPS at the app layer (UseHttpsRedirection / UseHsts) — only skip this if a reverse proxy demonstrably terminates TLS.
X1 · Async correctness
X12 · Unreachable branch
X13 · Undrained process stream
X14 · Bypassable address classification
X15 · Unvalidated length from an untrusted reader
X16 · Unfloored truncation loop
X17 · Uncapped recursion over a caller-supplied document
X18 · Disposal-pattern correctness
X19 · Unrestored process-global state
X2 · Cancellation propagation
- Only 9/37 async methods accept a CancellationToken, so in-flight work can't be stopped early when the caller gives up — whatever ends it in your host (shutdown signal, timeout, abandoned request, user cancel). Thread a token through the call chain and honour it at each await and loop; where a method genuinely cannot be interrupted, omitting it is a deliberate choice — judge against your hosting model.
- No CancellationToken parameter — this work can't be stopped early once started. (×28) — CleanArchitectureExample.Persistence/Repositories/AuthorRepository.cs:18, CleanArchitectureExample.Persistence/Repositories/AuthorRepository.cs:24, CleanArchitectureExample.Persistence/Repositories/AuthorRepository.cs:29, …
What to do
- Thread a CancellationToken through async methods so work stops promptly on cancellation.
X20 · Mistyped argument guard
X21 · Side-effecting pattern guard
X22 · Contradicted release guard
X23 · Unguarded diagnostic materialisation
X24 · Document value interpolated into markup unescaped
X25 · Inert configuration knob
X26 · Unsynchronised callback handoff
X27 · Collection changed while being enumerated
X28 · Index access outside its own emptiness guard
X29 · Per-element action decided by a fixed element
X3 · Exception handling
X30 · Support guard that admits what it rejects
X32 · Type resolved by simple name across every loaded assembly
X4 · Structured logging
X5 · Nullable reference types
- 0/7 NRT-eligible project(s) enable <Nullable>enable</Nullable> (projects targeting a pre-C#-8 framework are excluded — NRTs aren't available there). NRTs catch a whole class of null-deref bugs at compile time.
What to do
- Enable <Nullable>enable</Nullable> across all projects and resolve warnings rather than suppressing with `!`.
Reference — by lens
| Lens | Score | Rating | Impact |
|---|---|---|---|
| Code Health | 63% | Adequate — gated by X5 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Architecture | 93% | Exemplary | Solid. |
| Maturity | 50% | Adequate — gated by M2 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Readiness | 25% | Weak — gated by D12, P1, P2, P3 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Security | 22% | Critical — gated by D30, C1, C2 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Domain Modelling | 48% | Weak — gated by DM1, DM2 | Capped at Fair by a Critical contributor — resolve it before relying on this lens. |
| Event-Driven | 100% | Exemplary | Strongest area. |
| Performance | 100% | Exemplary | Solid. |
Unscored — 2 check(s) recorded observations but carry no score
- SC1 Supply-chain hygiene — 1 observation(s) recorded · Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X7 Silent fallback defaults — 2 observation(s) recorded · Advisory — this card reports evidence and never carries a score.
Not evidenced — 6 control(s) we could not find positive evidence for
- C3 Audit Trail — Repo shows no audit-logging mechanism (IAuditable, an immutable audit log, an EF SaveChanges interceptor) for sensitive changes — absence of evidence is not evidence of a working control. Record an audit trail in code (or document where it lives) so this dimension can be scored.
- C4 Data Retention — Repo shows no data-retention / TTL / cleanup mechanism for personal data — absence of evidence is not evidence of a working control. Define retention periods and a purge/cleanup job (or TTL) in code, or document where retention is enforced, so this dimension can be scored.
- C5 Data-Subject Rights — Repo shows no corroborated data-subject-rights mechanism (erasure / export-portability / consent) tied to a subject id or GDPR vocabulary — absence of evidence is not evidence of a working control. Implement erasure, data export/portability and consent tracking over the subject's records.
- P4 Deployment & Rollback — not evidenced — no deploy/rollback/approval signal in the repo; absence of evidence is not evidence of a manual release
- P5 DR & Backup — not evidenced — repo shows no backup/RTO/RPO controls; absence of evidence is not evidence of a working control
- P6 Release Hygiene — not evidenced — no changelog, version stamp or semver release tag in the repo
Not included — 36 check(s) not relevant to this codebase
- AC1 Text alternatives — No web markup found — accessibility is not applicable to this repository.
- AC2 Forms & labels — No web markup found — accessibility is not applicable to this repository.
- AC3 Page structure — No web markup found — accessibility is not applicable to this repository.
- AC4 Keyboard semantics — No web markup found — accessibility is not applicable to this repository.
- AC5 ARIA correctness — No web markup found — accessibility is not applicable to this repository.
- AC6 Visual & motion safety — No web markup found — accessibility is not applicable to this repository.
- AC7 A11y enforcement — No web markup found — accessibility is not applicable to this repository.
- AX7 Slice cohesion — not applicable — not a vertical-slice architecture
- AXB2 Runtime readiness — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- AXR1 Runtime accessibility — the service exited before it opened a port — `ASPNETCORE_URLS=http://127.0.0.1:0 ASPNETCORE_ENVIRONMENT=Development dotnet run --no-build --no-launch-profile --project 'REDACTED'`: share/dotnet The following frameworks were found: 6.0.36 at [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] 7.0.20 at [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] 8.0.27 at [/usr/sha…; runtime evidence skipped (launch chosen because REDACTED is a Microsoft.NET.Sdk.Web project) This is a statement about this run, not a statement about your application: nothing here says the surface is inaccessible, only that it was never rendered.
- D11 Test Reliability — Test runner surfaced no tests
- D16 Bus Factor — single-contributor repository — bus factor is not applicable
- D22 Internal API Consistency — No intentionally-exposed public API to evaluate for consistency.
- D23 Boundary Type-Coupling — small single-context codebase (2,372 production LoC in the .NET projects) — bounded contexts are not needed at this size No bounded-context organisation was detected either — neither a context-shaped layout, nor 2+ sibling source directories each declaring an aggregate root, nor 2+ projects each declaring an entity of their own. Aggregate roots were found in only one source directory (CleanArchitectureExample.Domain), which is a layered codebase, not two contexts. Declaring this codebase's bounded contexts (≥2) would let cross-boundary type coupling be assessed. Declare them in `.codehealth/config.yaml` at the repository root (create it if absent), mapping each context name to the module-path or namespace prefixes that belong to it — e.g. `architecture:` → `contexts:` → `Billing: ["src/billing", "Acme.Billing"]`, `Catalog: ["src/catalog", "Acme.Catalog"]`.
- D25 ADR Conformance — no ADRs to check
- D31 IaC & Container Security — No Infrastructure-as-Code or container manifests found (Dockerfile, Docker Compose, Terraform, Kubernetes/Helm, CloudFormation, ARM, Bicep, Ansible); nothing to scan.
- D32 Data Compliance (PII/GDPR) — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that.
- D34 Knowledge Freshness — too few commits to judge knowledge freshness
- D36 Supply-chain Provenance & Signing — No CI/build pipeline found (.github/.forgejo/.gitea workflows, .circleci, .buildkite, .woodpecker, .teamcity, .gitlab-ci.yml, .travis.yml, bitbucket-pipelines.yml, .drone.yml, .cirrus.yml, .woodpecker.yml, appveyor.yml, azure-pipelines*.yml, .pipelines/, .vsts-ci/, .azuredevops/, Jenkinsfile); there is no build to attest provenance for.
- D37 Vulnerability-disclosure Policy — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed.
- D40 Network Egress Confinement — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here.
- D41 Kernel & Syscall Confinement — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here.
- D42 Runtime Threat Enforcement — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here.
- D43 Malicious Dependencies — Not scored — no dependency manifest in a supported ecosystem was read for this repository. A gap in the analyzer's language coverage, NOT a finding that the repository is free of vulnerable dependencies (a Python pyproject.toml/requirements.txt (pip/uv/Poetry), a Swift Package.swift/Package.resolved, a Cargo manifest, a Go module (go.mod/go.sum), a Gradle version catalogue, a Maven POM, an sbt build (build.sbt), composer.json, package.json, a Dart pubspec.yaml, an Elixir mix.exs/mix.lock (Hex), a rebar.config / erlang.mk DEPS (Hex), a Ruby Gemfile/Gemfile.lock or .gemspec (Bundler/RubyGems) — not scanned yet).
- D7 Architectural Integrity — no checkable ADRs and no dependency cycles — architectural integrity not assessed
- D8 Code Coverage — Coverage not measured — analyzer environment
- DM3 Integration-event coupling — no integration events detected — coupling check not applicable
- ES1 Event Sourcing — not scored — this repository shows none of the 3 signals this lens looks for
- P12 CI test-gate honesty — no CI workflow found
- P7 Outbound HTTP resilience — no outbound HTTP usage detected — no HttpClient/IHttpClientFactory/AddHttpClient in source, and no Refit/RestSharp/Flurl.Http namespace or package reference
- P9 Domain vs controller coverage — no coverage report found on disk — produce a coverage report in a standard format (Cobertura — `dotnet test --collect:"XPlat Code Coverage"` with a `coverlet.collector` PackageReference) and commit it — a hosted scan measures a clone of the repository, so a report that exists only in a working tree, a CI runner's or your own, never reaches it; the artefact is commonly gitignored, so `git add -f` that one file (or un-ignore its path) and commit it alongside the code it measures, or wire coverage collection into CI, to enable this cross-layer check
- PF1 Benchmark discipline — Performance is assessed only for perf-relevant repos — a packaged library, one that ships benchmarks, or one already using allocation-aware APIs. This repo isn't one, so the Performance lens is not applicable and is excluded from the score.
- PF2 Allocation hygiene — Performance is assessed only for perf-relevant repos — a packaged library, one that ships benchmarks, or one already using allocation-aware APIs. This repo isn't one, so the Performance lens is not applicable and is excluded from the score.
- X10 Duplicated predicate — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X6 Hand-rolled structured-format parsing — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
- X9 Subsumed condition operand — Advisory — this card reports evidence and never carries a score, so there is nothing missing here.
Appendix A — Findings (grouped)
Critical — 16 finding(s)
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Aggregate holds a reference to another aggregate: Book.BookLoans CleanArchitectureExample.Domain/Entities/Book.cs:34
- Aggregate holds a reference to another aggregate: BookLoan.Book CleanArchitectureExample.Domain/Entities/BookLoan.cs:26
- Aggregate holds a reference to another aggregate: BookLoan.Taker CleanArchitectureExample.Domain/Entities/BookLoan.cs:27
- Aggregate holds a reference to another aggregate: Person.BookLoans CleanArchitectureExample.Domain/Entities/Person.cs:37
- REDACTED
- REDACTED
- Domain depends on infrastructure: HttpContextServiceProviderProxy CleanArchitectureExample.Application/DomainNotifications/HttpContextServiceProviderProxy.cs:11
- Domain depends on infrastructure: HttpContextServiceProviderProxy CleanArchitectureExample.Application/DomainNotifications/HttpContextServiceProviderProxy.cs:13
- Vulnerable: AutoMapper
- WriteOnlyPrivateField CleanArchitectureExample.Service/Communication/SmsServices.cs:12
Serious — 83 finding(s)
- Async method without CancellationToken: AddAuthor CleanArchitectureExample.Persistence/Repositories/AuthorRepository.cs:18
- Async method without CancellationToken: GetAllAuthors CleanArchitectureExample.Persistence/Repositories/AuthorRepository.cs:24
- Async method without CancellationToken: GetAuthorById CleanArchitectureExample.Persistence/Repositories/AuthorRepository.cs:29
- Async method without CancellationToken: Add CleanArchitectureExample.Persistence/Repositories/BookLoanRepository.cs:17
- Async method without CancellationToken: GetByLoanId CleanArchitectureExample.Persistence/Repositories/BookLoanRepository.cs:23
- Async method without CancellationToken: AddBook CleanArchitectureExample.Persistence/Repositories/BookRepository.cs:18
- Async method without CancellationToken: GetAllBook CleanArchitectureExample.Persistence/Repositories/BookRepository.cs:24
- Async method without CancellationToken: GetBookByISBN CleanArchitectureExample.Persistence/Repositories/BookRepository.cs:29
- Async method without CancellationToken: GetById CleanArchitectureExample.Persistence/Repositories/BookRepository.cs:34
- Async method without CancellationToken: GetByTitle CleanArchitectureExample.Persistence/Repositories/BookRepository.cs:39
- Async method without CancellationToken: AddPerson CleanArchitectureExample.Persistence/Repositories/PersonRepository.cs:17
- Async method without CancellationToken: GetAll CleanArchitectureExample.Persistence/Repositories/PersonRepository.cs:23
- Async method without CancellationToken: GetByDocument CleanArchitectureExample.Persistence/Repositories/PersonRepository.cs:28
- Async method without CancellationToken: GetAll CleanArchitectureExample.Persistence/Repositories/ReadOnlyRepository/BookLoanReadOnlyRepository.cs:20
- Async method without CancellationToken: Commit CleanArchitectureExample.Persistence/UnitOfWork/UnitOfWork.cs:16
- Async method without CancellationToken: FireAfterCommitEvents CleanArchitectureExample.Application/Events/EventDispatcher.cs:33
- Async method without CancellationToken: FirePreCommitEvents CleanArchitectureExample.Application/Events/EventDispatcher.cs:39
- Async method without CancellationToken: SendCommand CleanArchitectureExample.Application/Orchestration/Orchestrator.cs:25
- Async method without CancellationToken: SendQuery CleanArchitectureExample.Application/Orchestration/Orchestrator.cs:68
- Async method without CancellationToken: AddAuthor REDACTED:25
- Async method without CancellationToken: AddBook REDACTED:25
- Async method without CancellationToken: Loan REDACTED:27
- Async method without CancellationToken: ReturnBook REDACTED:35
- Async method without CancellationToken: GetAllLoans REDACTED:43
- Async method without CancellationToken: AddPerson REDACTED:26
- Dead code: FromString CleanArchitectureExample.Domain/Enums/BookSituationEnum.cs:28
- Dead code: FromValue CleanArchitectureExample.Domain/Enums/BookSituationEnum.cs:33
- Dead code: GetPreCommitEvents CleanArchitectureExample.Domain/Interfaces/Events/IEventDispatcher.cs:11
- Dead code: AddPreCommitEvent CleanArchitectureExample.Domain/Interfaces/Events/IEventDispatcher.cs:12
- Dead code: RemovePreCommitEvent CleanArchitectureExample.Domain/Interfaces/Events/IEventDispatcher.cs:13
- Dead code: GetAfterCommitEvents CleanArchitectureExample.Domain/Interfaces/Events/IEventDispatcher.cs:17
- Dead code: RemoveAfterCommitEvent CleanArchitectureExample.Domain/Interfaces/Events/IEventDispatcher.cs:19
- Dead code: GetAllAuthors CleanArchitectureExample.Domain/Interfaces/Persistence/Repositories/IAuthorRepository.cs:12
- Dead code: GetBookByISBN CleanArchitectureExample.Domain/Interfaces/Persistence/Repositories/IBookRepository.cs:12
- Dead code: GetAllBook CleanArchitectureExample.Domain/Interfaces/Persistence/Repositories/IBookRepository.cs:13
- Dead code: GetByTitle CleanArchitectureExample.Domain/Interfaces/Persistence/Repositories/IBookRepository.cs:14
- Dead code: CleanNotifications CleanArchitectureExample.Domain.Core/DomainNotification/IDomainNotifications.cs:12
- Dead code: IsLowerThan CleanArchitectureExample.Domain.Core/Validators/AssertionsConcern.cs:67
- Dead code: IsLowerThan CleanArchitectureExample.Domain.Core/Validators/AssertionsConcern.cs:125
- Dead code: IsLowerThan CleanArchitectureExample.Domain.Core/Validators/AssertionsConcern.cs:181
- Deprecated: Microsoft.EntityFrameworkCore REDACTED:8
- Deprecated: Microsoft.EntityFrameworkCore.Relational REDACTED:9
- Deprecated: Microsoft.EntityFrameworkCore.SqlServer REDACTED:10
- Deprecated: Microsoft.EntityFrameworkCore.Tools REDACTED:11
- Deprecated: Microsoft.AspNetCore.Http.Abstractions REDACTED:10
- Deprecated: Microsoft.AspNetCore.Mvc.NewtonsoftJson REDACTED:8
- Deprecated: Microsoft.EntityFrameworkCore.Design REDACTED:9
- Deprecated: Microsoft.AspNetCore.Mvc.Testing REDACTED:11
- Deprecated: Microsoft.EntityFrameworkCore.InMemory REDACTED:12
- Deprecated: xunit REDACTED:16
- No authorization
- No authorization REDACTED:25
- No authorization REDACTED:18
- No authorization REDACTED:25
- No authorization REDACTED:27
- No authorization REDACTED:35
- No authorization REDACTED:43
- No authorization REDACTED:26
- No authorization REDACTED:34
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- REDACTED
- Constructible in an invalid state: Book CleanArchitectureExample.Domain/Entities/Book.cs:14
- Constructible in an invalid state: Person CleanArchitectureExample.Domain/Entities/Person.cs:18
- Domain type reads the wall clock: Book CleanArchitectureExample.Domain/Entities/Book.cs:37
- Domain type reads the wall clock: BookLoan CleanArchitectureExample.Domain/Entities/BookLoan.cs:36
- No data-protection/encryption
- Duplicated block (11 lines × 2) CleanArchitectureExample.Persistence/Context/ApplicationDbContext.cs:24
- End-of-life runtime: .NET net5.0 REDACTED:4
- Fake-async — async method never awaits REDACTED:18
- No CI pipeline
- No structured logging
- NuGet dependencies are not locked
Minor — 44 finding(s)
- Outdated: Microsoft.EntityFrameworkCore REDACTED:8
- Outdated: Microsoft.EntityFrameworkCore.Relational REDACTED:9
- Outdated: Microsoft.EntityFrameworkCore.SqlServer REDACTED:10
- Outdated: Microsoft.EntityFrameworkCore.Tools REDACTED:11
- Outdated: AutoMapper REDACTED:8
- Outdated: AutoMapper.Extensions.Microsoft.DependencyInjection CleanArchitectureExample.CrossCutting/CleanArchitectureExample.CrossCutting.csproj:8
- Outdated: Microsoft.AspNetCore.Mvc.NewtonsoftJson REDACTED:8
- Outdated: Microsoft.EntityFrameworkCore.Design REDACTED:9
- Outdated: Microsoft.VisualStudio.Web.CodeGeneration.Design REDACTED:13
- Outdated: MediatR CleanArchitectureExample.Domain.Core/CleanArchitectureExample.Domain.Core.csproj:8
- Outdated: coverlet.collector REDACTED:21
- Outdated: FluentAssertions REDACTED:10
- Outdated: Microsoft.AspNetCore.Mvc.Testing REDACTED:11
- Outdated: Microsoft.EntityFrameworkCore.InMemory REDACTED:12
- Primitive id on a domain type: Book.BookId CleanArchitectureExample.Domain/Entities/Book.cs:24
- Primitive id on a domain type: Book.AuthorId CleanArchitectureExample.Domain/Entities/Book.cs:29
- Primitive id on a domain type: BookLoan.BookLoanId CleanArchitectureExample.Domain/Entities/BookLoan.cs:18
- Primitive id on a domain type: BookLoan.BookId CleanArchitectureExample.Domain/Entities/BookLoan.cs:19
- Primitive id on a domain type: BookLoan.TakerId CleanArchitectureExample.Domain/Entities/BookLoan.cs:20
- Primitive id on a domain type: Person.PersonId CleanArchitectureExample.Domain/Entities/Person.cs:30
- Documentation: no project overview README.md
- Documentation: no installation or build instructions README.md
- Documentation: no usage examples README.md
- Mutable entity: Book CleanArchitectureExample.Domain/Entities/Book.cs:10
- Mutable entity: Person CleanArchitectureExample.Domain/Entities/Person.cs:11
- No security response headers detected
- No security response headers detected CleanArchitectureExample.WebAPI/Program.cs:20
- No app-layer HTTPS enforcement detected
- No app-layer HTTPS enforcement detected CleanArchitectureExample.WebAPI/Program.cs:20
- Silent fallback default in catch CleanArchitectureExample.Domain/Enums/BookSituationEnum.cs:59
- Silent fallback default in catch CleanArchitectureExample.Persistence/UnitOfWork/UnitOfWork.cs:23
- No ADRs found
- The event class is named 'LoanEffetivatedEvent' (containing a typo for 'Activated'). The handler classes are named 'LoanEffetivatedEventSendSms' and 'LoanEffetivatedEventSendMail', inheriting the typo and using a non-standard suffix pattern for handlers (typically 'Handler' or 'NotificationHandler').
- The field '_orquestrator' in BookController contains a typo ('orquestrator' instead of 'orchestrator'). While the type is correctly named 'Orchestrator', the field name is misspelled, creating an inconsistency with the correct spelling used elsewhere (e.g., in comments or other potential usages) and the type name itself.
- The field 'retryPolice' in EmailServices is a typo for 'retryPolicy'. This is a spelling inconsistency within the same class.
- The method 'ValidateBookNotNul' contains a typo ('Nul' instead of 'Null'). Other validation methods in the same class use correct spelling ('ValidateBookGuid', 'ValidateBookLoanExists').
- Primitive data clump: [message, value1, value2] CleanArchitectureExample.Domain.Core/Validators/AssertionsConcern.cs:26
- Commented-out code CleanArchitectureExample.WebAPI/Startup.cs:34
- No ADRs
- No architecture diagram/doc
- No src/ separation
- No SAST
- Not all async methods take a CancellationToken
- Nullable reference types not enabled everywhere
Minor — 16 finding(s)
- Outdated: MediatR.Extensions.Microsoft.DependencyInjection
- Outdated: Microsoft.AspNetCore.Http.Abstractions
- Outdated: Polly
- Outdated: Microsoft.NET.Test.Sdk
- Outdated: Moq
- Outdated: Moq.AutoMock
- Outdated: xunit
- Outdated: xunit.runner.visualstudio
- XML-doc coverage: CleanArchitectureExample.Domain CleanArchitectureExample.Domain/CleanArchitectureExample.Domain.csproj
- XML-doc coverage: CleanArchitectureExample.Persistence REDACTED
- XML-doc coverage: CleanArchitectureExample.Application REDACTED
- XML-doc coverage: CleanArchitectureExample.CrossCutting CleanArchitectureExample.CrossCutting/CleanArchitectureExample.CrossCutting.csproj
- XML-doc coverage: CleanArchitectureExample.WebAPI REDACTED
- XML-doc coverage: CleanArchitectureExample.Service CleanArchitectureExample.Service/CleanArchitectureExample.Service.csproj
- XML-doc coverage: CleanArchitectureExample.Domain.Core CleanArchitectureExample.Domain.Core/CleanArchitectureExample.Domain.Core.csproj
- Mock framework: Moq
Appendix B — Reproduction & audit trail
| Dimension | Tool | Version | Command | Findings | Raw output |
|---|---|---|---|---|---|
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-1474a03daf514b4097f61dad8a69223f/history.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-history.json |
| D28 · Secrets (history) | gitleaks | — | gitleaks detect --no-git --no-banner --config /opt/gitleaks-rules/watchdog-gitleaks.toml --report-format json --report-path /tmp/watchdog-gitleaks-1474a03daf514b4097f61dad8a69223f/tree.json --exit-code 0 --source . | 0 | artifacts/raw/gitleaks-tree.json |
| D29 · Static Analysis (SAST) | semgrep | — | semgrep --config /opt/semgrep-rules/security-audit.yml --config /opt/semgrep-rules/owasp-top-ten.yml --config /opt/semgrep-rules/watchdog-sast.yml --json --quiet --timeout 10 --timeout-threshold 3 --metrics off . | 8 | artifacts/raw/semgrep.json |
| D30 · Dependency Vulnerabilities | dotnet | — | dotnet list CleanArchitectureExample.sln package --vulnerable --include-transitive --format json | 10 | artifacts/raw/dotnet-vulnerable.json |
| D31 · IaC & Container Security | trivy | — | trivy: not applicable — No Infrastructure-as-Code or container manifests found (Dockerfile, Docker Compose, Terraform, Kubernetes/Helm, CloudFormation, ARM, Bicep, Ansible); nothing to scan. | 0 | — |
| D32 · Data Compliance (PII/GDPR) | semgrep | — | semgrep: not applicable — No personal data was found crossing a boundary the PII/GDPR ruleset checks — nothing written to a log or console sink, placed in a URL or query string, or persisted to browser storage. That is a clean result for the LEAK surface only: this ruleset detects personal data escaping, it does not inventory the personal data a repository holds, so it is not evidence that this repository has no personal-data surface. The personal-data map (Appendix C) and the C1-C5 compliance cards are what speak to that. | 0 | — |
| D36 · Supply-chain Provenance & Signing | provenance | — | provenance: not applicable — No CI/build pipeline found (.github/.forgejo/.gitea workflows, .circleci, .buildkite, .woodpecker, .teamcity, .gitlab-ci.yml, .travis.yml, bitbucket-pipelines.yml, .drone.yml, .cirrus.yml, .woodpecker.yml, appveyor.yml, azure-pipelines*.yml, .pipelines/, .vsts-ci/, .azuredevops/, Jenkinsfile); there is no build to attest provenance for. | 0 | — |
| D37 · Vulnerability-disclosure Policy | disclosure | — | disclosure: not applicable — No vulnerability-disclosure policy file found (SECURITY.md/.markdown/.rst/.txt at root or under .github/.forgejo/.gitea/docs, .well-known/security.txt). A coordinated-disclosure policy may live off-repo, so this is not evidenced rather than failed. | 0 | — |
| D40 · Network Egress Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; network egress policy is a cluster-native control that may live at the platform/firewall layer, so there is nothing to assess here. | 0 | — |
| D41 · Kernel & Syscall Confinement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; seccomp/AppArmor/SELinux confinement is a workload-level control, so there is nothing to assess here. | 0 | — |
| D42 · Runtime Threat Enforcement | runtime-hardening | — | runtime-hardening: not applicable — No Kubernetes/orchestration workloads found in the repository manifests; runtime threat-detection and admission-control policy are cluster-level controls, so there is nothing to assess here. | 0 | — |
| D43 · Malicious Dependencies | none (no readable dependency manifest) | — | none (no readable dependency manifest): not applicable — Not scored — no dependency manifest in a supported ecosystem was read for this repository. A gap in the analyzer's language coverage, NOT a finding that the repository is free of vulnerable dependencies (a Python pyproject.toml/requirements.txt (pip/uv/Poetry), a Swift Package.swift/Package.resolved, a Cargo manifest, a Go module (go.mod/go.sum), a Gradle version catalogue, a Maven POM, an sbt build (build.sbt), composer.json, package.json, a Dart pubspec.yaml, an Elixir mix.exs/mix.lock (Hex), a rebar.config / erlang.mk DEPS (Hex), a Ruby Gemfile/Gemfile.lock or .gemspec (Bundler/RubyGems) — not scanned yet). | 0 | — |
Appendix C — Personal-data map
Phone — 10 field(s)
- Person.PhoneNumbers CleanArchitectureExample.Domain/Entities/Person.cs:36
- PersonPhone.PersonPhoneId CleanArchitectureExample.Domain/Entities/PersonPhone.cs:21
- PersonPhone.PhoneNumber CleanArchitectureExample.Domain/Entities/PersonPhone.cs:22
- LoanEffetivatedEvent.Phone CleanArchitectureExample.Domain/RequestHandlers/BookLoanHandlers/Commands/RequestLoan/Events/LoanEffetivatedEvent.cs:18
- AddPersonCommand.Phones CleanArchitectureExample.Domain/RequestHandlers/PersonHandlers/Commands/AddPerson/AddPersonCommand.cs:20
- AddPersonCommandResponseViewModel.PhoneNumbers CleanArchitectureExample.Domain/RequestHandlers/PersonHandlers/Commands/AddPerson/AddPersonCommandResponseViewModel.cs:12
- AddPersonCommandResultViewModelPhones.PhoneId CleanArchitectureExample.Domain/RequestHandlers/PersonHandlers/Commands/AddPerson/AddPersonCommandResponseViewModel.cs:17
- AddPersonCommandResultViewModelPhones.PhoneNumber CleanArchitectureExample.Domain/RequestHandlers/PersonHandlers/Commands/AddPerson/AddPersonCommandResponseViewModel.cs:18
- ApplicationDbContext.PersonPhone CleanArchitectureExample.Persistence/Context/ApplicationDbContext.cs:12
- ApplicationDbContextReadOnly.PersonPhone CleanArchitectureExample.Persistence/Context/ApplicationDbContextReadOnly.cs:13
Email — 3 field(s)
- Person.Email CleanArchitectureExample.Domain/Entities/Person.cs:33
- LoanEffetivatedEvent.Email CleanArchitectureExample.Domain/RequestHandlers/BookLoanHandlers/Commands/RequestLoan/Events/LoanEffetivatedEvent.cs:20
- AddPersonCommand.Email CleanArchitectureExample.Domain/RequestHandlers/PersonHandlers/Commands/AddPerson/AddPersonCommand.cs:21