![]() Consider the meaning of a particular washing machine model (note: this example will be used throughout the article). Let's imagine a chain of domestic appliance stores. ![]() The same word might have completely different meanings - an "account" can be both a system user account for IT and a bank account for finance. ![]() You might also notice some shared terminology, yet the meaning of each shared term may vary between departments. They are covering distinct aspects of the business, after all. If you take any company and observe communication within different departments, it will quickly become clear each one uses a different language. I will explain why this is not the case as we look into the second essential DDD concept - bounded contexts. The term "ubiquitous" might mislead you into thinking the language extends over the whole domain. The team's already familiar with it anyway, and documentation only requires additional work and continuous maintenance.Īlso, be careful. ![]() While documenting ubiquitous language might be useful in some cases, you should generally avoid doing that. Developers should make sure to accurately translate that to code and avoid introducing any new terminology that would be hard to accustom to by others. The technical team should pay close attention to how domain experts communicate about the business. It continually evolves as the understanding of the domain changes. There is also no point at which a ubiquitous language becomes final. It should be clear, thoroughly defined, well understood, and nurtured by involved parties. When they work together with the technical team to establish a common, rigorous language, one that is unambiguous and effortlessly used, that becomes the ubiquitous language. Ubiquitous languageĭomain experts often have their jargon or a distinct vocabulary. That brings us to the first of the two most significant concepts in DDD - ubiquitous language. It also affects team communication, making sure it's effective with a minimal chance of misinterpretation. It is instrumental in shaping your project, affecting how the implementation is organized and even how the code is written. We will begin with DDD's less technical, strategic side. In the end, we will take a quick look at some of DDD's technical aspects, so developers and architects can start experimenting for themselves. I will provide some examples along the way to make the introduced concepts easier to digest. You will see how to partition projects for an implementation that's understandable, testable, maintainable, and adjustable to new requirements. You will be given some ideas on how to share knowledge and reason about the business domain. The target audience for this article are people usually involved in software projects, such as domain experts, project managers, product owners, clients, UX/UI designers, QA specialists, developers, architects, etc. That makes DDD applicable in many domains and allows its further evolution. Some parts of it are intentionally open to interpretation, while others are more thoroughly defined. The whole team should practice it - the technical staff will fail if other project members don't get involved. While it's not particularly suitable for simple applications, DDD shines in complex domains.ĭDD is not a methodology nor a strict set of rules. As the business evolves, this code should too. This level of clarity makes rigorous documentation unnecessary. The main parts of the code should resemble the language used by domain experts, and be easily explainable to non-technical staff. To paraphrase DDD Comunity, DDD is an approach to software development, aiming to produce an implementation deeply reflecting the core business concepts. You can reap the benefits of DDD with a wide variety of system and software architectures. But as useful as it can be to use them together, nothing is compelling you to do so. Eric Evans coined the term in his book: "Domain-Driven Design: Tackling Complexity in the Heart of Software." A lot of recent interest probably correlates with the rise of microservices, since it provides many practices and patterns for building them effectively. Domain-Driven Design (DDD) has been around for well over a decade, and its popularity keeps on growing.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |