Domain Driven Design

Value Objects are a great way to explicitly capture concepts within your domain. They are immutable, always in a valid state, provide behavior, and are defined by their value. This sounds a lot like Messages (Commands, Events) that are also immutable and should be in a valid state. However, exposing your Value Objects by using them within Commands or Events can have a negative impact on your ability to evolve your domain model. YouTube Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in this post. Value Objects… Read More »Leaking Value Objects from your Domain

Always having your Domain Model in a valid state means it will be predictable. You’ll write less defensive code or conditional code because your domain objects will always be in a valid state. Using aggregates is a great way to encapsulate the state with behavior to keep the state valid. Using factories to create your aggregates is key to having a valid state from the very beginning. Here’s how you can create an always valid domain model. YouTube Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in… Read More »ALWAYS Valid Domain Model

The mainstream thought on Domain Driven Design is about Entities, Value Objects, Aggregates, Repositories, Services, Factories… all kinds of technical patterns. Because of this, most don’t think they need Domain Driven Design because it’s complicated for their domain. Why would you need all that “stuff”? Well, maybe you don’t! In a large system, modeling your domain, defining boundaries, and how they relate is far more important than concerning yourself if you’re using the Repository pattern correctly. YouTube Check out my YouTube channel where I post all kinds of content that accompanies my posts including this video showing everything that is in this… Read More »STOP doing dogmatic Domain Driven Design