Mar 1, 2021 · 11:40 AM UTC

24
44
21
179
Replying to @stilkov
My "problem" with DDD is that it is not primarily about design, but collaboration (find a common language) and analyzing the domain (bounded contexts). <- The strategic patterns. The technical patterns are just one implementation variant.
1
7
Replying to @stilkov
Agreed, and also to fully understand something you must try it out as intended to experience how it works, and learn about when to use what pattern, and when not. As @mathiasverraes said, @rebeccawb her take on design heuristics is really valuable at that point.
3
Replying to @stilkov
As with all things the last decade, discussing the rise and fall are a recurring theme, with the essence often being lost in translation ... true, many more patterns which help with design, a little less focus on DDD lingo and a little more on what it enables are a good reminder.
4
Replying to @stilkov
"This is fine! This concept, that we can and should invent our own languages, is to me way more important than many naïve DDD practitioners think." This is true and this is what DDD actually entails....
1
1
Replying to @stilkov
I agree. The mindset of DDD is way more important than the concrete building blocks. Especially the tactical design introduces some terms which are hard to grasp (what's an aggregate?). It's not necessary to have these building blocks in order to build a domain oriented system.
1
3
Replying to @stilkov
There is no shortage of methodologies and their devotees and detractors. What there is a shortage of is guidance about why, when and when not to use each one.
Replying to @stilkov
"..But it also uses its own language..:" It uses A language. Use your own, call an Aggregate Thing. But understand the concepts, which are kinda ubiquitous and, well, timeless... You can bash every vocabulary. Most of the time there is one because people need names 🙄
Replying to @stilkov
I’ve done this myself and seen others: talking architecture in DDD vocabulary, thereby ecxlcuding those who do not know about it. If you really understand it, you should be able to abstract the concepts and goals of DDD so everyone on the team understands it.
1
4
Replying to @stilkov
I agree with your article. If I had one remark on the contents, it's that you describe DDD without mentioning modelling, but your post isn’t about that of course. (Evans & Vernon use the word "model" at least 500 times in their books.)
2
1
4
Replying to @stilkov
Looks like you spent some time with some DDD zealot! ;-) I don't agree with your post title - yet it caught my attention, so... but many of the things you say resonate but made me think "somebody is fighting a war in the name of the blue book" ...which is not the point.
1
9