DDD is something not a lot of devs know about, but then every single microservices concept/pattern/architecture is basically some sort of applied DDD. Do I like the philosophy? Yes and no. Yea because it's been a great source of inspiration for me. No because I think Evans, just like Martin and a few others is basically nothing more than a businessman, trying to sell books and workshops and conferences, while being completely detached from the reality of production code, deadlines and code maintainability.
The concepts are really interesting, but I'm pretty sure none of the suggested implementations are remotely acceptable in a professional environment.
Why Domain Driven Design?
11–20 of 175 posts
Re: Why Domain Driven Design?
#12I thought the DDD hype has died down a bit, but I guess not. Eric Evans (inventor of DDD) has said in recent years that unfortunately once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear. People do NOT have the discipline to do DDD correctly. But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "serv…
Would you have the quote on that? I'm curious.
In my opinion, Microservices is an implementation detail, and the extend to which DDD principles are applied is about people and ownership.
Re: Why Domain Driven Design?
#13I thought the DDD hype has died down a bit, but I guess not. Eric Evans (inventor of DDD) has said in recent years that unfortunately once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear. People do NOT have the discipline to do DDD correctly. But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "serv…
> But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "services". Eric Evans has said that people using microservices may represent the most successful application of DDD's principles, not because people using them were fans or even aware of DDD, but microservices enforce the patterns DDD Evans was describing.
Sir, your assembly code is so hard to read with all them GOTOs. You should do structured programming, use constructs such as loops to make it easier to follow.
Man, your code is so long written like that, you should break it into functions to make it easier to reason about.
Dude, you have so many functions it's impossible to make heads or tails of the logic, you should break it into classes to be able to abstract away all of this detail.
Bro, you have so many classes I don't even know where to start. You should introduce modules so that it becomes possible to isolate different parts of the design.
Dawg, you have so many modules, you ought to break them into small different runtimes communicating via a rest protocol to isolate different parts of the code.
Choom, you have so many microservices, you ought to break them into different microclusters to separate the different parts of the API.
X'man, you have so many microclusters, you really ought to break them into different miniclouds to spearate the functionality and make it easier to follow.
𐀘𐀐, you have so many miniclouds it's impossible to deal with this code, you really ought to separate it into functional minicloud clusters.
Re: Why Domain Driven Design?
#14I thought the DDD hype has died down a bit, but I guess not. Eric Evans (inventor of DDD) has said in recent years that unfortunately once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear. People do NOT have the discipline to do DDD correctly. But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "serv…
> once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear
Conway's law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
Re: Why Domain Driven Design?
#15DDD sounds amazing, but y'all the pull requests are usually a dozen files with tiny changes. At least from what I have seen. And the promise is "change is easy" or "impact to existing code is low." This may be true. Is it? I have the Evans book. It may completely change the way I write code. But I also have "C Interfaces and Implementations," and that promises another. Yet another is Stepanov's "Elements of Programmi…
> DDD sounds amazing, but y'all the pull requests are usually a dozen files with tiny changes. At least from what I have seen.
When I've used it, a typical PR is about a Query or a Command, that calls a repository to retrieve an entity maybe performs some logic using that domain entity and stores it afterwards, three layers, application, domain and infrastructure. If you have more changes that those 3 layers (I'd say 2 files minimum, maximum about 6 ? ).
Maybe the feature / user story is not granular enough ?
Re: Why Domain Driven Design?
#16IMO there are two good and interesting ideas behind DDD - the notion of an ubiquitous language and bounded contexts. However, these concepts are vague and underdeveloped. I'm not even sure they were original.
Meanwhile it gets way too specific about certain design patterns. These are not as generally applicable as the originators imagined and have a tendency to blow up SLOC and add too many layers of indirection.
Re: Why Domain Driven Design?
#17The problem with following a list of principles inside of a book is: It's hard and requires a holistic view of the entire manuscript which everyone has to remind themselves all the time.
This is much more compelling:
Why domain driven design? Because we have tools that detect deviations and give suggestions for expanding your models.
Just like Rust constraining ownership, just like ruby on rails generating entities, controllers, css html and js for your model with a single command.
In other words, writing rules is easy. You are just leaving tooling (the most useful and hardest part) as an exercise for the reader.
Re: Why Domain Driven Design?
#18I'm divided on DDD. On one hand there are some good ideas (system is model, language is important etc) that seems "obvious", but I guess still worth explicit mention.
On the other hand there are implementation techniques that strike me as not really Domain Driven, but I Program In Java With Hibernate Driven (Entities, Value Objects & Aggregates section).
I wonder why those two are married other than historical accident.
Re: Why Domain Driven Design?
#19I thought the DDD hype has died down a bit, but I guess not. Eric Evans (inventor of DDD) has said in recent years that unfortunately once a team is big enough, all the invisible conceptual boundaries between domains blur and disappear. People do NOT have the discipline to do DDD correctly. But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "serv…
> But do you know what helps? Having physical boundaries you can't cross so easily. Microservices. Or as I call them... just "services". Eric Evans has said that people using microservices may represent the most successful application of DDD's principles, not because people using them were fans or even aware of DDD, but microservices enforce the patterns DDD Evans was describing. Sir, your assembly code is so hard to…
this is a good summary of why I pay zero attention to power point decks and blog posts. there is never a right answer and it's just people masturbating in circles. it's not rocket science, half of the time it's not even computer science. design patterns, at a certain point, become full of themselves.
Re: Why Domain Driven Design?
#20I teach programming and software design, too. But i never use domain, driven, design,... as vocabulary. I use function all the time. "Hey guys, just use function, that's all you know to make usable software." What's the problem with NOT following "weird, confusing" patterns and vocabularies. And the result is, all of my students actually make useful code, simple code. Also, most of software recruiters will tell you:…
Teaching-scale and production-scale programs are very different. Teaching-scale, where students start with a blank sheet of paper, are better served by simple approaches. You can't put enough complexity in there to warrant a complex framework.
I would like to see a course with a "maintenance" module, where students have to make changes to an application that's maintained over the several years of the course running. Including dealing with mistakes made by previous students.