Practice
DDD (Domain-Driven Design) has many unresolved problems, which may have been partially discussed at seminars. However, ideal solutions for any task don't exist — they are always just approximations. There are many methodologies: today OOP (object-oriented programming), AOP (aspect-oriented programming), DDD, and TDD (test-driven development) are popular, and tomorrow new approaches will appear that will be actively discussed.
But, unfortunately, new methodologies are developed very slowly, and many of them are still based on concepts from the 90s. They often don't solve problems 100%, because every solution creates new challenges. So you can't rely exclusively on a single methodology — you need to take only the best aspects from each, applying them to solve specific tasks.
This approach, a symbiosis of different methodologies, an eclecticism of best practices, allows for the most effective handling of problems that arise in development.
However, in my view, DDD (Domain-Driven Design) attracts three types of people.
The first type is programmers without an IT education, or without a higher education at all. Such specialists often look for simple solutions to complex problems and follow trendy development fads without fully understanding the essence of the methods and concepts. They may feel that DDD is something mandatory to use, simply because it's popular and discussed at conferences, in articles, or among colleagues. As a result, they apply DDD without deep analysis in areas where this methodology isn't always justified or effective, which leads to unnecessary complications in the project.
The second type is programmers who have never worked on personal projects (that generate profit), and have spent their entire career working "for someone else," at large companies. These people generally follow corporate standards, and if management or colleagues decide to adopt DDD, they follow these instructions without questioning or analyzing their applicability to the specific project. For such specialists, what matters isn't optimizing the project or the end result, but completing the task within the prescribed methodology. This often leads to increased development time, the project becoming harder to maintain, and the business suffering, when it could have achieved its goal faster with a more flexible approach.
The third type is competitors, who use DDD as a tool to slow down the development of other companies. By promoting the idea that DDD needs to be implemented everywhere, regardless of the loss of time and profit, they deliberately make life harder for their rivals. DDD can indeed slow down the development process, especially if a company isn't yet ready for such a deep overhaul of its approaches. That's why competitors may actively promote DDD in the hope that their opponents will get stuck in complex technical weeds, while they themselves move more flexibly and quickly, applying other methodologies.
Thus, without a deep understanding and a thoughtful approach, DDD can become a drag on business. Following a single methodology, such as DDD, without critical analysis leads to the project becoming more complicated, deadlines being extended, and ultimately profit declining. A more rational approach is to combine elements of different methodologies, choosing solutions that best fit specific business tasks, rather than blindly following one popular concept.
Comments