ivanpaulovich/clean-architecture-video-tutorials

This system is a .NET-based wallet application built using Clean and Hexagonal architecture principles. It currently implements core domain and application logic for customer registration, including entity modeling and use case orchestration. The codebase includes unit tests to verify customer creation behavior and relies on .NET Standard 2.0 for its domain and application layers.

This change introduces the core domain model and application layer for registering new customers. It adds a \Customer\ entity in the domain layer that generates a unique ID upon creation, and defines a \CustomerResult\ DTO for returning customer details. The application layer exposes an \IRegisterCustomerUseCase\ interface and its implementation, \RegisterCustomerUseCase\, which orchestrates the creation of a new customer and returns the resulting data.

images, source/Wallet.Application, source/Wallet.Domain · high confidence

This change introduces the initial \Wallet.sln\ solution file, establishing the project structure with \Wallet.Domain\, \Wallet.Application\, and \Wallet.UnitTests\ projects. It also updates the \README.md\ to reflect the current state of the video tutorial series, including links to Season 01 episodes on account balance service design and Season 02 episodes covering Clean Architecture essentials, validation, and hexagonal architecture styles.

(repo-wide) · high confidence

A change to existing behaviour in source — 2 commits, 1 file.

source · medium confidence · unverified

Added a new test class, CustomerTests, in the Wallet.UnitTests project to verify the behavior of the customer domain and application layer. The tests cover the RegisterCustomerUseCase to ensure it returns a valid customer result with a non-empty ID when provided with valid details, and the Customer entity constructor to confirm it correctly initializes the customer's name and phone number.

tests · high confidence

This change introduces the foundational project structure for the Wallet application, adding the Wallet.Domain and Wallet.Application libraries targeting .NET Standard 2.0, along with a new Wallet.UnitTests project targeting .NET Core 2.1. The test project establishes its dependency stack by adding references to Microsoft.NET.Test.Sdk (15.7.0), xunit (2.3.1), xunit.runner.visualstudio (2.3.1), and the dotnet-xunit CLI tool (2.3.1), while linking to the newly created domain and application projects.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 86 → 77 (-8.7)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 98 → 98 (-0.2)
• Architecture 98 → 98 (+0.0)
• Maturity 80 → 60 (-19.6)
• Readiness 93 → 93 (+0.0)
• Security 87 → 90 (+2.4)

• Coverage not measured — analyzer environment
• High CVE: Microsoft.NETCore.App 2.1.0
• High CVE: Microsoft.NETCore.App 2.1.0
• High CVE: Microsoft.NETCore.App 2.1.0
• High CVE: Microsoft.NETCore.App 2.1.0
• Medium CVE: Microsoft.NETCore.App 2.1.0
• Medium CVE: Microsoft.NETCore.App 2.1.0
• Medium CVE: Microsoft.NETCore.App 2.1.0
• Medium CVE: Microsoft.NETCore.App 2.1.0
• No architecture or application documentation exists; the README is a video-tutorial schedule with no description of the domain model, repositories, services, or wireframe diagrams.
• No exposed public API
• No tests discovered
• The 'Register' method in the interface and implementation takes parameters 'string, string' but the parameter names are 'string, string' in the interface and 'string, string' in the implementation. However, looking at the parameters: 'expectedPhoneNumber' vs 'phoneNumber' and 'name' vs 'expectName'. The parameter names are inconsistent: 'expectedPhoneNumber' vs 'phoneNumber', and 'name' vs 'expectName'.
• The concept of a customer is represented by 'Customer' in the domain and 'CustomerResult' in the application layer. While this might be intentional (DTO vs Entity), the naming 'CustomerResult' is ambiguous and differs significantly from 'Customer', potentially causing confusion about whether they represent the same concept or different ones.
• The interface and its implementation differ in naming: the interface uses 'IRegisterCustomerUseCase' while the implementation uses 'RegisterCustomerUseCase'. While the 'I' prefix for interfaces is a common convention, the inconsistency lies in the fact that the interface name includes the 'I' prefix while the implementation does not, which is consistent with typical C# conventions, but if the codebase strictly avoids 'I' prefixes, this is an inconsistency. However, looking deeper, the parameter names also show inconsistency.
• early-stage repository — too little history to judge knowledge freshness
• git history depth insufficient
• git history depth insufficient
• single-maintainer — knowledge-concentration (bus factor) risk

• Coverage not measured — no coverage collector is wired up
• Documentation: no installation or build instructions (README.md)
• End-of-life runtime: .NET netcoreapp2.1
• High CVE: Microsoft.NETCore.App 2.1.0
• Inconsistent naming for the name parameter. One uses the prefix 'expect' (likely in a test context) while the other uses the base name 'name'. Similar to the phone number issue, this creates a vocabulary split for the same concept.
• Inconsistent naming for the same conceptual parameter in the Register method. One uses the prefix 'expected' (likely in a test or assertion context) while the other uses the base name 'phoneNumber'. While 'expected' is common in test assertions, having both forms for the same logical input (phone number) in the same domain context creates confusion.

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

ivanpaulovich/clean-architecture-video-tutorials was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.