> Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts ... That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous) ... > DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation.…
Agreed, my issue wity DDD is that it is based on a bunch of good ideas but very little of it is actually actionable.
Domain-Driven Design
191–198 of 198 posts
Re: Domain-Driven Design
#192I am working really hard on how to apply DDD to a video game context, specifically with unity3d. It is a struggle because I think the game creator cultural zeitgeist doesn’t like applying software patterns from ‘outside’ influences, like enterprise software. It is my personal view that the zeitgeist is terribly short sighted and is actually only considering the game client at the expense of the entire software system…
Re: Domain-Driven Design
#193Like 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…
> '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…
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).
Re: Domain-Driven Design
#194Earlier quoted context omitted.
I think the question was more how to sell not-doing-DDD. Reasonable people (including DDD advocates) clearly understand that tactical patterns can easily be misapplied, and that the strategic part of it is more important, but inexperienced programmers jump in on the "new" fad (it's not even that new, which is most perplexing to me), and misapply all the patterns they possibly can. I see there's a lot of similar senti…
One cause of misapplying tactical patterns is learning. When people start learning something, they do it badly and in inappropriate contexts. The solutions to this are: A. Don't learn things. B. Dedicate some amount of time to learn something in a sandbox before using it on the job. C. Once you've learned something well enough to see the error of your ways, dedicate some amount of time to clean up your old work.
B and C are a single thing, and unfortunately, C does not happen, which is why any particular methodology gets a bad rep. And it's obviously already happening with DDD (judging by the polarized sentiments around here).
And finally, while I do believe abstraction is the ultimate tool of the human mind (and mathematics is the purest form of abstraction we are capable of), I do not think it suits all brains equally, and not everybody will be equally capable of ever getting the right understanding. Basically, your architecture can be _too smart_ if you are looking to hire actual, real-world developers and software engineers, and have them be efficient.
Re: Domain-Driven Design
#195Other than that, most DDD concepts are a bit dated, and really oriented around JAVA/C# in the early 2000s.
Re: Domain-Driven Design
#196Earlier quoted context omitted.
How exactly does DDD advocate forming bounded contexts? I ask because only ever heard personal opinions in answer to this question. I researched it heavily and found nothing. As far as I can tell it doesnt.
I've been replying to you in other threads. There is no answer to this question, it is an art. I understand that it's frustrating, but that doesn't make it any less true. As far as what the goal of the art is - the goal is to avoid linguistic and semantic ambiguities in the ubiquitous language. There is even a section entitled "Recognizing Splinters Within a Bounded Context" where specific examples are given: * dupli…
It's conceptually similar to answering the question "How do I know where the borders of Germany lie?" by saying "ask the first person you see if they speak German".
It also conflicted with a process I followed, which was to essentially create a team glossary and agree to semantically disambiguate terms which had multiple different meanings (e.g. linux user/website user instead of just user) and even just "ban" the usage of terms which got overloaded too much.
(I discovered that semantic collisions didn't just present problems in code, it often prevented you and your team from having coherent conversations).
This could, of course, then put everything we touched as a team into the same bounded context. Or not...?
>The example in the book given is the notion of a "Charge," which customer invoicing and bill payment departments might both use. But each department only cares about certain pieces of data of a charge
It sounds like they're essentially saying (not explicitly, but via assumption), that your software should follow conway's law.
Nonetheless, this example screams "bug alert" to me, since assumptions made by departments (and, as a consequence software systems) about what they should care about are where the really nasty bugs lie - frequently driven by misunderstanding between departments about terms (e.g. what counts as a user).
Re: Domain-Driven Design
#197Seeing a lot of hate for DDD here so let me offer an alternative point of view from someone who advocated for DDD on my team. When I joined, my team had been building the backend for the first version of our app for about 4 months. I would describe the state of the code base when I joined as an 'Anemic Domain Model' as defined by Martin Fowler - There was a 'domain model' in the loosest possible sense - Each model ty…
Perhaps the problem is inventing a new language for good application design. Uncharitably, this explanation sounds as if you've taken a description of modularity, type-safety, and maintainability and run it through a randomizing jargon thesaurus. If an experienced developer can barely understand you, there's a communication problem.
Re: Domain-Driven Design
#198The principles listed in the article look like general common-sense design principles. I can hardly imagine anyone designing a system without understanding the problem domain first - and likewise, the problem domain usually drives the underlying models (because what else can they be driven by)? I acknowledge that something the design process strays away from the original domain requirements (especially among the less…
What's particularly contrary to DDD principles and common is mixing up different concerns without regard for model integrity (e.g. ad hoc incorrect caching of stale data for performance reasons, messing up all business logic).