The Cost of Code
Today and during the coming couple of weeks, I’ll be writing on topics that are all somewhat connected to each other. They all are going to be about long-term consequences of our decisions in software development. This is the first email in that short series, and it’s about the cost of code. 1. The question This email is inspired by a question I received to one of my Pluralsight courses.
Integration Testing vs Failing Fast
There’s another question I wanted to address with a separate email. This time, it’s about the choice between writing an integration test and relying on the fail fast principle. 1. Preamble This question is for a section of my Unit Testing book (section 8.1.3, to be precise) where I discuss integration testing versus failing fast. In that section, I mentioned the guideline for choosing appropriate integration test coverage for a business scenario:
Is Enum an Entity or a Value Object?
I received an interesting question recently: is an enum an entity or a value object? 1. The Enumeration pattern Let’s start with defining an enum. An enumeration (enum for short) is a type that contains all possible values of that type. The simplest example in C# is this: public enum Grade { A = 0, B = 1, C = 2, D = 3 } For simple situations, a simple enum is fine, but in more complex ones, it’s better to introduce a custom class to avoid switch statements like this being scattered across the whole code base:
Exposing implementation details in class names
Today, we’ll talk about exposing the class’s implementation details in its name. 1. The question This topic came up in a question about the CQRS pattern, but it’s equally applicable to other patterns as well. Here’s the gist of it: Why does DatabaseRetryDecorator expose its structure and implementation details in the class name? What if I change the class’s implementation and replace the decorator with something else?
Domain-Specific Nulls
I’ve received an interesting question that I thought I would share with you. It’s about the article I wrote some time back: Nulls in Value Objects. 1. Preamble The gist of this article is the choice between ValueObject<Nullable<T>> and Nullable<ValueObject<T>>: You should prefer ValueObject<Nullable<T>> if the null (or empty) value is valid for the given value object. Otherwise, you should go with Nullable<ValueObject<T>>. For example, a phone number can’t be an empty string.
Specification pattern in the DDD trilemma
The specification pattern is something I’ve been writing about since 2016. Today, I’d like to talk about it in the context of the DDD trilemma. 1. Specification pattern To recap, you can think of specifications as of domain classes that categorize other domain classes. A specification answers the question of whether a domain object meets some criteria. The main benefit of the Specification pattern is that you can reuse that knowledge (of whether a domain object meets some criteria) in different scenarios and therefore adhere to the Don’t Repeat Yourself principle.
Where's the line between types of dependencies in the domain layer?
I received an interesting question about separation of concerns which I thought I would share with you: In your courses you often refer to the CSharpFunctionalExtensions, and use it from within the domain model. In your view what makes this acceptable vs let’s say a DataAnnotations attribute, or a package like FluentValidation, where is the line? This is a great question, but let’s set some groundwork first before we answer it.
How tooling leads developers away from good unit test design
I wanted to share this short tweet thread with you: Graham makes a very on-point observation here. Unit testing is hard. As hard as writing code in general. Moreover, the quality of the test code matters as much as the production code. Trying to outsource unit testing to code generation tools implies that you don’t consider tests important, which is a wrong mindset altogether.
On domain model purity
Today, I’d like to talk about one of the 3 pillars of the DDD trilemma: domain model purity. If you haven’t read about the DDD trilemma, I highly recommend that you check out this article: Domain model purity vs. domain model encapsulation. 1. What is domain model purity? I gave an extensive definition in this article but in short, you can think of it as of lack of certain types of dependencies in the domain model layer:
Unit test naming policies: which one is better?
Let’s talk about unit test naming policies. I’ll first describe where I stand on this topic and we’ll then discuss the Given-When-Then pattern. 1. Preamble I wrote about how to name unit tests in my Unit Testing book. I’ve also extracted this particular topic into an article that I (somewhat provocatively) named "You are naming your tests wrong!". In short, I advocate against rigid unit test naming policies. The reason is that your unit tests should describe your system’s behavior in a way that’s understandable not only to programmers, but to non-technical people too.