codemountains/axum-ddd-explicit-architecture

This system is a Rust-based web application for managing a todo list, featuring full CRUD operations and status tracking. It provides an API with versioned endpoints and structured error handling, backed by a PostgreSQL database that supports Japanese locale. The architecture includes a containerized development environment and a layered design separating the kernel, adapters, and use cases.

The project now includes a Dockerfile and docker-compose.yaml to containerize the Rust application and a PostgreSQL 16 database. Users can start the entire stack with \docker-compose up\, which handles building the Rust image, running the database, and managing volumes. The configuration also introduces a \docker-app.env\ file for containerized environment variables and updates the README with instructions for running migrations and the application within the container.

(repo-wide) · high confidence

The application now supports creating, reading, updating, and deleting todos. The \TodoRepository\ interface has been extended with \find\, \insert\, \update\, \upsert\, and \delete\ methods, and a new \TodoStatusRepository\ has been introduced to manage todo statuses. The \TodoUseCase\ now exposes \find\_todo\, \register\_todo\, \update\_todo\, \upsert\_todo\, and \delete\_todo\ methods, enabling users to manage their todo list items.

todo-app/src/usecase, todo-kernel/src/repository · high confidence

The todo-adapter now tracks a status for each todo item, introducing a new \TodoStatus\ model and repository to manage status codes and names. The \TodoRepository\ has been expanded to support filtering by status, sorting results by creation date, and performing insert, update, and upsert operations that include status information. This enables users to view, search, and manage todos with their current status.

todo-adapter · high confidence

The database service is now containerized via a new Dockerfile that runs PostgreSQL 16-alpine with Japanese locale support. Additionally, new SQL files have been introduced: check.sql provides a query to inspect table constraints for the 'todos' table, and sample.sql inserts initial test data into the 'todos' table.

database · high confidence

The Todo model now includes a status field, supported by a new TodoStatus struct that tracks an ID, code, and name. Additionally, the model introduces NewTodo, UpdateTodo, and UpsertTodo structs to handle creating, updating, and upserting todo items with optional fields for title, description, and status.

todo-kernel/src/model · medium confidence

The Todo API now requires an explicit version parameter (e.g., /v1/todos) to access endpoints, replacing the previous implicit routing. All Todo operations (create, read, update, delete, search) now return structured JSON error responses with specific error codes and messages, providing clearer feedback for validation and server errors.

todo-driver · high confidence

The database schema has been updated to include a new 'todo\_statuses' table that defines various states for todos (such as 'new', 'working', 'done', etc.). The 'todos' table now includes a 'status\_id' column that references this new table, allowing each todo to be associated with a specific status. This change replaces the previous simpler schema where todos did not have an explicit status field.

migrations · high confidence

The Todo model now includes a new TodoStatusView struct and a status field in TodoView, enabling users to track and update todo statuses. Additionally, new structs (CreateTodo, UpdateTodoView, UpsertTodoView, SearchTodoCondition) support creating, updating, upserting, and searching todos with status codes.

todo-app/src/model · medium confidence

The project updates several Rust dependencies to newer versions, including anyhow (1.0.58→1.0.86), async-trait (0.1.56→0.1.80), chrono (0.4.22→0.4.38), serde (1.0.140→1.0.203), sqlx (0.6.2→0.7.4), tokio (1.20.0→1.38.0), axum (0.5.13→0.7.5), http-body (0.4.5→1.0.0), tracing (0.1.35→0.1.40), tracing-subscriber (0.3.15→0.3.18), tower-http (0.3.4→0.5.2), thiserror (1.0.35→1.0.61), and validator (0.16.0→0.18.1). Additionally, the Cargo workspace is configured to use resolver version 2.

(dependencies) · medium confidence

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

• CAI 51 → 49 (-1.7)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 99 (-0.6)
• Architecture 100 → 88 (-12.2)
• Maturity 50 → 50 (+0.0)
• Readiness 21 → 21 (+0.0)
• Security 98 → 98 (-0.4)
• Domain Modelling 100 → 100 (+0.0)

• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• Medium IaC: CKV_DOCKER_3 (Dockerfile)
• Medium IaC: CKV_DOCKER_3 (database/Dockerfile)
• No exposed public API
• The main README describes Clean Architecture workspaces but does not explain what each workspace represents (e.g., driver vs app layer) or how they interact, leaving a gap for someone new to the project. (README.md)
• single-maintainer — knowledge-concentration (bus factor) risk

• DTO duplication with identical signatures. UpdateTodoView and UpsertTodoView have the exact same properties and constructor signatures. In many architectures, an 'Update' (partial) and 'Upsert' (create or update) might differ in required fields (e.g., ID presence), but here they are structurally identical, suggesting redundant types.
• Dependency hygiene PARTLY measured — Cargo dependencies read, no committed lock to grade for currency
• Duplicated block (13 lines × 2) (todo-app/src/usecase/todo.rs)
• Duplicated block (13 lines × 2) (todo-driver/src/routes/todo.rs)
• Duplicated block (7 lines × 2) (todo-driver/src/routes/todo.rs)
• Inconsistent naming for retrieval operations. TodoRepository uses get (generic), while TodoStatusRepository uses get_by_code (specific). This creates confusion about whether get implies fetching by ID or if there is a missing get_by_code for todos.
• Low IaC: DS-0026 (Dockerfile)
• Medium IaC: WD-DOCKER-0003 (Dockerfile)
• Medium IaC: WD-DOCKER-0003 (database/Dockerfile)
• Medium IaC: WD-DOCKER-0004 (Dockerfile)
• No ADRs found
• Semantic mismatch in 'find' operations. The kernel repository find takes a full TodoStatus object (entity), while the use case find_todo takes a SearchTodoCondition (DTO/Filter) containing only a status_code. This forces the use case to perform mapping or the repository to accept a different type than its domain entity, breaking the clean separation of concerns.
• Type mismatch in collection definition. The property todos is named plural but typed as singular JsonTodo. The constructor also takes a single JsonTodo instead of a list/collection. This is likely a typo or incomplete implementation where a list was intended.

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

codemountains/axum-ddd-explicit-architecture 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.