Skip to content
CAI
Software that uses CAICheck a score

Peopl3s/clean-architecture-fastapi-project-template

62.6

Adequate · 22 September 2026

3.1k

lines of production code

Python

primary language

7

measurements over time

CAI band scale
CAI trend line
CAI lens gauges

What this system is

This system is a Python-based web service template for managing museum artifacts, built on FastAPI with a clean architecture. It handles the full lifecycle of artifact data: fetching from external APIs or caches, processing through granular use cases, and publishing to message brokers and public catalogs. The application enforces strict domain invariants, manages state via database and cache repositories, and exposes a REST API for artifact retrieval.

Features

Add database, cache, and messaging infrastructure implementations

Added infrastructure components for persistence, caching, and messaging: a SQLAlchemy-based \ArtifactRepository\ and \UnitOfWork\ with mappers and exceptions; a \RedisCacheClient\ implementing \CacheProtocol\; a \KafkaPublisher\ for sending artifact admission notifications; and an \InfrastructureArtifactMapper\ for serializing DTOs. These files establish the concrete implementations for the application's data and messaging layers.

_{{cookiecutter.project\_slug}}{{cookiecutter.project\slug}}/infrastructures · high confidence

Added database initialization and migration scripts

Added shell and SQL scripts to automate the setup of the application's database. For PostgreSQL, the new init-db.sh script handles connection, database creation, and extension setup, while init-db.sql provides the corresponding SQL. For MySQL, init-mysql.sql creates the database and user. For SQLite, init-sqlite.sh creates the database file and initial metadata. Additionally, migrate.sh is provided to run Alembic migrations, and setup-env.sh copies the environment template.

_{{cookiecutter.project\slug}}/scripts · high confidence

Automatic .env file generation during project initialization

A new post-generation hook (post\_gen\_project.py) has been added to the hooks directory. This script automatically generates a .env configuration file when a new project is created, pre-filling database, cache, and broker connection strings based on the user's template selections. This removes the need for manual environment variable setup at the start of a new project.

hooks · high confidence

Initial project scaffolding and configuration files

The project now includes essential configuration and documentation files to support development and deployment. A \.cookiecutterignore\ file prevents build artifacts and IDE files from being tracked. An \.editorconfig\ enforces consistent coding styles across Python, Markdown, and configuration files. A comprehensive \.gitignore\ excludes common build, cache, and environment files. Documentation is structured with a \docs/\ directory containing Sphinx configuration, a \doc/requirements.txt\ for building docs, and a \.readthedocs.yaml\ for automated deployment to Read the Docs. Additionally, \renovate.json\ is added to automate dependency updates via RenovateBot, and \cookiecutter.json\ defines the template variables for project generation.

(repo-wide) · high confidence

Introduce Artifact Data Transfer Objects

Added new Data Transfer Objects (DTOs) for the Artifact domain, including ArtifactDTO, ArtifactAdmissionNotificationDTO, and ArtifactCatalogPublicationDTO, along with supporting enums for Material and Era. These classes define the structure for transferring artifact data between application layers, with specific fields for inventory tracking, acquisition details, and catalog publication.

_{{cookiecutter.project\_slug}}{{cookiecutter.project\slug}}/application/dtos · high confidence

Introduce REST API for retrieving artifact details

The presentation layer now exposes a new REST endpoint at /v1/artifacts/{inventory\_id} to fetch artifact data. This includes a dedicated error handling module that maps internal exceptions (such as ArtifactNotFoundError and DomainValidationError) to appropriate HTTP status codes (404, 400, 500) with JSON error messages. The endpoint utilizes a new ArtifactPresentationMapper to convert application DTOs into response schemas, ensuring a clean separation between the application and presentation layers.

_{{cookiecutter.project\_slug}}{{cookiecutter.project\slug}}/presentation · high confidence

Introduce domain entities and value objects for artifact management

Added new domain-layer components to support artifact data modeling. This includes the \ArtifactEntity\ which enforces business invariants such as date constraints and name/department length limits, along with \Era\ and \Material\ value objects that restrict inputs to predefined historical periods and material types. Supporting infrastructure includes \DomainValidationError\ and specific exception classes for invalid eras and materials.

_{{cookiecutter.project\_slug}}{{cookiecutter.project\slug}}/domain · high confidence

Introduce structured dependency injection with Dishka providers

The application now uses the Dishka library for dependency injection, replacing the previous ad-hoc or manual wiring. A new \di.py\ module collects all providers, while \providers.py\ defines individual provider classes for settings, database sessions, HTTP clients, message brokers, repositories, and use cases. This ensures consistent lifecycle management (e.g., closing HTTP clients, disposing database engines) and explicit scope definitions (APP vs REQUEST) for all injected dependencies.

_{{cookiecutter.project\_slug}}{{cookiecutter.project\slug}}/config/ioc · high confidence

Introduced application-layer interfaces and mappers for artifact management

Added a suite of abstract base classes and protocols that define the application's internal contracts. This includes exception classes for error handling, protocols for caching, database mapping, HTTP clients, message broker publishing, repository access, serialization, and unit of work management. Additionally, a concrete implementation of the DtoEntityMapperProtocol was added to handle conversions between domain entities and application DTOs.

