Domain driven design are big topic, so here’s my summary of the domain driven design to reflect my current understanding of the domain driven design and the various thoughts on the Domain Driven Design
Why should I spend times and effort on Domain Driven Design
- Software industry are young and growing very fast, however, there are few things that are important and less likely to change, one of those things is domain driven design. It gives the company the competitive edge by creating models for the specific business domain, so it’s easier for the software to evolve, at the same time, I don’t think it would change or being replaced by something else completely in the near future (knock on wood)
- blhalhblhab
Key Concepts
- Ubiquituous Language
It provides ways/tools for every one to design the software with the underlying models of the business domain.
As software getting bigger/large, it’s harder to build/create domain model that could be used shared between multiple teams. Hence, the Bounded Context comes in the picture where it divides the big monolithic context into multiple different contexts so we can design the unified model in that context
For example, book model in different context such as “conceptual and proposing a book”, “Managing the book authorship and editorial process”, “Design book layout, including illustrations”, “shipping physical book to resellers and customers”
What’s next step?
- lkajkljalkjslkjaslkjas
Questions
- What to do with database schema that shares between single domain model that is used in different context?
- What to do with cross cutting concerns? Like Identity and access, solution -> use segregated modules and let application service takes care of security and object translation
- What about caching, transaction management, etc…? should that be extracted into its own library? context?
- How different domain interact with each other? By sending message to different modules?
