| Nope. UML is a language for describing software systems. It's software first. Domain-Driven Design is a focus on understanding the actual concepts of domain experts. So this is people first. As Martin Fowler said, “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” That's much more likely to happen if programmers start with the existing human understanding of the situation. As a contrast, let me describe two terrible code bases I worked on. The first was something built by roving gangs of consultants. It was about donations and corporate matching, but that was hard to tell by the code. It was basically a giant snarl of HashMaps with magic keys that got passed around all over the place, with bits of code fishing out things they needed. It mostly worked, but it was incredibly hard to sort out because the code didn't mean anything. Another is the typical Java enterprise mess. I was once called in to advise on an open-source product that was being built by consultants used to doing banking work. Between being fetched from the database and rendered on the screen, data was copied from object to object 7 different times. ThisBean and ThatBean and DTOFactoryIntializerStrategy. Most of the code base wasn't really about the domain, it was cargo-cult rituals and architectural patterns that had no practical value. Worse, having the domain knowledge smeared out over a zillion objects means that their early domain understanding was locked in, so the code base and the way people talked about the domain drifter further and further apart. At this point I'm a firm believer in Domain-Driven Design. If you really understand how people think about what they do and then build the system in those terms, you'll get a much better code base and a much better user experience. Domain concepts are generally very stable, so your design is less likely to go obsolete. A good example is yesterday's article about building a real-time editing system. They got good code because they really thought about the human experience and then built in those terms: https://news.ycombinator.com/item?id=18220020 |
Your anecdotes are more common with object-oriented languages and poor object-oriented design approaches. Any fool can claim to have discovered a OOD pattern, but a good programmer will not claim to have discovered anything. Instead, she will use the software to express the user's activity and desired outcomes.
That being said, some software languages take more skill and experience to implement a solution than others. Sometimes it is necessary for developers to consider the choice of HashMap over List<?> or worse MyCollection which implements List<?> over an array. These considerations may have created to more types of diagrams (UML, OOD, etc.) that describe software in more an more detail, but what is necessary to express a solution is really subjective and rarely universally understood. You can't sit an inexperienced developer in front of a C++ program and expect them to understand that they are looking at code for a text editor anymore than you could sit them down in front of a collection of DDD diagrams and expect them to build a perfect representation in Java.
We (the royal "We") are looking for a proper balance in design and implementation. That is a work-in-progress: it is the point of this career and won't be captured by single checkbox on one's resume, e.g. "knows UML or not".