_{{cookiecutter.project\_slug}}{{cookiecutter.project\slug}}/application/interfaces · high confidence

Project scaffolding and build configuration

The template now includes a comprehensive set of build and development configuration files. A multi-stage Dockerfile is added to support production, development, and testing environments, each with distinct entry points and dependencies. A Makefile is introduced to standardize common tasks such as linting, formatting, type-checking, testing, and database migrations. Additionally, a .pre-commit-config.yaml file is added to enforce code quality with hooks for trailing whitespace, AST checks, gitlint, ruff, and mypy. The project also includes .dockerignore and .gitignore files to manage build artifacts and environment files, alongside a .git-commit-template to standardize commit messages. The README.md is updated to reflect the new structure and available commands.

_{{cookiecutter.project\slug}} · high confidence

Behavioural changes

Configuration settings refactored into modular Pydantic models

The application's configuration has been restructured from a single monolithic settings object into distinct, modular Pydantic \BaseSettings\ classes (e.g., \AppSettings\, \DatabaseSettings\, \RedisSettings\). Each domain now has its own configuration file, while a central \Settings\ class aggregates them and provides backward-compatible properties for existing code. Additionally, the logging system has been updated to use \structlog\ for structured logging.

_{{cookiecutter.project\_slug}}{{cookiecutter.project\slug}}/config · high confidence

Introduce FastAPI application entry point with structured logging and dependency injection

The application now uses FastAPI as its web framework, initialized via a new \main.py\ entry point. This change introduces \structlog\ for structured logging, integrates the \dishka\ library for dependency injection, and configures CORS middleware. The application lifecycle is managed through a lifespan context manager that logs startup and shutdown events.

_{{cookiecutter.project\_slug}}{{cookiecutter.project\slug}} · medium confidence

Introduce granular use cases for artifact processing and data retrieval

The application layer now features a set of specialized use cases that replace a previous monolithic approach. These include fetching artifacts from the external museum API, retrieving them from the cache or repository, and saving them back to the cache or repository. Additionally, new use cases handle publishing artifacts to the message broker and the public catalog. The main ProcessArtifact use case orchestrates this flow, ensuring artifacts are fetched from the most efficient source and subsequently persisted and published.

_{{cookiecutter.project\_slug}}{{cookiecutter.project\_slug}}/application/use\cases · high confidence

Test coverage

Initial test suite for artifact processing and domain entities

Added comprehensive tests for the \ProcessArtifactUseCase\, covering scenarios where artifacts are found in cache, repository, or external APIs, as well as error handling for missing artifacts and failed publishing. Included unit tests for \ArtifactEntity\ and \Era\ value objects, plus integration tests for the API controller and endpoints. Test infrastructure includes \conftest.py\ with fixtures for database sessions, DI containers, and mock clients, alongside factory classes for generating test data using \polyfactory\ and \faker\.

_{{cookiecutter.project\slug}}/tests · high confidence

Dependencies

Updated Python dependencies and added docs requirements

The project's Python dependencies have been updated to their latest specified versions, including FastAPI 0.121.0, Pydantic 2.12.4, Redis 7.0.1, and others as defined in the template's pyproject.toml. Additionally, a new docs/requirements.txt file has been added to manage Sphinx and related documentation tooling dependencies.

(dependencies) · medium confidence

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

How this codebase got here

Score

  • CAI 62 → 63 (+1.1)
  • Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

Lenses

  • Code Health 99 (new)
  • Architecture 100 → 82 (-18.1)
  • Maturity 69 → 74 (+4.7)
  • Readiness 39 → 42 (+2.5)
  • Security 100 → 96 (-4.1)

Resolved (7)

  • Coverage not included — suite not readable by the collector
  • Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
  • No exposed public API
  • Off-boarding risk: anonymized user #1
  • Test reliability not included
  • The documentation structure diagram lists only index.rst as the main page; the outline requires pages like 'Getting Started', 'User Guide', and 'Testing'. (docs/README.md)
  • complexity unreadable for .py — churn × complexity hotspots could not be measured

New (26)

  • Documentation: no architecture or design documentation (docs/reference/environment-variables.rst)
  • Documentation: no installation or build instructions (README.md)
  • Documentation: no installation or build instructions (docs/reference/makefile-commands.rst)
  • High IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • High IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • High IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • High IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • Low IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.override.yml)
  • Medium IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • Medium IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • Medium IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • Medium IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • Medium IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • Medium IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • Medium IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • Medium IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • Medium IaC: WD-COMPOSE-0002 ({{cookiecutter.project_slug}}/docker-compose.yml)
  • Medium IaC: WD-DOCKER-0003 ({{cookiecutter.project_slug}}/Dockerfile)
  • Medium IaC: WD-DOCKER-0004 ({{cookiecutter.project_slug}}/Dockerfile)
  • Outdated: alembic
  • …and 6 more

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

Survey your own repository

Peopl3s/clean-architecture-fastapi-project-template 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.

About this page

  • The score is its most recent published measurement, taken on 22 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
  • Measured at commit 66c6eea5ce7c17ffef7b6df5bfe46e9fe966b579 — the exact code this score is about.
  • Scored under rubric-2026.09.15 — the same rubric and the same method as every other entry in this index.
  • Measured by watchdog.canine.dev using codehealth-analyzer preprod-821afab8930d.