If they don’t understand this then they are weakening the model. Getting the Developers as close to the source of information gives the highest chance of getting the software right.Įngineers working on the model must understand the change they are making and how they are improving the model.
This may or may not be the details the developers need to complete their work. The Developers are reading the Cliff Notes version of the domain problem. This document is then handed to the Developers. In a typical organization the business domain is documented by a Business Analysis, which records what they think the developers will need. Hands-On Modelersĭeveloper assumptions get shipped to production and sometimes these assumptions are wrong. If so, these are the hints of a complex ideas and the naming to got along with it. Domain experts have the solution to one of the hardest problems in Software Development and that’s they names for all the concepts.ĭomain experts have a term that succinctly communicates a complex idea? Respect the domain experts, the domain might seem simple, but once you start talking to the domain experts, it’s not. Why are accounts in the banking domain opened and not created?
What the point of using two different terms to mean the same thing? Isn’t this idea much like copy and pasting code? They might be the same to start with, but they always diverge over time? There is no opportunity to lose meaning in translation. If we (the engineering team) and the business have the same understanding and use the same terminology there is no overhead to communication concepts. It’s a mental overhead and things are always lost in translation. Translation fractures the language between the developer and the business. Concepts of that are Core to Successful Domain Driven Design Ubiquitous Languageĭomain Experts are developers who can’t code and we are developers who don’t know the domain. We add our own complexity in solving the problem that may or may not be needed. Complexity is in the problem domain, not in our software. Tackling complexity is the heart of software. Andrew Harmel-Law The Heart of Domain-Driven Design
0 kommentar(er)
