There are a lot of headaches clients, project managers, and developers can face on any given project. Often, the developers are talking in tech jargon while the clients are talking in business jargon, and both sides lose each other along the way. This miscommunication can spill over to requirement docs. Clients ask for specific things to be included in their final product, while the tech people translate this to match the language they use to develop the project. Besides the language barriers, if developers start with the database and then write the code base, there can be a significant amount of time between the start of the project and the testing phase. The solution? Domain Driven Design utilizing Ubiquitous Language and Test Driven Development. Some of you read that and know exactly what I am talking about, while I probably lost some of you along the way. Never fear, I am going to give you the basics of Domain Driven Design (DDD) and Ubiquitous Language (UB) in this first blog so that when I take you through the benefits of DDD and how one company has leveraged those benefits in my next blog, I won’t lose you along the way.
DDD is not a new concept. It creates a way for developers, project managers, and clients to all speak the same language. This concept, dubbed Ubiquitous Language, is industry/project specific, so that requirement documents use easy to understand terms. Take, for example, a software program designed for a car dealership. Using DDD and UB, the requirement document may contain items such as: “finance person runs credit check”, “customer test drives car”, and “sales person sells car”. All of these requirements are easily understood by all parties because the language mimics exactly what happens in the real world. There is no technical jargon or business jargon, just straightforward talk that anyone can understand.
The one other main thing to understand about DDD is that it does not require a database for testing. This means that the developer writes the code base as data storage agnostic. What is data storage agnostic? The code can retrieve data from any type of database the client or developer decides can best meet their needs.
These two variables (language and database options) are what make DDD special, because it is so different from other ways of developing. Keep an eye out for my follow up blog detailing the specific benefits of DDD and how our company, Amadeus Consulting, is leveraging these benefits to make projects more straightforward for developers and to increase client satisfaction.