I think about this a lot, and I think my core beef with stuff like this is:
- Engineering team has a problem
- Engineer/Lead/Architect reads a book
- Whole team builds an in-house, bespoke framework around the book's ideas
- They now have 2 problems
I'm very against in-house frameworks; I think they almost never deliver on value, and you should just use Rails/Django/etc (again, you almost certainly won't outdo them).
But if you use a framework that implements DDD (or SOA, or whatever), I'm very OK with them. For instance, I think that Django is basically DDD/CQRS/SOA: views are the service layer, models are entities, querysets are repos, REST is defacto JSON-RPC, etc. And you do start to realize the benefits: engineers aren't bogged down with irrelevant stuff like request (de)serializing, they don't have to make architecture decisions on the fly, you don't have to document/test the framework, etc. etc.
Frameworks are not architectures, and architectures are not frameworks. DDD is an approach to building an architecture that emphasizes domain modeling. Done properly, all the web gunk (and there’s a lot of it) can be mostly isolated from the actual interesting part: the domain being modeled.
Until we as a profession understand how to structure code and how it is different from simply choosing Django vs flask, these discussions will not be productive.
I'm not saying they are; I'm saying you should outsource the building of a framework that implements your architecture of choice when you can. I would also go further and say that if you can't, you should pick a different architecture where you can.
I hear you. I just don’t trust frameworks to actually sell you on an architecture that benefits you more than them. Thus you don’t get full benefits of said architecture because you’re using a sanitized version.
Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's monolithic nature).
Maybe a monolith on BEAM (Erlang, Elixir) could be marked as SOA due to the nature of BEAMs concurrency model.
> engineers aren't bogged down with irrelevant stuff like request (de)serializing
Last Django app i saw sure had a lot of this boilerplate going. I saw this talk and thought: well this is finally a "framework" that allowes me to do away with serialization (as in: in this framework the amount of extra work you do for making the app an SPA is fairly minimal):
> Sure you can do DDD in Django. But I do not find that framework inherently CQRS of SOA (not SOA due to it's monolithic nature).
Django has "apps", which--while they do run in the same process--aren't intended to use code from each other. They're supposed to have their own models/views/templates/migrations/etc. They're effectively different services, as long as you don't think a service has to be available at a different network address to be a different service (think of mounting different apps or microservices behind different URLs, for example).
Also, I wouldn't say Django is CQRS--CQRS is more or less a different phrasing of "JSON-RPC", which "REST" has become.
> Last Django app i saw sure had a lot of this boilerplate going. I saw this talk and thought: well this is finally a "framework" that allowes me to do away with serialization (as in: in this framework the amount of extra work you do for making the app an SPA is fairly minimal):
Eh, some people are highly allergic to any boilerplate, but like, the DRF example [0] has practically none.
That Elm video is interesting, but I'm skeptical of anything whose central claim is "I can easily turn front end data requests into SQL and back again in very few lines of code". There's just a lot of inherent complexity there, and my evidence is every mainstream ORM, plus all the "backend-as-a-service" products that are multi-1000s LOC. Then again I think SQL is a great (legendary, honestly) language and we should stop trying to replace it.
> I'm skeptical of anything whose central claim is "I can easily turn front end data requests into SQL and back again in very few lines of code".
Same for me. The Elm video is showing off a toy, an interesting toy, but a toy. The presenter also says it's for now only useful for fun projects.
Something with a more mature backend in the same direction would Hasura (a GraphQL and authorization layer over Postgres) with a generated-from-the GraphQL-spec client library. A generator for Elm exists (which give you strong type-safety over the API barrier).
It does lead to a situation where SQL barely used. The GraphQL used to query the db is very SQL-like though :)
I absolutely love Hasura. I basically never want to write a backend API again after using it. But yeah it is a GraphQL to SQL compiler (and yeah all the attributes are like "where", "aggregate", it obviously is SQL-in-GraphQL), which... yeah let's just use SQL everyone, come on.
It's good if those frameworks are very high quality and very thoroughly debugged like django is but if you have to spend an appreciable amount of time peeking under the hood they quickly become a nightmare.
I think about 9 out of 10 home grown frameworks end up in the nightmare bucket.
I'm super skeptical of frameworks that dont really "do" anything also. Django handles web and database and saves you from a whole load of boilerplate crap but any DDD framework would basically just be an opinionated code mold, a bit like all those dependency inversion frameworks. 100% straitjacket but with none of the boilerplate written for you.
- Engineering team has a problem
- Engineer/Lead/Architect reads a book
- Whole team builds an in-house, bespoke framework around the book's ideas
- They now have 2 problems
I'm very against in-house frameworks; I think they almost never deliver on value, and you should just use Rails/Django/etc (again, you almost certainly won't outdo them).
But if you use a framework that implements DDD (or SOA, or whatever), I'm very OK with them. For instance, I think that Django is basically DDD/CQRS/SOA: views are the service layer, models are entities, querysets are repos, REST is defacto JSON-RPC, etc. And you do start to realize the benefits: engineers aren't bogged down with irrelevant stuff like request (de)serializing, they don't have to make architecture decisions on the fly, you don't have to document/test the framework, etc. etc.