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.
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?
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.
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 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.
- 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.
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.