The thing that was most new to me was the types of the subdomains concept. We know that any business can be divided into domains or subdomains, we've met several types of subdomains, and we've been operating this for a long time. But DDD specifies them and suggests, that we work differently with any of them.
In DDD there are three types:
* Core subdomain(s). This is what makes your business different from others. This is your competitive advantage, and the one where you are the experts. This subdomain is the most complex and volatile. It shall be developed in-house and you shall invest in its architecture so that it remains maintainable. What brings your company money?
✨Example: Imagine our business is a call center — Unique logic of calls distribution.
* Supporting subdomain(s). This is what you have to have to make your core subdomain work. Maybe there are solutions on the market, but they do not satisfy your requirements. So the company decided to develop it in-house. The complexity of such shall be lower than the core subdomain.
✨Example: internal CRM
* Generic subdomain(s). This is what every company in the industry should have, and they do it the same way. If it's possible, this functionality will be bought as SaaS or it can be outsourced.
✨Example: authentication system
Good developers shall understand the business of the company well enough. To be able to identify (together with business experts) the types of subdomains. Then we know where we should invest our time and resources. We can explain to ourselves and the stakeholders that it does not make sense to continue to develop our own in-house authentication system.
Subdomain types may change. With time, you can discover that the one that was generic yesterday brings the company more money. So it makes sense to take care of it, and the way we deal with it may change.
Subdomains are, as well, a good way to split the work between teams. No two teams shall work on one subdomain.
In general, I would rate this book
7/10. Have you read it?