architecture-paradigm-domain-driven

# The Domain-Driven Design Paradigm Design for the future, build for now. DDD is modeling a business in the business's own language. The goal is not to avoid structure. It is to avoid structure you cannot back out of, and to defer structure you do not yet need. ## What DDD Is Ubiquitous language, bounded contexts, and a model built by talking to the people who do the work. The measure of a domain model is whether a person in the business would recognize their own job in it. ## What DDD Is Not Clean Architecture. Mandatory layering. A mapper between every tier. A count of design patterns applied before the first line of business logic is written. These are DDD-adjacent choices. Each has its own justification, and none of them is entailed by DDD. Wanting to decouple an API from the domain is a good reason to add a DTO. "This is what DDD requires" is not, because it does not. ## Strategic Design Is The Core The building blocks are not the point, and this is not the repo's opinion. Evans said so himself, ten years after the book, about the book: > "things like the entities and value objects [..] [People] come away > thinking that that's really the core of DDD, whereas, in fact, it's > really not." > "I really think that the way I arranged the book gives people the wrong > emphasis, so that's the biggest part of what I do is rearrange those > things." Source: SE-Radio Episode 226, "Eric Evans on Domain-Driven Design at 10 Years" ([video](https://www.youtube.com/watch?v...