The DDD class taxonomy travels well; the conversations do not travel at all

A post on dev.to titled "Stop Pretending To Do Domain-Driven Design" argues that developers, and AI agents generating code, have reduced domain-driven design to a set of code artifacts: entities, aggregates, repositories, factories, services, value objects, bounded contexts and domain events ^[1]. It matters because the author's own diagnostic splits the practice cleanly: you can do DDD without the tactical patterns, but not without the strategic work ^[2].

Eight nouns ^[1]. For a lot of teams that is the entire visible surface of the practice, and it spreads because it is teachable and checkable in review. The author points at social platforms, where the trend is popularised by the content creator with three years of experience who will explain distributed microservices and DDD in the same thread ^[14], and at course descriptions promising you will structure your application around domains and entities, establish aggregate classes with appropriate behaviours, and interact through events and commands ^[5]. Nothing in that sequence requires talking to the people who do the work being digitised, which is what the author says DDD actually is ^[11].

Vaughn Vernon's Red Book, as quoted in the piece: DDD is about discussion, listening, understanding, discovery and business value, all in an effort to centralize knowledge ^[3]. Vernon also names the substitute: DDD-Lite, the tactical patterns employed mostly for a technical payoff ^[4]. The author's analogy is test-driven development. Writing unit tests with assertions, mocks and stubs is not TDD, because TDD is about using testing as the process by which the software gets designed ^[13].

The consequence is cost, not taste. Strategic DDD, in the author's framing, is deciding which parts of the system matter and which do not ^[6]. On a trading platform for a bank, customer profile management and authentication support the system without delivering differentiated value ^[7]; no user cares whether they can upload a profile image, and every user cares if a trade is miscalculated and money vanishes [c7b]. What the author reports seeing instead is entities, aggregates, services, repositories and factories used to build something as basic as a profile management module ^[9], with the whole pattern set applied everywhere once an organisation declares it is doing DDD ^[10]. Vernon again: businesses regularly put too much effort into glorified database table editors, and CRUD-based solutions treated elaborately are too expensive ^[8]. The author's field test is blunt: are your supportive products built simply, on budget, quickly, saving time and money? In his experience, that is not the norm ^[15].

The salvageable part is a forecasting question rather than a folder structure: can you predict which parts of your system and code will change most often ^[12]? The implicit premise is that the parts delivering the most differentiated business value are exactly the parts most apt to change ^[12]. Machinery that makes change cheap belongs there. The profile picture upload gets CRUD ^[7].

Worth watching: the piece is one opinionated post, self-described as something you could classify as a rant ^[16], so treat the prevalence claims as experience reports rather than measurement. The author explicitly includes AI agents in the trend ^[1], which makes the taxonomy cheaper to emit than ever and the modeling conversation no cheaper at all. The check that costs nothing is provenance: for each aggregate name in your codebase, whether it came from a domain expert or from a tutorial, and whether the supportive modules around it are hitting their budgets ^[15].