My new course Building a Pragmatic Unit Test Suite for Pluralsight went live.
In this post, I’ll show a simple way to get to know if your domain model is properly isolated.
In this post, we’ll discuss the Law of Demeter in the context of immutability.
Aggregates carry out many important functions. One of them is maintaining consistency boundaries. In this post, I write about the requirement of global email uniqueness and how it is related to aggregate invariants.
Validation and DDD can be a tricky combination. How to perform validation in a way that doesn’t lead to domain knowledge leakage?
In this post, we’ll take a look at domain services: what differs them from application services and when it is preferable to use one in addition to an application service.
I’ve been using the term “domain model isolation” for a long time already but just recently realized that its meaning might not be as obvious as I thought. In this post, I’ll try to describe what it means to properly isolate your domain model and why it is important.
In this post, I’ll write about a couple of thoughts regarding what domain logic is and how to distinguish it from other types of logic.
In this post, we are going to look at what to do if you are not able to treat some concept in your domain as a Value Object and have to make it an Entity. TL;DR: create a nested Value Object inside that Entity and relocate as much domain logic to that Value Object as possible.
I was reviewing the list of topic ideas lately and found this question in the discussion to my DDD in Practice Pluralsight course. While I answered it – somewhat briefly – in the discussion thread, I think it’s worth a separate detailed blog post. The question itself goes like this: “Can you have a collection of Value Objects abstracted as a Value Object itself?” Or, in other words, can you represent a collection as a Value Object?