3 ms·

The author makes an observation that has been growing on me in the last few years; many ORM models really prevent you from using an architecture like this, beca

The author makes an observation that has been growing on me in the last few years; many ORM models really prevent you from using an architecture like this, because your “pure core” actually has to have logic for DB operations like saving/filtering. It’s possible to build a DDD Repository in Django or Rails, but really a lot of work. I think the frameworks like sqlalchemy and NHibernate seem to do things a bit better by tracking “dirty” models, hiding the “ORM-ness”, and letting the higher levels control when to flush/write to the DB. But the more you abstract this stuff, the more you lose the auto generated sugar that makes frameworks like Django so productive.

danuker 6y ago
Absolutely. [Uncle Bob is clear](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a...) that the inside circles must not know about the outside world. That is, your business logic is not allowed to know what a DB operation is, nor should it do any DB operations behind the scenes. > Frameworks and Drivers. > The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards. > This layer is where all the details go. The Web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.
- theptip 6y ago
  The tension I observe is: when should you use a highly productive and well-known framework like Django or Rails, and when should you build your own DDD/Clean architecture? This discussion has gone on for a long time, e.g. see the back-and-forth around https://dhh.dk/2014/test-induced-design-damage.html https://dhh.dk/2014/test-induced-design-damage.html after Weirich demonstrated what sort of thing is required to use the Hexagonal Architecture with Rails. I believe that if your system is sufficiently complex, you'll start to see the benefits of a more structured architecture, but it's a net drag on productivity for small projects. These days perhaps you chop your monolith into microservices before reaching the ROI point for Clean/Hexagonal? I could believe that a "framework-first" architecture is more productive while you have <100kloc. Or maybe it's <10kloc, I don't know. I'm certainly seeing the architectural strain with a Django-first architecture in the current 150kloc monolith I'm working on, and chopping into a few services makes sense there for other reasons, so it might obviate the need for a bigger refactor onto Clean/Hexagonal.

danuker 6y ago

Absolutely. [Uncle Bob is clear](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a...) that the inside circles must not know about the outside world. That is, your business logic is not allowed to know what a DB operation is, nor should it do any DB operations behind the scenes. > Frameworks and Drivers. > The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards. > This layer is where all the details go. The Web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.

theptip 6y ago
The tension I observe is: when should you use a highly productive and well-known framework like Django or Rails, and when should you build your own DDD/Clean architecture? This discussion has gone on for a long time, e.g. see the back-and-forth around https://dhh.dk/2014/test-induced-design-damage.html https://dhh.dk/2014/test-induced-design-damage.html after Weirich demonstrated what sort of thing is required to use the Hexagonal Architecture with Rails. I believe that if your system is sufficiently complex, you'll start to see the benefits of a more structured architecture, but it's a net drag on productivity for small projects. These days perhaps you chop your monolith into microservices before reaching the ROI point for Clean/Hexagonal? I could believe that a "framework-first" architecture is more productive while you have <100kloc. Or maybe it's <10kloc, I don't know. I'm certainly seeing the architectural strain with a Django-first architecture in the current 150kloc monolith I'm working on, and chopping into a few services makes sense there for other reasons, so it might obviate the need for a bigger refactor onto Clean/Hexagonal.