Domain-Driven Design Quickly

I started reading Secure By Design recently. Its premise is that Domain Driven Design (DDD) is a useful tool to help write secure software. I didn't know much about DDD, so when Secure By Designed mentioned Domain-Driven Design Quickly as a good resource, I ordered a copy. It arrived a couple of days later and it was so short (less than 100 pages) that I decided to set down Secure By Design temporarily and pick up DDD Quickly.

I had already gotten most of the way through the DDD part of Secure By Design before the book arrived so that definitely helped in grokking it. I had a good basic understanding and background. DDD Quickly is a 100-page book that is intended to be a summary of Eric Evans' 500-page book so obviously, it just hits the highlights and is light on detail. So if you already have some idea of what DDD is and need a refresher I would highly recommend it. If it is your first exposure to DDD it might be like drinking from a firehouse and a little light on details.

Why DDD?

Why use DDD? Well according to the Secure by Design book DDD is a useful tool for improving security. When is it appropriate? When is it not? I like that Secure By Design lays that out very clearly. Sometimes the complexity in our software comes from technical requirements: we are manipulating lots of data, we are doing image processing, we are on a real-time system and have really tight constraints, we are collecting data at really high speeds, etc. However, there are other times when the complexity lies instead in the domain, which many of us may refer to as "business logic".

Example

As an example, I recently worked on a packaging project. Think of something similar to Amazon. A customer orders something on a website, and an order gets created and entered into a database. In a warehouse somewhere there is a machine that takes that order, and kind of like a vending machine dispenses the correct products into a box, seals it up, and sends it out. The vending machine gets controlled by PLC which controls all the physical moving parts.

I was charged with writing some code to provide a user interface for the PLC. The user needed some way to start and stop processing orders. They also needed a way to tell the PLC which products were in which slots in the vending machine. The user also needed a way to manually control some of the hardware for troubleshooting. In addition, the software was responsible for querying the web service, deciding which orders were actually fillable, queueing orders, updating the web service when orders were completed or rejected by the PLC for some reason, and keeping an inventory tracking up to date as it dispensed.

In this example, the PLC handled all the complexity of the hardware and timing. My program didn't have to worry about that. It did have to worry a lot about orders, order status, and inventory levels. Those are all "business logic" and that logic was quite complex. I didn't use DDD at the time, because I didn't know about it, but it certainly would have been useful.

The Domain Model

At the heart of DDD is the domain model. The model is a shared understanding of the problem domain between the domain experts and the programmers. The goal is to come up with a model that both sides can understand that accurately represents the important parts of the domain and is easy to implement in software. Part of the challenge is making everything unambiguous and making all the behaviors very well-defined and understood by everyone.

Ubiquitous Language

One of the things that I have been very much aware of about DDD for a while is the concept of the ubiquitous language. Sometimes you'll hear people refer to domain-specific languages or DSLs, which are very closely related to the ubiquitous language. The idea is that the domain experts and the software engineers speak different languages and that can lead to confusion. The goal is to come up with a ubiquitous language that they can share. The key is that in the ubiquitous language, there is no ambiguity. The same terms should be used throughout the domain model, the user interface, function and variable names, database tables, etc, and those terms need to have the same unambiguous meaning each time they are used within the domain. The reason the terms need to be unambiguous is so that they are easier to implement in the software. This helps to prevent bugs and security holes.

Entities and Value Objects

Entities and Value Objects are some of the main building blocks of DDD. This part of DDD I hadn't really known about or explored before. An entity is basically something with a unique identity but whose properties might change over time. An example would be a customer. Over time they grow older so their age changes. They may move so their address might change. They could get a new phone number or e-mail address, yet through all that, they are still the same person. They have the same identity. Contrast that with value objects, which are things like an address, phone number, date of birth, etc. In those cases, all we care about is the value. If you have 2 addresses, they are equal if the values of the addresses are equal. Whereas you can have 2 different customers with the same address and even the same phone number, and they are 2 distinct customers and aren't interchangeable. The customers are only equal when their identities are equal.

Immutability

Immutability is an interesting topic in DDD. Value objects are usually immutable. Once you create one, you can't change it. You can create a new value object of the same type but you can't change the value of an existing one. Entities however have to be mutable. For example, if a customer gets a new address, you want to be able to update the customer object. In that case, since an address is an immutable value object, you would just create a new address to replace the old one.

This concept may be difficult for LabVIEW programmers to grasp because we don't typically think about immutability. In LabVIEW, we basically get immutability for free because we typically pass everything around by value. A mutable object in LabVIEW would be some sort of reference like a DVR. With a DVR, if you have a DVR pointing to some value, another process can change that value on its own without your process having any control. Immutability avoids that scenario.

The Rabbit Hole Goes Deeper

DDD Quickly covers a lot more than I am covering here. There is also an entire 500-page book by Eric Evans that goes into even more detail. Hopefully, this article gives you a small idea of what is involved in DDD and when you might use it.

Help Applying DDD And/Or Writing More Secure Software

If you want help implementing DDD or are interested in learning about how to write more secure code, let's talk. Use the button to reach out.