Is Domain-Driven Design Beneficial for Software Development?
Para acceder a post original click aquí
Over the last couple of years, the interest in Domain-Driven Design (DDD) has increased, Eric Evans noted in his keynote at the recent DDD eXchange conference in London. He believes we are in a time when developers care more about design, partially because we are working more with distributed systems in which models have a higher value.
Evans believes that one of the reasons DDD is still interesting is because we challenge the assumptions underlying it and have had some good results from this. One way of challenging it is to ask questions such as:
- Does DDD help us deliver software faster or better in some definable way?
- Does DDD help us adapt; can we apply the same principles in an IT world that has changed radically in the last 10 years?
- Do the DDD principles help us innovate; are we doing software design better now because these principles help us to find new ways of doing things?
The DDD principles depends on us thinking about models in a certain way, but in Evans’ experience, people too often reduce a domain model to a UML diagram. Although a data schema is an important aspect, it’s not what he is referring to by a model; the various dynamic aspects are also important. Completeness or a description of reality is not a goal; a model should have a narrow focus and be useful in some specific way. He compares it with a Mercator projection which is a model of the world created specifically for navigation but not especially useful for other purposes.
Often, Evans finds that people get stuck when they trying to create models so elegant, that there is now way to get there in one step. Instead, he believes we should deliver models that aren’t that great and start to use them. We can then learn and create better and better models until we finally have a model that we can be proud of.
Evans emphasizes that we shouldn’t narrow in on what models look like. His view on models include a lot of distinct model paradigms:
- Object orientation with a focus on things which in turn bring actions. This was the main technique when Evans wrote his book about DDD.
- Event sourcing, where the sequence of events becomes central and the things are secondary. It has many advantages but also some drawbacks. Evans notes that event-oriented modelling seems to fit a lot of business processes very well.
- Relational is a set-oriented model suitable for problems in which a lot of things are compared or related to each other. Evans notes that we should use it for what it was meant for, not just a bad way of persisting OO data.
One example in which Evans believes DDD has helped us innovate, is Event Sourcing. It is a different style of modelling a domain with a shift in thinking, from changes in data structures into what’s happening. In certain domains, discrete events relating to things that have happened can be very valuable.
Another example Evans mentions is Event Storming, which has had some impact in recent years. It starts from the context of events happening in a domain and looks at events as fundamental elements in a model. He believes that Event Storming and Event Sourcing, two techniques that both is working with events, may create a positive effect when used together.
Next year’s DDD Exchange is scheduled for late April 2017 and registration is open.