So how is all of the Domain Driven Design stuff supposed to be wired together?
-
Preface: there are lots of ideas from DDD that make sense to me. Aggregates, bounded contexts, universal languages, etc.
But as I read more through it, most of it is talked about at a very high level of
generalityvagueness. Lots of abstract diagrams...but nothing that would actually help me implement it in any significant context.Like let's say I have an HTTP API (vaguely REST-like, but that's not so important) running with some off-the-shelf web server (express.js in this case). A request comes in, gets picked up by the server and I've got a request object and a response object (should I need it). I even, because I was smart, know what aggregate I'm working with, say a Schedule. But now what? Where does this server reach out to (in this case, I've got a callback hook that the express.js code is running)? Does it directly call a method on the Schedule object? Where does it get that from? Does the server code have to know about all the dependencies (factories, repositories, other aggregates that are referenced and might be needed, so also their factories and repositories, etc)? Or is there some sort of controller thing? Or am I thinking at the entirely wrong level here?
I guess this is mostly a rant. A rant that all these "architecture" and "coding patterns" books faff about at the really high level, 10k-foot view...but never give any guidance on what that looks like outside the realm of toy problems. Same with all "tutorials" (which often have the bad habit of just saying "here, run this code, isn't it special?"). Utterly useless for anything.
-
@Benjamin-Hall said in So how is all of the Domain Driven Design stuff supposed to be wired together?:
never give any guidance on what that looks like outside the realm of toy problems
Non-toy problems tend to be hairballs with lots of detail on all sorts of things, and are hard to learn anything from. Unless you want to learn ten things all at once with the particular weird way they interact this time.
-
@dkf said in So how is all of the Domain Driven Design stuff supposed to be wired together?:
@Benjamin-Hall said in So how is all of the Domain Driven Design stuff supposed to be wired together?:
never give any guidance on what that looks like outside the realm of toy problems
Non-toy problems tend to be hairballs with lots of detail on all sorts of things, and are hard to learn anything from. Unless you want to learn ten things all at once with the particular weird way they interact this time.
But toy problems are only valuable for "lies told to children" purposes.
-
@Benjamin-Hall said in So how is all of the Domain Driven Design stuff supposed to be wired together?:
But toy problems are only valuable for "lies told to children" purposes.
And full projects are incomprehensibly complex.
I guess that's why the few bits and pieces of extended tutorial material that manage to hit the space between the two are so valuable. It's rare, so even if it is an imprecise fit to what you're solving it is still a useful way to show how two-or-three systems can fit together. (Alas, all too often it takes quite a lot of reading and experimenting to understand the underlying model that all of these things dance around; once you've got that, many things fit together easily. But that doesn't really help anyone faced with an immediate problem…)
-
@dkf said in So how is all of the Domain Driven Design stuff supposed to be wired together?:
@Benjamin-Hall said in So how is all of the Domain Driven Design stuff supposed to be wired together?:
But toy problems are only valuable for "lies told to children" purposes.
And full projects are incomprehensibly complex.
I guess that's why the few bits and pieces of extended tutorial material that manage to hit the space between the two are so valuable. It's rare, so even if it is an imprecise fit to what you're solving it is still a useful way to show how two-or-three systems can fit together. (Alas, all too often it takes quite a lot of reading and experimenting to understand the underlying model that all of these things dance around; once you've got that, many things fit together easily. But that doesn't really help anyone faced with an immediate problem…)
Yeah. I don't want a full project, but even a basic idea of how you'd go about wiring this thing together. Or even guidance as to different styles. Instead it's all fully abstract and intentionally domain agnostic...which kinda goes against the whole point. Or uses fully domain things. It'd be like a guide to building computers which gets to the level of "ok, there are CPUs, which do X, mainboards which do Y, and IO devices that do Z. Build your own and put it all together and write an OS and magic!"
