Domain-Driven Design
DDD is a way to keep the language of the business inside the code. It is not a catalog of tactical patterns to sprinkle on a CRUD app.
Personal experience
Ecommerce (Armirene, Kooomo, Zerogrey) and a private ERP (Soga / ProCrédito v2) are domains where language already exists in the business. Obligation processing is a bounded context: Laravel owns the aggregate; Python workers transform files and streams without becoming the domain.
Technical perspective
Start with bounded contexts, not with aggregates. If “order” means three different things to sales, warehouse, and finance, you do not have one model with extra fields. You have three models sharing a word.
Tactical patterns — entities, value objects, domain events — are useful after the context map is honest. Applied first, they produce ceremony around a single database.
The domain layer should not import the web framework, the ORM, or the broker. That is not purity for its own sake. It is how you keep a model testable when the infrastructure changes, which it will.