4👍
Short answer: DRF and DDD+Hexagonal architecture are not the best friends.
When the model reflects the domain (the subject, problem at hand) it’s most likely in the antipodes of CRUD. Create, Read, Update, Delete are actions that will not always be part of your ubiquitous language.
Moreover, Onion/Hexagonal Architecture would require that the model does not depend on any framework or library code. To invert these dependencies and make the persistence and the delivery mechanism depend on your model instead is possible (not using any Django import inside your domain), but certainly uphill with Django. The framework is prescribing the opposite to all this.
1👍
The idea of DDD is more about seperation of concerns. Seperating the logic from framework functionality is crucial, this is the case in any framework. if you you use persistance/ORM stuff from django that is fine but don’t mix it up with your domain logic, always keep it seperate. The logic should also work with a different ORM. There should always be some kind of layer in between.
- Django – links generated with {% url %} – how to make them secure?
- Django – Objects for business hours
- ProgrammingError: column "product" is of type product[] but expression is of type text[] enum postgres
- How to delete user in django?