Are static methods good or bad? Over the course of my career I did a full circle on this topic. In this article, I’ll try to describe this evolution and the reasoning behind it.

1. Oh, cool, static methods!

After learning about static methods for the first time, most people (myself included) become enthusiastic. That’s understandable because static methods have some pretty compelling benefits:

  • They are convenient — You can call static methods whenever you want, without injecting all those pesky dependencies the lead developer keeps telling you about.

Compare this code:

public string GetOrderAmount()
decimal amount = ShoppingCart.GetAmount(); …

I was re-reading some old articles about always-valid domain models, including this one form Jeffrey Palermo and the response to it from Greg Young. I highly recommend that you read them both if you haven’t already. This post is another response to Jeffrey’s article, which will hopefully complement Greg’s one.

1. Not-always-valid domain model

It may seem strange to write a response to an 11 years old article, but the concepts it talks about are timeless and still relevant today. Moreover, I still see people asking the same questions raised in that article and coming to the same conclusions, which in my opinion are…

I’m continuing the topic of domain model purity. This time, we’ll look at it with regards to getting the current date and time.

By the way, be sure to subscribe to my email list. Not all discussions fit the format of a blog post (including some shorter takes on the topic of domain model purity vs completeness). I send those out as emails instead.

Time as an ambient context

I received a couple of interesting questions to the previous post that I thought I would address with this article.

Here’s the first one:

I have some thoughts about abstracting time and what the best solution…

I’ve been meaning to write this article for a long time and, finally, here it is: the topic of domain model purity versus domain model completeness.

Domain model completeness

In this article, we’ll talk about a trilemma that comes up in each and every project. To best describe this trilemma, we need to take an example. Let’s say that we’ve got a user management system with one use case so far: changing the user email. Here’s how the User domain class looks:

public class User : Entity
public Company Company { get; private set; }
public string…

How to unit test an abstract class? Or a whole class hierarchy that depends on that abstract class? Let’s see.

Unit testing an abstract class

Imagine you work on a people software in a university and have the following code:

public class Student
public string Name { get; set; }
public void EnrollInCourse(Course course)
/* ... */
public string GetSignature()
return $"Best regards,\r\n{Name},\r\nStudent at MIT";
public class Professor
public string Name { get; set; }
public void ApplyForFacultyJob(Faculty faculty)
/* ... */
public string GetSignature()
return $"Best regards,\r\n{Name},\r\nProfessor at MIT";

In this example…

In this post, we’ll make a deep dive into the DRY and DAMP principles and will talk about the false dichotomy around them.

The DRY and DAMP principles

The DRY principle stands for “Don’t Repeat Yourself” and requires that any piece of domain knowledge has a single representation in your code base. In other words, in requires that you don’t duplicate the domain knowledge.

The DAMP principle stands for “Descriptive and Meaningful Phrases” and promotes the readability of the code.

DRY vs. DAMP: the dichotomy

You can often hear that people put these two principles in opposition to each other. …

The use of mocks in unit testing is a controversial topic (maybe less so now than several years ago). I remember how, throughout my programming career, I went from mocking almost every dependency, to the “no-mocks” policy, and then to “only mock external dependencies”.

None of this practices are good enough. In this article, I’ll show you which dependencies to mock, and which to use as is in your tests.

What is a mock?

Before jumping to the topic of when to mock, let’s discuss what a mock is.

Mock vs test double

People often use the terms test double and mock as synonyms…

This article is about 3 things that can make or break any software project.

Now, I know what you might be thinking right now — what is this, Cosmopolitan? Also, why three, and not five or twenty?

I know, the title sounds cheesy, but I do believe that these 3 things have a detrimental effect on any software project. And when it comes to purely technical reasons why a project succeeds or fails (that is, not taking into account possible organizational issues), these things form about 90% of those reasons. …

Vladimir Khorikov

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store