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?
I bet you encounter (and use) the term “implementation detail” a lot. But what it means, exactly? And how to see if something is an implementation detail?
This post is about the practice of Structural Inspection in unit testing and why I personally consider it an anti-pattern.
This is a review of the Growing Object-Oriented Software, Guided by Tests book (GOOS for short) in which I’ll show how to implement the sample project from the book in a way that doesn’t require mocks to be tested.
The topic described in this article is part of my Unit Testing Pluralsight course.
When trying to break down unit testing, the bigger picture stays incomplete if you overlook the subject of integration testing. In this post, we’ll discuss how to make the most out of your integration tests with pragmatic integration testing.
Integration tests are tests that, unlike unit tests, work with some of the volatile dependencies directly (usually with the database and the file system). They can potentially interfere with each other through those dependencies and thus cannot run in parallel.
My new course Database Delivery Best Practices for Pluralsight went live.