{"slug": "stop-pretending-to-do-domain-driven-design", "title": "Stop Pretending To Do Domain-Driven Design", "summary": "A developer argues that domain-driven design (DDD) is being misused as a collection of coding patterns, such as entities, aggregates, and repositories, rather than its true strategic purpose of understanding and modeling business domains. The post criticizes the prevalence of 'DDD-Lite' in tutorials and social media, emphasizing that DDD requires deep collaboration with business experts and focus on areas of differentiated business value. It cites Vaughn Vernon's 'Red Book' to support the claim that tactical patterns alone do not constitute DDD.", "body_md": "Warning: This is an opinionated article and could be classified as a rant if you really want...\n\nThere's a trend by software developers (*this includes AI agents!*) to approach domain-driven design as a collection of useful programming/coding patterns and abstractions:\n\nI see this idea popularized on all the social platforms by *content creator X software developer with 3 years of experience who is an expert on building distributed microservices using domain-driven design.* They can tell you all about creating entities, aggregates, and repositories. And distributed microservices too - as a cherry on the top.\n\nThe courses on popular learning platforms are the same. Here's part of a description from a popular learning platform's course on DDD:\n\n- Structure your application around domains and entities.\n- Establish aggregate classes and determine appropriate behaviors.\n- Interact with your domains through events and commands.\n\nI disagree with this code pattern-centric characterization of DDD.\n\nHere are a couple of questions to consider:\n\nThe answer to 1 is yes.\n\nThe answer to 2 is no.\n\nIn Vaughn Vernon's \"Red Book\" he says:\n\nDDD is about discussion, listening, understanding, discovery and business value, all in an effort to centralize knowledge.\n\nIf you aren't doing these things - you aren't doing DDD. Period.\n\nVaughn also writes about a fictitious scenario of developers focused on these tactical tools - calling it \"DDD-Lite\":\n\nIn fact, they were really using what amounted to DDD-Lite, employing the tactical patterns mostly for a technical payoff.\n\nIn other words, it doesn't matter how many entities, aggregates, factories, services, and repositories you have.\n\n*Side note: This is like saying you \"do TDD\" because you write unit tests and use assertions, mocks, stubs, etc. Sure, those things are useful to know. But TDD is not about individual tests. It's about using testing as a process of designing and building software. It's a higher-level plane of thinking.*\n\nThe strategic aspects of DDD are about figuring out what parts of the system matter and which don't.\n\nFor example, where should you focus your efforts if you are building a trading platform for a bank?\n\nBuilding a trading platform is going to be hard. But at face value, we all know this business will most likely not focus on the first two domains (profile management and authentication). Or maybe I should say *should not* focus...\n\nWhy? Those two domains or systems don't deliver differentiated business value. They only support the overall system.\n\nHave you ever used a trading platform and really cared whether you could upload a profile image?\n\nBut you do care if the trading platform miscalculates your trade and some of your money disappears into the ether.\n\nIn my experience, many (most?) software developers use entities, aggregates, services, repositories and factories to build something basic like a profile management module for their software.\n\nI'll quote Vaughn's book again:\n\nBusinesses regularly put too much effort into developing glorified database table editors. Without the correct tool selection, CRUD-based solutions treated elaborately are too expensive... if the choice is correct, it should save time and money.\n\nLook at the software business you work in. Are your secondary/supportive products:\n\nIn my experience, this is not the norm. If the organization is \"doing DDD\" the norm is using aggregates, entities, repositories, factories, etc. everywhere.\n\nIn a nutshell, DDD is about talking to the business experts who do the job. To the ones who do the real work you are digitizing. If you aren't doing that...\n\nAnother way to think about DDD is that it tries to help us to answer the question:\n\nThe implicit premise here: The parts of your system that deliver the most business value and differentiate your business from others are exactly the parts that are apt to change the most.\n\nSupportive modules & functionality like authentication or profile pictures are probably not the pieces of a trading platform that break and change the most, for example.\n\nYour business has to choose where to focus or it will never get things done.\n\nThis leads to other questions like:\n\nYou could answer this question at the level of code objects like classes and functions. But this level of granularity makes it hard to predict where the most change will be. It's too narrow and in the weeds. It's like predicting that an individual stock will do well over the next 5 years.\n\nDDD answers these questions at a higher level. Bounded contexts and domains correspond to larger pieces of the business. You're making predictions about larger pieces. It's like investing in an index fund. You get a broader view of the overall market and can therefore make much more probable predictions.\n\nHere's where DDD practitioners should focus:\n\nIs it because software developers like to complicate things more than is necessary? Maybe.\n\nIs it because those overseeing the various business domains aren't technical and don't think about Conway's Law? Maybe.\n\nBecause you don't have access to the people doing the job you are trying to improve/solve? Maybe.\n\nIs it because everyone wants to be a content creator and talk about whatever is trendy? Maybe.\n\nIs it because real DDD is non-trivial, requires real-life experience and depends on the context of your business which is hard to replicate, so we turn to things that we can replicate in order to sound smart? Maybe.\n\nIs it because we've had an era of \"easy money\" via low interest rates that have produced companies which were able to waste tons of money by building projects and products in really inefficient ways but that doesn't matter because they could just hire more people and throw more money at them and pretend like everything is okay? Maybe.\n\nI'm not sure how to \"fix\" this. Individuals need to change and help others to change their minds on this.\n\nThis is part of a larger discussion around software developers who over-engineer systems. The code you work on probably doesn't matter that much to your business in the grand scheme of things. The chances that you've over-engineered your code and architecture are high.\n\nBut, misunderstandings exist around agile, TDD, SOA, and you name it 🤷. It's a people problem, as you might say.\n\nEntities and microservices don't answer these questions. Entities and microservices don't mean that you're doing DDD.", "url": "https://wpnews.pro/news/stop-pretending-to-do-domain-driven-design", "canonical_source": "https://dev.to/jamesmh/stop-pretending-to-do-domain-driven-design-2od4", "published_at": "2026-08-12 19:20:00+00:00", "updated_at": "2026-08-12 19:45:38.687643+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Vaughn Vernon"], "alternates": {"html": "https://wpnews.pro/news/stop-pretending-to-do-domain-driven-design", "markdown": "https://wpnews.pro/news/stop-pretending-to-do-domain-driven-design.md", "text": "https://wpnews.pro/news/stop-pretending-to-do-domain-driven-design.txt", "jsonld": "https://wpnews.pro/news/stop-pretending-to-do-domain-driven-design.jsonld"}}