Who Protean is for

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.

AI in production, bounded by rules it cannot break.

A general-purpose model will happily generate an aggregate that breaks the rules, or act in ways the business forbids. A domain model has rules a framework can check and a boundary it enforces, so you can put AI in production and keep control of what it is able to touch.

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.