2 ms·
Django has these same limitations in my experience, but to me the issues are largely caused by the common usage patterns which are encouraged by the official do
by skrtskrt 5y ago
Django has these same limitations in my experience, but to me the issues are largely caused by the common usage patterns which are encouraged by the official docs and community, and lead to absurd amounts of coupling/ball-of-mud apps.
you can be disciplined about clean architecture/DDD/hexagonal architecture, etc, but you have completely ignore the patterns encouraged by Django, Django Rest Framework, etc etc.
Hide the ORM behind Repository interfaces
Marshall ORM objects into true Domain objects
Do not call to the database in the HTTP adapter/validators
Etc etc
- tmp_anon_22 5y ago> Hide the ORM behind Repository interfaces > Marshall ORM objects into true Domain objects > Do not call to the database in the HTTP adapter/validators The tradeoff for this is exploding the number of files, directories, and tests, needed for the project. Which has its own cost and overhead.
- berkes 5y agoI'm not experienced in Django. But doing this in Rails is very hard. It goes against the most strongest of opinions this opinionated framework has. So much, that if you strive for such a design (and you should, IMO) Rails is more in the way than helping you - I know, I tried.
- skrtskrt 5y agoSure, writing boilerplate is always going to have overhead. But in my experience the stricter-yet-more-verbose design strongly increases maintainability and velocity in the long term, which should be self-evident due to the massive reduction of coupling.