Back to browse
GitHub Repository

Async DDD framework for microservices on Starlette

5 starsPython

Urich – Async DDD framework for microservices on Starlette

by ElMuncho·Feb 20, 2026·1 point·0 comments

AI Analysis

MidBig BrainNiche Gem

Automates DDD routing and OpenAPI from dataclasses, but Django/FastAPI ecosystem larger.

Strengths
  • Single DomainModule object per bounded context reduces scatter (routers, handlers, config)
  • Protocol-based adapters (Redis, Consul, HTTP) prevent lock-in and enable swapping
  • CLI scaffolding (urich create-app, add-context) lowers DDD learning curve for Python teams
Weaknesses
  • Python DDD frameworks already exist (nameko, dramatiq); unclear why Urich is better than hand-wiring
  • Early project (1 star, 0 forks): no proof of production use or community adoption yet
Target Audience

Python microservices developers adopting DDD/CQRS patterns, Starlette users

Similar To

nameko · FastAPI with manual DDD wiring · Django with CQRS layers

Post Description

I built Urich after getting tired of hand-wiring DDD/CQRS on top of Starlette: routers, command handlers, OpenAPI, and DI scattered everywhere. The idea: one object per bounded context. You define a DomainModule (aggregate, repository, commands, queries, event handlers), call app.register(orders_module), and get routes like POST /orders/commands/create_order and GET /orders/queries/get_order plus OpenAPI from your dataclasses. Event bus, discovery, and RPC are separate modules; you plug in your adapters (Redis, Consul, etc.) or use in-memory defaults. Core stays small and protocol-based so you’re not locked in. Python 3.12+, Starlette, Pydantic. CLI for scaffolding (urich create-app, add-context, add-aggregate). Docs and an ecommerce example are in the repo. Would love feedback from anyone building microservices with DDD/CQRS — what’s missing, what would break in your setup, or what you’d want next (e.g. more adapters, patterns).

Similar Projects