Now that I have given you the basics in my previous blog, Domain Driven Design: Give Me the Basics where I covered Domain Driven Design (DDD) and Ubiquitous Language (UB), I want to go into the “so what”. Like I said, DDD is not a new concept, so why am I bringing it up now? Does anyone really care? Well, once you hear the benefits, you might care. Our company, Amadeus Consulting, definitely cares since they are leveraging the benefits of DDD to make projects go more smoothly, make outcomes more flexible, and increase client satisfaction.
By using DDD, projects go more smoothly because the developers and the clients are speaking the same language. Say for instance, a client wants to develop a software and mobile program for car dealerships. The client would include things like “customer takes test drive”, “customer applies for financing”, and “sales person sells car” in the requirements document. With DDD, because these requirements are laid out in terms everyone can understand, it is not necessary to translate anything into technical jargon. Because the language stays the same and is easy to understand through all stages of the project, the developers, and the project managers can quickly and easily communicate project status and any updates and/or changes. The key is that everything is described and acts as it does in the real world. In this way, everyone involved can visualize the outcomes. Projects go more smoothly because of better communication.
At Amadeus Consulting, we ramp DDD up another notch with “test driven development”. By using DDD, developers can test the end results of the code by assuming all the prerequisites are met. They then know if the code will work before full development, thus saving time. To use the dealership example again, the end result of the program may be “salesperson sells car”. The developer can test what happens at the end of the code by assuming all the prerequisites and just testing “salesperson sells car”. This means that specific information like a customer name, type of vehicle, and cost of vehicle do not need to exist to test the code. The developers can ensure that the code will do what the client wants and five years from now the developer could re-test and re-configure with anything new.
DDD also makes end results of projects more flexible. Before, I mentioned “data storage agnostic”. This is the idea that data can be stored anywhere because the code can work with any database. This is awesome because the developers and client can work together to figure out what database best meets the client’s needs. In addition, if the client’s needs change over time, moving the data to a different database will not affect how the code works. This is especially true with more and more businesses wanting to store their data in the cloud. There are different options for cloud data storage and as a company changes the options change, and DDD creates the best flexibility.
By using DDD and test driven development, projects go more smoothly, communication is better, and the end result can be easily customized for the customer’s current and future needs.