That said, a well commented sample app should at least reveal some of these decisions and give you some direction in terms of matching up your domain model with the technical patterns used to implement it. (as some say, the best DDD sample is the book itself!) DDD is much more about the process than it is the code. I hope that keep it up to date with new insights.The difficulty with DDD samples is that they're often very domain specific and the technical implementation of the resulting system doesn't always show the design decisions and transitions that were made in modelling the domain, which is really at the core of DDD. I’ve been using and improving this definition in my workshops for probably 6 or 7 years now, so I hope that makes it hardened enough to be useful for both newcomers to DDD and seasoned practitioners. This definition is specifically focused on DDD as a discipline, that is, design as something you do, activities with a set of guiding principles. That makes DDD notoriously hard to define. Many methods that people now consider core to DDD, such as EventStorming, didn’t exist when the book was written. It doesn’t prescribe methods, or practices, and even the patterns in the book 1 are meant to be illustrative rather than a final set. It doesn’t have rules of how to do it, and is open to new interpretation. You don’t apply DDD everywhere, you do it where it will have the most impact.ĭDD is not prescriptive. It considers design from the micro-level of code and design patterns, to models and their language, to communication and relationships between models, to the large scale reasoning about systems of systems. The model and language should be in sync with our understanding of, and changes in the domain, through continuous refactoring towards deeper insightĭomain-Driven Design presents an all-encompassing view on software design.an internally consistent language and model) by the system designers A complex domain can not be efficiently expressed as a single universal model and language, and must therefore be separated into Bounded Contexts (ie.The model must not shy away from explicitly expressing the essential complexity of the domain.The understanding is expressed in a model, shared between experts and designers, which express the problem space (as opposed to the solution space).That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous).
Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts.Domain-Driven Design is a software design discipline centred on the principles that:
0 kommentar(er)
