TL;DR
Domain Driven Design, which was described in 2003, about the same time as TDD. And like TDD, was a terrible idea twenty years ago, and even more so twenty years later. The naive idea that focusing on modeling software to match a domain according to input from that domain's experts" would lead to anything but wasting time should have been obvious to anyone that had just once tried to get one of these "domain experts" to describe the "domain" they were supposedly an expert in.
What are you an expert in exactly?
I once was hired to as technical lead on a project that built the world's first all digital cable news room in the mid-90s.
I was given a "bible", which was actually two, 3 inch thick, 3 ring binders. These binders were the artifact of almost 3 years of "requirements gathering" documenting the "domain experts" idea of what their domain was, what they wanted and how it should work.
Guess how many times anyone opened those two binders or even referred to them once we started building the systems?
Guess how many of the "domain experts" actually knew what was in those artifacts three years later?
Guess how many things the "domain experts" described in those artifacts were exactly the opposite of what we ended up with in production?
Guess what percentage of those two binders were implemented in the end?
Guess how many updates with new functionality were deployed in the 13 years that 24/7/365 system was in production?
What is the goal of the software project exactly?
Here is what the system ended up doing.
It allowed ingestion of live digital video from the satellites directly to digital video servers and digital video tape simultaneously.
It allowed a person to interactively mark clips of that live video for a producer/editor pair in a live editing suite in real time as it was ingested. This was called "triage".
It allowed the producer/editor pair to edit those clips into a finished package while the live event was happening, and write a script for the finished package in real time.
It allowed the newsroom to have a finished package with the highlights of the live event ready to be broadcast as soon as the embargo of the live event was over; usually immediately the end of the event.
It allowed a person to archive the video from the limited storage digital video servers to digital tape, generate a edit decision list with timestamps and descriptions to be printed out, saved on floppy disk and stored with the physical tape, as well as load the tape back to the digital video servers using the edit decision list stored on a floppy disk.
That is not two 3 inch three ring binders of requirements.
And the one things that was NOT in those binders was the time we had to build this; 6 months.
There were ZERO developers involved in creating those binders of requirements, and if there had been,there would have been 5 binders instead of 2 and probably another 2 years spent creating them.
Because the "domain" had nothing to do with the system that needed to be created in practice.
The "domain" they documented, was the domain of what they need to replace with automation and had nothing to do with the requirements of the automated system.
I read through the first few hundred pages of the first binder while I was waiting for the rest of my team to be onboarded, it was just a very structured overly detailed description of what the people did every day and how they did it.
None of the verbosity of the details were relevant to the automated systems that were actually built.
The computer systems that were required to automate the newsroom, did not need step by step instructions on how to insert tapes into a machine, press the buttons to get them to do what you needed and how to remove the tapes. That was all details that the interns needed to know, interns that were replaced by machines.
Well all but one intern, someone needed to push the cart full of tapes from the tape room to the edit booths and back. At least until they bought petabytes of robotic tape storage a few years later.
Why it was a flawed concept from the start
Domain-driven design is predicated on the following goals:
- placing the project's primary focus on the core domain and domain logic;
- basing complex designs on a model of the domain;
- initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
The last bullet point is the only relevant one and even it is predicated on the fallacy that the domain expert is an expert in what the problems are, much less how they should be fixed and what the end result should look like.
This is your "domain expert" at work.
This is like a story I read a very long time ago, about someone who installed a computer system to track invoices in a database to eliminate the paper system that had multiple copies on different colored forms of carbonless copy paper. The main reason they installed this system was to speed up processing and reduce human errors.
The developer was asked to come back in and explain why the system was still having the same human errors of invoices being not processed or processed multiple times.
The old lady who was in charge of the "domain" of the invoice system, was just printing out the invoice multiple times and had bought rubber stamps that said "this is the pink copy", "this is the green copy" and was still processing them in her filing cabinet manually.
This is your "domain expert" at work, they are an "expert" in the domain you are replacing, and not the one you need to build.
The "domain" of pink, green, yellow copies is irrelevant to the computer database implementation.
What should the goals be?
- placing the project's primary focus on what the end result should be; a more efficient in time and space process as well as less error prone and auditable for root causing where and why bad data happens when it happens.
- reducing complexity by ensuring high cohesion and loose coupling;
- initiating a creative collaboration between technical and future uses of the system to iteratively refine a process that improves their lives and gives them more time to do what humans do best and let the machines do what they do best.
Dogmatic adherence to a "Driven Design" never works.
If you have never read the Tao Te Ching, you should, it is very short and very relevant in many ways to what we do as machine instructors.
The main principal of the Tao Te Ching;
The tao that can be told
is not the eternal Tao
The name that can be named
is not the eternal Name.
this applies to everything, but applied to software development
There is no one true design process, as soon as you name it, it not the one true design process.
Our job is to produce an extremely amorphous product from extremely flaw "requirements"; flawed because very few people can step back and see anything other than what they do and their struggle to stay relevant to the process. Take away their mindless shuffling of pink and green copies in different filing cabinets and you take away their safe comforting repetitive daily activities and force them to think instead of just going through the same mindless motions every day.
I have been an machine control automation specialist for 38 years. I take people out of the process so they can do what the machines can not do. That ends up being required to think, it becomes painful, just like the story in "Who Moved My Cheese".
If you run the same maze to get the cheese in the same place every day, you are a commodity. Commodities are interchangable, thus replaceable and expendable.
If you can explain to me what you do every day and it is a repeatable process that uses decision making that you can type down, I can automate it and instruct a machine to do it instead.
Top comments (61)
It looks you are very confused.
Domain Driven Design concept appeared from the Eric Evans book, that was first published in 2003. The experience you are describing "in the mid-90s" -where there was no concept of DDD yet- is a typical waterfall planning, where you get the requirements, not from the domain experts, but from the analysts.
The fight against this way of working sparked the agile manifesto, DevOps, CI/CD and many other common practices now. It looks you missed that.
Still, there are valid points on what you say, people need to be critic all the time.
It will be well if you get informed and read the Eric Evans book, the "Implementing Domain Driven Design" from Vaughn Vernon, and also it will be very interesting for you the "Project Phoenix", since you cite "Who moved my cheese", also the "CI/CD" book, which is a little bit old, but makes for an enjoyable read.
Probably all of it is tangent to what you do if you have been "control automation specialist for 38 years". But you'll probably get different points of view.
"analyst" is even worse; it was just another person that was supposed to "analyze" the system and write down how it worked, usually by interviewing the "domain experts". That was even more of an epic failure on how to decide what was needed. Garbage Man or Waste Removal Technician, same job regardless of title. And 1995/6 is not that far removed from 2003 in internet time it is just a few mins ago.
All these ? Driven Design books came out and spawned a cottage industry of consultants (experts from out of town) that would come in and help you build your application; train your team; and bill you boat loads of hours and none of them. NONE of them were even close to correct; much less the silver bullet they promised and that people still claim, two decades later; to still be.
you left out one semantically important part of what I do "MACHINE control automation" and what is programming but controlling machines to work in an automated way.
Aren't you one of those "consultants"?
Your view of people seems to be very narrow and very negative.
Nobody explained to the business that was shuffling green/pink papers what the new process should be with the new system? They installed the system and then washed their hands clean without talking to anyone in leadership?
Maybe better communication with some of the domain experts would have prevented that out the gate.
You're by no means wrong on all of your points. But pointing some of that contempt and criticism you have for everyone else at yourself might help make you a better person (even if you have already been doing this for nearly 4 decades). Never too late for a dog to learn some new tricks.
nope; never have been, my career has been "firefighter", I primarily came in to drag projects over the line screaming and kicking. I made good money dumping all the dogma that did not work, just getting in there, writing the code and getting something deployed. In weeks or months, usually in less time than the project was over due on. Granted, I had the foresight of the failures of the people that were 9 months over scheduled on an 18 month project. I was effectively writing and deploying at least version 2 or 3 of the application at that point, for all practical purposes. But, they were never going to get anything deployed the way they were going, dogmatically adhering to some pie in the sky philosophy like it was a Religion, because it was being promoted like one, usually by an "evangelist" that was a fervent follower of savior that wrote the book about it.
I have never written and promoted a book about the one true way to write successful software projects.
I have never sold courses that promote any thing as the one true way you must do anything.
I have been too busy actually putting applications into production the last 30 years, most of them environments where down time has to be 7 to 9 NINES and where performance; in time and/or space was critical. Where data must have an immutable audit trail of mutations. I have had ops teams contact me when I was leaving the company and asking what the dozen servers with my name on did, because they had forgotten they were even there because "we never have to reboot them or constantly patch them like all the other line of business apps in the datacenter".
So, no I am not one of "them".
You're still a consultant. A consultant going around talking about how all consultants are bad.
If you can't see how narrow minded and silly that is I can't help you bud. Maybe it is too late for some dogs to learn new tricks afterall.
Sincerely,
A guy who's not a consultant
and if you can not see that telling me who and what I am and what I am saying and thinking is not way more "toxic" is the limit of irony. I am not a consultant, never have been, I have never sold a book, training course or anything that consultants do. I have been a contractor, a hired gun, a firefighter but never a 'consultant' I actually did things with quantifiable outcomes.
I have never been an evangelical for any specific tech priest/priestess or tech religion.
If you knew me personally, you would know that, but you do not.
but go ahead and tell me who and what I am and sling ad homien attacks, that says all about you; not me.
Straaaaaaaaw man. First, you basing a critic of a whole technique on two anecdotes. Second, the problem in the first anecdote is a) thinking 100% upfront design/requirement gathering can work and b) not doing one of the main things DDD advocates for: letting developers talk to the domain experts.
The second anecdote doesn't have enough detail, so I don't really have a strong hypothesis, but if the person in charge still felt the need for pink/yellow/green copies after the system being implemented, I have to wonder, did the system properly model the concepts of green/yellow/pink copies? It doesn't have to store multiple copies, but if that's how people think of it, it has to model that concept somehow, with different views, for instance. Perhaps a little more DDD would have helped XD
That said, I bet that one could find plenty of cases of DDD overuse in the wild, even if used well, because there are no silver bullets but people insist on trying to make them. But that's true for any technique, and doesn't mean the technique is wrong, or harmful.
I use DDD like I use TDD, or UML, or BDD, or OOP: as a tool, to be applied when needed, and to be ignored when not.
you miss the point, DDD was ineffective when it was penned, anyone that had been writing non-trivial software projects before that ( mid-1990s ) would know that. If you are using any one of those things "when needed" and "ignored when not' you are not using them, you are doing your own thing. They are religions, they dictate adherence or heresy. "Clean Code" is the worst of them as well, that one is going to be my last entry on this series. It is the most egrigous.
Funny because Clean Code and DDD are the two books I suggest to juniors as "things to read asap". None of them are dogmas and both of them works well when applied correctly, which was probably not the case on your projects. Never ever heard about any kind of resource gathering with DDD that will produce 3 books worth of results. It smells like waterfall to me more than anything else.
Btw, how do you understand the domain without talking to domain experts? Who gathered the requirements for your project? It was a business analyst? Someone needs to talk to the business experts otherwise your program will not solve their needs and probably that's the reason why they still keep printing useless copies and such (or lack of education).
Also, you rarely if ever replace domains, but rather digitalize some part of an existing one. Why do you thing that the new domain you create would be better than the existing one? Especially if you are re-creating a domain from scratch that was improved for dozen of years and probably quite complex. I'm not sure if you understand the "domain" part of DDD to be honest.
two out of 40 years of professional paid career where i made all this mistakes. the difference is i learned from them and am trying to share that experience. others just double down with logical fallacies because they can not admit they are wasting time.
I really understand your frustration when it comes to so-called domain experts as I have been involved in the development of an automated workflow for a local institution, which was stuck for a number of months because the person who compiled the initial requirements didn't speak with the people that were supposed to work with the application and those people only had a very narrow view of what was going on. So I really get it.
However, this has nothing to do with Domain-Driven Design. Actually, in the very first chapter of the DDD book, called "Crunching knowledge", the author describes the initial phases of a project:
To me, this sounds like the very same problem you're described using the three-inch binders.
The next step is to define a "ubiquitous language" which creates a bridge between the language used by the stakeholders and the code written by the developers. For example, the domain expert will tell you that you are inserting a tape in a recorder, while your code will have a
Recorderobject that "writes" data into aTapeobject.Personally, I have found a lot of value in designing my domain models to match the language used by the domain experts. Sure, in some cases having "pink" and "green" invoices makes no sense from a database perspective, but I found that in a lot of cases there's some meaning to the color (overdue invoices might be red, recurring invoices might be blue and so on) which wasn't missed from the initial specifications.
There are other parts in the DDD book that seem to be relevant only for extremely complex systems and maybe too many people reach for those patterns when they probably shouldn't, but this shouldn't subtract from the overall value of the book.
Finally, I don't think we should complain too much about the "domain experts". They aren't supposed to know how to build software, that's our job. Sure, the job might be hard from time to time, but let's not forget that we are generally better paid and have a much more fulfilling job that most of the domain experts we work with.
you missed the entire point, "domain experts" are usually wrong because they are telling you how they navigate a maze that never changes to get their cheese, when the entire point of the new system/process to remove the maze.
This is simply untrue. Sometimes carving off a couple of extra turns is all thats necessary. Creating a new system is not THE solution, but a solution. Also, most of the time it is the wrong one.
you are moving the goal posts. done.
This shows the arrogance of Software Engineers towards the work of other people. Sure, I agree with you that a new (automating) system should not mimic 100% the old paper-based system, but you do learn the main notions of the business from experts, not out of creative thinking of an SWE in an ivory tower.
Also a 3'' ring binder should not be the result of DDD, please read E. Evans again.
If you reach 99% automation, that is great, but usually you want part of the old employees still be getting along with the system. In quite some businesses you have certifications, not about the color of papers, but about relevant safety and procedural steps in the business. That is what the domain story telling should be about.
The point is that you want part of the old employees still somewhat getting along with the system.
The best part is that the process he is describing is just having a team of analysts taking to the domain experts to determine what should get built by a bunch of software devs. That is just DDD with extra steps and specialization following a more wastefall system.
Yes, I can fully understand how a bunch of business analysts would come up with 3'' of a meticulous manual how the current process is supposed to work. But again, that is not DDD, it is not what E. Evans had in mind. Degrade the business analysts to management consultants and let the SWEs learn a few core principles from the domain experts (not business analysts). If the result is 3'' of manual, you have run too many meetings or not focused on the essentials.
yeah, nice feel good judgy comment; I figured out what needed to be built by actually doing the job for a few weeks, then I just went and built what they needed; not what they asked for or thought they wanted. They never asked for any additions to the system again for 14 years. I actually got invited back to work on version 2 of the system about 15 years later, as my initial work had been adopted for every newsroom in the company. I made good money ripping out "Spring" and "Hibernate" for almost 9 months to get the performance to where it had to be.
You cannot come into a complex domain and understand/implement it in a few weeks.
This is by definition not a complex domain. There would be no reason to apply things such as DDD on a similar domain.
You are describing something of the complexity that might be ... CRUD with a few business rules. Not all domains are like this.
It is more like a "Domain Expert" and people behavior criticism.
DDD guides you to find your domain's:
How you try to achieve this is up to your work.
DDD also encourages a lot of OOP practices, like by using Aggregate roots, your class/structs are not just a data holder but actually a real Objects.
What is the alternative way for building a domain? Anemic domain model of course. And it has more drawbacks than any DDD modeled project.
Those are not religion rules, you can adjust some of the parts according to your project/domain requirements. I do not know why people complain about DDD a lot, usually it seems like it is not completely understood by the person.
those are all distractions and have nothing to do with writing software, anymore than what wood an electric guitar is made of, or what pickups it has or what kind of tubes are used in the amp; to justify why you are poor at playing guitar. It is easier to chase that voodoo BS than actually face they truth that you just need to practice more because you are not that good at the hard part; actually delivering a song, or an application.
Improving your software design and development skills goes beyond simply "doing more" or "writing more code." While practice and hands-on experience are important, there are several reasons why this alone is not sufficient for continuous growth:
Quality over quantity: It's not just about the quantity of code you write, but the quality of that code. Writing more code without a focus on improving your skills and understanding can lead to bad habits, suboptimal solutions, and an accumulation of technical debt. It's crucial to strive for code that is maintainable, efficient, and adheres to best practices.
Exposure to diverse perspectives: Engaging with the wider software development community exposes you to a range of ideas, approaches, and experiences beyond your own. By participating in forums, attending conferences, joining user groups, or collaborating on open-source projects, you can learn from others, gain new insights, and broaden your understanding of software development as a whole.
Leveraging existing knowledge:The field of software development is vast and constantly evolving. It's inefficient to try to reinvent the wheel or solve every problem from scratch. By studying established design patterns, architectural principles, and existing frameworks, you can leverage the knowledge and experiences of others, saving time and effort while building more robust and scalable solutions.
Expanding skill sets: Software development is a multidisciplinary field that encompasses various domains, such as algorithms, data structures, databases, user experience, and security. By deliberately exploring these different areas and acquiring new skills, you can enhance your ability to tackle complex problems and make informed decisions in your projects.
Continuous learning: The technology landscape is ever-changing, with new tools, languages, and frameworks emerging regularly. Staying updated and continuously learning about the latest advancements is crucial for remaining relevant and effective as a software developer. This includes exploring new paradigms, experimenting with emerging technologies, and being open to adapting your approach as needed.
In summary, while hands-on experience and writing code are important components of skill development, they need to be complemented by reflective learning, exposure to diverse perspectives, leveraging existing knowledge, expanding skill sets, and engaging in continuous learning. By embracing a holistic approach to growth, you can enhance your software design and development abilities and keep up with the evolving demands of the field.
Sure, but please note that DDD does not require OOP. You could even realize the domain in e.g. Haskell (of F#). What you really mean is part of OOAD (object-oriented analysis and design), but keep in mind that the stories written down should be understandable by the domain experts, not just by business analysts.
Spelling out the objects is part of encoding the solution. The result of DDD is knowing the ubiquitous language, the main agents and main actions. Another crucial part is recognizing domain boundaries, i.e. where the ubiquitous language changes meaning. Separating the implementation at domain boundaries keeps you from designing god objects (i.e. big objects that are used for everything, but are hard/impossible to maintain or update).
this is just a bunch of regurgitation of religious mumbo jumbo, none of that stuff gets your project across the line, it gives you something to work on other than the actual problem.
I think the root issue you're actually driving at, see what I did there :), is dogmatism and ideologs. Anything you try and use as a silver bullet will backfire and shoot you in the foot. Following some set of rules, guidelines, or processes blindly, heck even semi-blindly, is a terrible idea regardless of the rule, guide, or process.
I've been at places that practice DDD and I've been at other that don't. They all were successful companies, none of which are successful because of blind dogmatism or ideology. It's because they had humble (enough) and smart (enough) people that were able to find a good (enough) process and practice that continued to produce success.
If your process is not producing success, regardless of what it is, your process needs to change. Good enough can become great over time, if changes to processes and practices are based on team collaboration and insight. It is also an ongoing process, especially true when team composition changes but also true when it doesn't.
Dogma can go both ways. It's important to judge a person based on if they're willing to take constructive feedback and learn from it.
Lots of people in this industry can't. An example is a consultant that's convinced ALL consultants are scammers. They're the ONE and ONLY good consultant. EVERYONE else sucks!
It's impossible to have a constructive conversation with someone like that. They know everything. You know nothing. When they make a mistake it's always someone else's fault. Or there is always some logical innocent reason for the mistake. If you make a mistake you're a idiot and there is never ANY excuse for it.
It's a toxic attitude thats bad for this industry. And unfortunately there is something about our industry that seems to attract people like that. Which is so strange to me since critical thinking should be the primary skill that we all have.
This is so true.
The silver lining is I think a lot of the consumer base is starting to identify the smoke and mirrors that come with many "consultants"
I empathize with the sediment that ego is a battle we just all fight within our space.
My favorite saying is
" You win some. You LEARN some."
its also toxic to sling ad homien attacks at someone instead of their ideas, especially when you go on to say you agree with their ideas and that you just do not like the way the person said them. not much more "toxic" than that.
To be honest, your post seems like a rant without any learning I can see. Permanently quoting someone's job title seems rather rude.
I am a developer myself and I believe every developer should strife to be part of the DDD. It is quite common that nobody knows exactly what the domain, it's terms and definitions etc. actually are. It is something you have to figure out during the project. I made the experience that some of my best and on point code was written once I had actually understood the domain which was mostly a team process.
I have worked at almost 100 different companies, small < 10 people all the way up to 250K+ people and never once have I ever seen "domain expert" as a job title.
By design, DDD is implemented as a waterfall ( or series of waterfall ) process. All the "agile" wording and ideas were added in a later edition of the book when it was the current fad silver bullet.
If TDD, DDD and all ???DD reactions to their shortcomings were the actual silver bullets we would have objective quantitative evidence that they actually worked, none of that exists, because they are not the silver bullets their authors and adherents claim they are.
Because "domain expert" is not a job title but a skill.
Where it is written in the DDD book that it should be implemented wit waterfall in mind? I might have read a different edition then. DDD only defines a few rules around mapping your donain an not the process you use to do this. It doesn't matter if you use waterfall/agile or something else to do the mapping.
They are not silver bullets, but they help a great deal. Also, some of them are easy to measure. Eg, measure the test coverage of a project with TDD and one without it.
I've read only your TL;DR for now, and already I feel I have learned more about DDD than I did since the start of my career.
Incredibly well written 👋🏻
I debated commenting because I find this post a tad arrogant, as it makes strong claims based on anecdotal evidence while also at the same time failing to understand some of the key concepts about DDD. I didn't want to give it more visibility by replying, yet here I am. We all fail in some ways, I guess.
One of the most important things you should understand is that DDD is about continuously communicating with stakeholders and refining your domain model. Having a big, immutable design built upfront is a huge red flag, and it's a classic waterfall scenario you should be trying to avoid. DDD is a continuous and collaborative process, it's not the result of some analysts creating hundreds of pages of almost useless docs.
Another important failure in your anecdotes is that what domain experts say must be interpreted, not taken as the definitive truth. Everyone has some sort of bias, and often the perception of how a domain works is altered by how things used to be done: do something wrong a thousand times, and you'll start to think it's the right way to do it. Going back to DDD being a collaborative effort, you should not take anything for granted: if a domain expert says X about your domain, your job is to understand why they say that, and figure out if there's some sort of bias that is conditioning them into thinking that. This is especially important if there's some sort of "legacy", be it a previous software or even a non-digital version.
Failing to model the domain properly together will inevitably result in a final product that is miles away from expectations or any sort of binder you may have had at the beginning. To me your post screams you need something to blame for some failures, and because someone told you you were doing DDD while clearly you were not (or maybe for some reason you convinced yourself you were doing it), now DDD is your scapegoat and we have another "considered harmful" BS article.
Finally, I urge you to understand that DDD is not really about software. It's about communicating and working together.
no all that "iterative communicating" was added later when "agile" became the new shiny thing; and new revisions of the book(s) were published; because you know, money.
I know I was there.
Then why is it not called "Iterative Communication Driven Design", instead of "Domain Driven Design". The name contradicts your apologetics, no one needs to go any further than that.
There are grains of truth in your post, rest is your personal experience so I am not going to draw conclusions for an entire industry from it. I agree with you that sometimes the so called "domain experts" just mindlessly repeat/execute what they have been told is a part of the business process without ever thinking about the "why"! Then regardless of whether or not you apply DDD, you will just produce the same mindlessly complicated system that reflects current state, nothing learned, nothing improved and no innovations made.
Or as an engineer you'd roll in thinking you know the domain better than the people that are working in it (sometimes it could be the case), and you'd build what you want not what the users could actually use. In either case, it doesn't move the needle in the right direction. Not quite 40 years, but during my 20 years of being a software engineer and architect, I have seen it done both ways and neither produce good outcomes.
For me the way to build meaningful software that solves actual business problems comes down to developing a sufficiently deep understanding of the business domain I am in. The two best tools I have come across to build that understanding (no matter how imperfect): direct communication with business folks and iterative design of the software (and sometimes you don't need to write code to solve a business problem). Tools like event storming help get different perspectives on the problem space and provide a much needed opportunity to ask the "why", create a sensible language and boundaries to create some clarity! Its in those moments we identify improvements on the current state and try to make peoples' lives a bit better.
The process is messy because people are messy, and to some extent system design will also reflect that but why do we need to chase absolute perfection? If the invoice clerk is used to pink, green and blue copies, may be that's her mental model and we should give her that "comfort" in the system design and see over time if she realises that it can be simplified. This is where iterative design that's driven by the needs of the humans using a system, comes in. Call it domain driven if you want!
Over the years, this is how I have come to understand DDD, its not perfect but its none of the consultanty BS and none of the dogmatic pattern happy wannabe-ism that treats any idea as a religion. I also understand that may be in your context, it didn't work but everyone's context is different and no idea applies the exact same way. You've got to tweak it and adjust it for your context and from what I understand, every DDD author has said as much, unfortunately, as an industry we get pattern happy to easily and no one really argues about the "why".
so all that wall of text to apologetics, and in the last paragraph, you do not really do DDD ...
By saying "you do not really do DDD", you now seem to imply that there is only one true way to do DDD (or software dev in general), the very idea you take an issue with in your article. Good job contradicting yourself! And I am not being a DDD apologist, I don't really care if someone does it or not, I was only sharing my practical experience as an indication that different people in different contexts have different experiences using the same tool but that's not a reflection on the tool itself. But you are 40 year veteran, I am sure you know that!
so you agree you are not doing DDD, because you do not get to decide what DDD is. the authors of the book where it is presented is. They do not sell DDD as what you are any of the other apologists are claiming it is. They sell it as the religion that it is, along side the TDD religion. Your experience with DDD is the same as mine, it does not work, so you do not do it, you do "DDD but". Google "Agile But" to see what that term references. Uncle Bob twists himself in knots redefining "Clean Code" every time something new comes out to incorporate that new thing as well as to disavow previous dogma states when he is proven wrong. Everything that has a name is subject to this; and you prove my point in this comment; you do not think DDD works, because you are NOT doing DDD, you are doing "DDD but - Aman version". I did not write my post about, you, your experiences or any of your strawman arguments. If you want to apologize for DDD and promote "DDD but - Aman style" feel free to write your own article.
I agree there are religious zealots for any pattern and principles in our industry and many of our so called industry leaders don't do a good enough job of communicating the why/why not or when/when not. This has resulted in a lot of mindless cargo culting that some people are now waking up to and responding. This is also something we as engineers need to do for ourselves as well and teach the less experienced generation coming after us, to be critical about silver bullets.
My interpretation from having read both books on DDD hasn't at all been one of religious diktat or that the authors are pushing an agenda or selling it as a miracle cure for software design (though given they have created a good revenue stream around it for themselves but that's just called making a living, nothing wrong with that). As a matter of fact I do get to decide what DDD means for me and my team, no one gets to do that on my behalf not even the book authors. That's indeed the whole point, so yes may be you and I are talking about different DDDs here, but only because I do believe that what's in the books needn't be applied all the same and all the time, one is free to pick adapt the ideas to work in their context. The 2 core ideas of DDD that are put front and centre are Boundaries and Language, if you are paying attention to what lives where, who owns what part of the business processes, what things are called in those bounds and how they are translated across bounds, IMV, you are doing DDD. Whether or not you like it. You don't have to subscribe to anymore of that, you can take it or leave it.
All of this is true of all design patterns, microservices vs monoliths etc as well btw!
saying you baked a cake using "Martha Stewart's Ulimate Birthday Cake" recipe; but then throwing out or changing almost all the ingredients means you did not actually make her cake, you are just stealing their credibility for your own cake recipe, probably because nobody has any reason to care about your recipes unless you tell them it is "DDD". You just want to copy paste the same disproven argument full of logical fallacies just to argue at this point. Done.
"Dogmatic adherence" to anything is idiotic. Process needs to change in reaction to new ideas, tends, preferences, organizational structure, and the market. It is a living idea that should evolve over time.
DDD works far better in some organizations than others but if you have an organization with clear responsibility boundaries built into the actual struct of the organization should absolutely be a factor in your system design.
That is not domain driven design. In fact is mostly .. "based" in contrast to "driven".
In any case, the workflow you detailed does not work. I made extremely detailed design documents in the past and almost always ended up shooting myself in the foot. And hell, I AM the developer.
Nowadays I always leave a healthy dose of wiggle room. It is very dangerous to back yourself into a corner.
"Bethany: Having beliefs isn't good?"
"Rufus: I think it's better to have ideas. You can change an idea." - Dogma - Kevin Smith -1999
Anything that people argue so hard to defends is a belief system.
There is no scientific evidence that any of these consultant created "systems" work, but the anecdotal evidence that exists is very heavily weight to that they do not. Unfortunately, the dozens of projects I have had to rescue that were "DDD" projects and over budget and over schedule is 100%, and not because the people just "did not DDD enough or effectively", exactly the opposite, they DDD dogmatically and doubled and tripled down instead of tossing it because of the sunken cost fallacy and the consultant (that was long gone by the time I was contracted to rescue the project) driving the project benefited more from billing hours and shipping a project in a timely manner. I do fixed bid contracts, I deliver or I do not get paid. The last salary job I had, for 10 years, was just a very long term contract basically, they fired the tens of thousands of consultants and brought the IT staff in house. As usual, I worked myself out of a job eventually, just took way longer because the problems were way more numerous at the scale of a multibillion $ car company.
You share a story about a project you worked on, where extensive requirements gathering and documentation were not useful in practice. The implementation of the system ended up being quite different from what was initially documented. You believe that focusing on the end result, reducing complexity, and collaborating with both technical and end-users can lead to better outcomes.
It's important to repeat that DDD,, is not meant to be a one-size-fits-all solution, and like any methodology, it has its strengths and weaknesses. DDD can be beneficial in complex domains, where a deep understanding of the business is crucial, and can help reduce complexity. It provides a common language between domain experts and developers, helping to bridge the communication gap and improving how people discuss and design solutions that address the inherent complexities of the challenge at hand. Some things are inherently complex, not simply incidentally so due to poor quality code or a bad design/architecture.
That being said, every project is unique, and the approach to software development should be tailored to the specific context and requirements. It's essential to consider a combination of methodologies, techniques, and practices that work best for a particular situation.
Ultimately, the effectiveness of DDD or any other approach depends on various factors, such as the project's complexity, team dynamics, and the willingness of stakeholders to collaborate and adapt. It can be helpful to stay open to different perspectives and continually evaluate and refine development practices based on real-world feedback and results.
tell that to the creator and the evangelists that say it applies to everything.
much like TDD the comments of people that have had success with it as "the way" are "it works best when the domain is small and already well defined"
my 20+ years of experience across dozens of companies and industries and scales is the latter. And if you already have a well defined domain and limited scope, it is just a formal documentation process as part of a waterfall process at that point. And really redundant, because these cases is usually a version 3 or 4 or 8 of a small application or service, so it is just added overhead at that point.
Sounds like you've lived in your own dogmatic echo chamber a little too long, friend. You're blind dogmatism of dropping a vast body of knowledge in favor of "whatever this one guy comes up with" is rather a ridiculous and childish mode of operating.
You blame the bomb blueprints for the choices of some individuals to destroy and kill... You blame ideas, concept, and knowledge for outcomes when it's the people weilding them that are actually responsible. You can't blame the material, the ideas, and the concepts for the outcome of idiologs and dogmatics. It's clearly because they are rigid and refuse to reflect on and improve upon that body of knowledge instead becoming ideologs. It's exactly the same thing you're doing by being dogmatic about throwing OUT all previous bodies of knowledge when you could instead IMPROVE and EVOLVE that body of knowledge.
You'd probably be a great resource for evolving our existing body of knowledge since you are aware of many of the weakness but it's your failure to acknowledge any strength whatsoever in the existing body of knowledge, apparently because you don't like the people using those things to take advantage of people, that makes you immature and ultimately persistently less of a developer and designer than you could be.
Grow up. Blame the people not the ideas. Help us evolve our body of knowledge instead of set it on fire and rewrite, rethink, redesign, everything from scratch. You don't have to nuke the world and start over on a new planet, this planet, at least for now, is still salvageable.
thanks for the ad homien attack, duly noted; blocked
It sounds like you mostly work on small projects few thousand lines of code here maybe 10k there. Working on large projects that span across years is a different ball game altogether. Things like TDD, DDD, and clean coding make a massive impact on technical debt and overall cost.
I don't know, but this article and especially the comments make me want to learn even lore about DDD....
... and maybe combine it with Hexagonal Architecture, CQRS and EDA to build myself a system any developer can pick up 3, 6 or 12 months from now and continue adding business value without needing months of onboarding, or weeks of PRs to get a simple change implemented because nobody knows how it works...
Thanks for spreading the DDD knowledge!
Some comments have been hidden by the post's author - find out more