Keeping Things Exciting with Domain Driven Design

Communication Breakdown

For a business, having a new web site or web application built is an exciting thing! We thrive on this excitement, our clients thrive on this excitement, and we thrive on our clients’ excitement. And with every project we undertake, we try to cultivate this air of excitement. However one thing that, historically, has made some web development projects seem slightly un-exciting to a business is the idea that developers and engineers can seem to speak a completely different language. Mostly because, in the literal sense, they are working with completely different languages. And in fact this problem can work both ways, as most industries have their own internal jargon that can leave a developer scratching his or her head as much as a client staring at a screen full of code. This phenomenon can create a communication divide that leaves one or both sides of this otherwise exciting equation dissatisfied by the resulting, well, results.

But there is a solution to this problem, referred to as Domain Driven Design (or DDD), which helps tear down these communication walls, and lets the project be exciting again! DDD is essentially the acknowledgement by both sides (the web developers and the members of a given industry, known in DDD as the, “Domain Experts”) that this rift in terminology exists, and the development and adherence to a model of the industry where all relevant terms and elements are defined and agreed upon. This model, and the elements born of the model, create a common ground language that everyone can understand and use to communicate what needs to be communicated.

A Real World Example

If this isn’t yet entirely clear, let me propose an example to illustrate: In the Real Estate industry, there exists a massive database called the MLS (Multiple Listing Service), which hosts virtually all pertinent data about any given property that is or was for sale. Someone in Real Estate might refer to an entry in that database as, “an MLS listing.” Simultaneously, developers too work with databases, but they might call such an entry a, “record in a persistent data store.” But after both create their mutually agreed upon model toward the beginning of the development process, they might agree to simply call these entries, “properties.” Everyone will be on the same page, and clarity will rule the day. This is a relatively simple and, perhaps even obvious, example. But these DDD models can get exceedingly complicated in some cases, with many moving parts, and this approach to design helps make communication and evaluating metrics within a given project far more painless and approachable.

A Model Approach

A Domain Driven Design model is a linguistic compromise, if you will. And this DDD approach is critical to how we work with our clients. We thrive on the excitement felt by all parties when initiating and iterating a new development initiative. Acknowledging that not everyone involved is speaking the same language, and taking the time to develop a model that marries and reconciles these differences helps to alleviate what could otherwise be a significant pain point for both our clients, and for us. And most importantly, it helps to keep the excitement alive! That excitement is what drives us to do what we do, and there’s nothing we love more than sharing it with our clients.