3 ms·

Like the original post fails to mention any stakeholders when it comes to developing "Ubiquitous Language" (it enumerates "engineers, testers, analysts, …", and

Like the original post fails to mention any stakeholders when it comes to developing "Ubiquitous Language" (it enumerates "engineers, testers, analysts, …", and I don't think ellipses does any justice to them), most people forget that DDD is about modelling the real world before you start coding. My experience is that, unfortunately, majority of developers are either not experienced enough, or smart enough (these are closely related), to keep the abstraction creep at bay and apply only meaningful abstractions. And others are simply not interested enough, and they know they can get a LGTM with following misjudged patterns. They also jump at the opportunity to use identical terms from the DDD book, and then keep explaining them with more colloquial terms everybody understands: it's like social sciences all over again (sorry social sciences, but it's what it is) where they invent terms so they'd be more "scientific". Why not simply use the terms everybody understands? I get the argument that a new language allows for consistency, but it still gets misapplied, because it's the same humans doing the work. I can't think of a better parallel than SQL-vs-noSQL databases: sure, no-ACID makes a bunch of things simpler, but then every developer has to think through all of the same problems ACID DBs solve, and majority will get them wrong (or maybe even everybody would get them wrong _most of the time_).

arkh 5y ago
> majority of developers Jump to coding or architecting because that's their happy place. That's easy, that's what they know so they think that's what they've been hired for. Shelling some dollars to buy an off-the-shelf solution for some ancillary application? No thanks we think we can do it ourselves and have more control over it. Let's go coding.
Kototama 5y ago
> 's like social sciences all over again (sorry social sciences, but it's what it is) where they invent terms so they'd be more "scientific". Why not simply use the terms everybody understands? To be precise probably. Every domain develops a jargon at some point. It can be used to exclude or sound smart but most of the time it just to be precise. Common terms are too much vague / polysemic. Why do you need words like compiler, linker, dynamic and static types and linter instead of using common words?
- necovek 5y ago
  I am fine with jargon to suit a purpose. You'd have to explain "compiler" or "linker" with a mouthful, and you are unlikely to be very successful (unless you go to those mathematical models of computers). My (limited) experience with social sciences (as obligatory courses in Math/CS studies) was that you'd have things like "Someone's Continuum" (I am, thankfully, at a loss for the name of Someone :)) to say that two extremes of learning are rote learning and learning with understanding (this, by virtue of what "two extremes" mean in a natural language, means that there are things in between), all explained in 3-4 pages of dense prose that says, literally, nothing else. There is no precision gained from introduction of these terms for the most part, mostly the number of things to memorize is increased. To contradict that, a "continuum" in mathematics is given a very precise meaning to indicate that no matter how small your "in between", you can still find something there: you get very particular properties and can easily differentiate if something is a continuum or not. You also build up other tools to work on things which are "continuous", like derivatives, differentials or integrals. Some of the language of DDD is quite like it, which probably makes sense, since it's more closely related to social sciences (not rigorous science), rather than formal sciences. That's not to slight it, because that's the best we can do with some things, but that means that in any particular setting, you should understand what you are trying to get out of it, and if you are struggling with language, move on to the point of the exercise instead (eg. establishing domains, boundaries and shared language as it relates to your problem).

arkh 5y ago

> majority of developers Jump to coding or architecting because that's their happy place. That's easy, that's what they know so they think that's what they've been hired for. Shelling some dollars to buy an off-the-shelf solution for some ancillary application? No thanks we think we can do it ourselves and have more control over it. Let's go coding.

Kototama 5y ago

> 's like social sciences all over again (sorry social sciences, but it's what it is) where they invent terms so they'd be more "scientific". Why not simply use the terms everybody understands? To be precise probably. Every domain develops a jargon at some point. It can be used to exclude or sound smart but most of the time it just to be precise. Common terms are too much vague / polysemic. Why do you need words like compiler, linker, dynamic and static types and linter instead of using common words?

necovek 5y ago
I am fine with jargon to suit a purpose. You'd have to explain "compiler" or "linker" with a mouthful, and you are unlikely to be very successful (unless you go to those mathematical models of computers). My (limited) experience with social sciences (as obligatory courses in Math/CS studies) was that you'd have things like "Someone's Continuum" (I am, thankfully, at a loss for the name of Someone :)) to say that two extremes of learning are rote learning and learning with understanding (this, by virtue of what "two extremes" mean in a natural language, means that there are things in between), all explained in 3-4 pages of dense prose that says, literally, nothing else. There is no precision gained from introduction of these terms for the most part, mostly the number of things to memorize is increased. To contradict that, a "continuum" in mathematics is given a very precise meaning to indicate that no matter how small your "in between", you can still find something there: you get very particular properties and can easily differentiate if something is a continuum or not. You also build up other tools to work on things which are "continuous", like derivatives, differentials or integrals. Some of the language of DDD is quite like it, which probably makes sense, since it's more closely related to social sciences (not rigorous science), rather than formal sciences. That's not to slight it, because that's the best we can do with some things, but that means that in any particular setting, you should understand what you are trying to get out of it, and if you are struggling with language, move on to the point of the exercise instead (eg. establishing domains, boundaries and shared language as it relates to your problem).