###### tags: `DDD` `cleanarchitecture`

# DDD core subdomains vs Clean Architecture's domain entities

["Learning DDD"](https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/) says that **core subdomains are volatile**.
> ...**core subdomains can change often**. If a problem can be solved on the first attempt, it’s probably not a good competitive advantage—competitors will catch up fast.
> Consequently, solutions for core subdomains are emergent. Different implementations have to be tried out, refined, and optimized.
> Moreover, the work on core subdomains is never done. Companies continuously innovate and evolve core subdomains. The changes come in the form of adding new features or optimizing existing functionality.
> Either way, **the constant evolution of its core subdomains is essential for a company to stay ahead of its competitors**.

While generic and supporting subdomains tend to change less often or do not change at all.
Generic subdomains are often commodities, third-party provided services.

In ["Clean Architecture"](https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164) Uncle Bob says that **the entities, the "core" of the application, is the most stable thing**.

> Entities [...] encapsulate the most general and high-level rules. **They are the least likely to change when something external changes**. [...] No operational change to any particular application should affect the entity layer.
> Business rules are the reason a software system exists. They are the core functionality. They carry the code that makes, or saves, money. **They are the family jewels**.
> The business rules should remain pristine, unsullied by baser concerns such as the user interface or database used. Ideally, the code that represents the business rules should be the heart of the system, with lesser concerns being plugged in to them. The business rules should be the most independent and reusable code in the system.

There's no contradiction here:
when Uncle Bob talks about "stability", it means that the core domain should not be dependent on volatile things like infrastructure details (databases, queues, frameworks, 3-rd party services, external services, ...).

So while a company may (and should) change its core subdomains in order to keep its competitive advantages on the other competitors in the market, it should shape the architecture so that its core subdomains does NOT change because of changes on details like which database we use, which frameworks we adopt, which 3-rd party services we need to integrate with, etc.