Who Protean is for

The same framework, spoken to the reader who needs it.

Domain-driven design in Python, without hand-rolling it.

You know aggregates, value objects, and bounded contexts. In Python you have been building them by hand, or envying what Axon gives Java and Marten gives .NET. Protean is that framework, for Python, open source, with the server included.

Give your backend a domain layer.

The app started clean. Then the business logic spread across services, utilities, and route handlers, and now nobody can find where a rule lives. Protean gives you a domain layer that keeps the rules in one place and grows without a rewrite.

One model, and everything derived from it stays in step.

Keeping the model, the API spec, the docs, and the infrastructure in agreement across many teams is a losing battle when each one is maintained by hand. Protean captures the model as data and derives the rest, so there is one source of truth to govern.

Make AI-generated backend code hold together.

A general-purpose model generates plausible Python, and plausible is the problem: it hands you an aggregate that breaks the single-writer rule, or a handler that mutates two aggregates at once, and nothing catches it. A domain model has rules a framework can check.

Event sourcing in Python, only where you need it.

Event sourcing is powerful, and it is usually sold as all-or-nothing, which makes it hard to adopt. Protean lets you turn it on for the one aggregate that needs a full history, and keep the rest as plain models.

Is Protean safe to bet a real project on?

The cost of a framework that turns out wrong is not the first week, it is the years afterward spent unable to move off it. Here is the honest picture: what Protean is for, where it stops, and what you keep control of.