Archives

There’s an interesting guideline I’ve been meaning to write about for a long time. I call it Storing information in its highest form.

Let’s talk about when to use which collection type and why.

Today, we’ll discuss the following guideline: you should use the most generic types possible for arguments and the most specific types possible for return values.

Let’s talk about modeling of relationships, including the dreaded many-to-many relationships, in a DDD way.

My new online training course about Encapsulating EF Core Usage went live.

Does the primitive obsession anti-pattern apply to collections? In other words, should you introduce a custom class for a collection?

Today, we’ll discuss a question that relates to my Unit Testing book: how to assert the state of the database?

This article is inspired by a tweet that I thought would be a good topic for discussion: should you abstract your database?

Today, we’ll talk about an important question: how does the application database fit into the concept of Always-Valid Domain Model?

In other words, is the database part of the always-valid boundary or should you consider it an external system and validate all data coming from it?

There’s an interesting controversy between two DDD topics: the Specification pattern and the Always-Valid domain model.

Today, we’ll discuss an interesting use case of handling nulls in value objects. Should you put null inside the value objects themselves or decorate those value objects using the nullable reference type notation (? or Maybe)?

My new online training course about Validation and DDD went live.

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.

UPDATE 5/13/2021: the course has been published, check it now here: Validation and DDD.

I’m working on a new Pluralsight course on the topic of validation and DDD, with the help of the FluentValidation library and .NET data annotations (attributes). So expect a couple of posts about validation in the near future.

Today, we’ll discuss how to best handle unique constraint violations.

Today, we’ll talk about the new C# 9 feature, Records, and whether or not they can be used as DDD value objects.

I’m continuing the topic of domain model purity. Last time, we talked about domain model purity in the context of getting the current date and time. Today, we’ll discuss it with regards to lazy loading.

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.

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.

This post is about where to put the equality comparison logic: under the test or production code.

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

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

Need to change validation rules but have pre-existing data that doesn’t follow the new rules? In this post, we’ll talk about how to do that properly.

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.

In this article, we’ll review the types of unit testing dependencies. This is more of a reference article, to which I’ll be referring in future posts. Still, this topic is important for establishing the common vocabulary.

My new online training course DDD and EF Core: Preserving Encapsulation went live.

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

In this post, we’ll talk about whether or not you should use assertion messages in tests.

In this post, we’ll discuss an interesting question about whether the concepts of Entity and Value Object are the same.

Combining bulk operations with Domain-Driven Design is a tough problem. In this article, we’ll look at why that is so and discuss ways to marry the two.

This is a continuation of the article series about some more advanced error handling techniques.

This post describes some (more) advanced error handling techniques. I’ll probably do a series because this topic is large and there’s quite a few things that need to be cleared out, but we’ll see.

Giving your tests expressive names is important. Proper naming helps understand what the test verifies and how the underlying system behaves. In this post, we’ll take a look at a popular, yet inferior naming convention and see how it can be improved.

I’m writing a book called Unit Testing: Principles, Patterns and Practices.

This post describes a common problem: how to deal with multiple domain events if raising of one of them must negate the others.

In this article, I’d like to discuss one particular aspect of exception handling relevant to CQRS and the decorator pattern.

There’s a question that I didn’t cover in the course and that was raised at least twice since then: when to validate commands in CQRS?

I published an online course about CQRS a couple months ago, and since then I realized that there are some topics I didn’t put enough emphasize on in that course, or didn’t cover at all. In the next several blog posts, I’m going to fill this gap.

This article is a response to a reader’s question. The question posed an interesting problem that I think will be interesting to a wider audience.

This is an article about how two DDD patterns contradict each other.

My new online training course CQRS in Practice went live.

In this article, we’ll talk about ORMs and lazy loading.

Today, we’ll discuss the difference between identity in the DDD sense and database primary keys. We often mix the two together but are they really the same thing?

Today’s article is an answer to a reader’s question about the use of Value Objects to represent the identity of an entity.

This is the final post in my series about unit testing anti-patterns. This one is about non-determinism in tests.

I’m continuing my unit testing anti-patterns article series. Today, we will talk about overriding methods in classes-dependencies.

My new training course Domain-Driven Design: Working with Legacy Projects went live.

Good news everyone! NHibernate 5.1 is released with the support of .NET Core 2.0 and .NET Standard 2.0.

This is another post from my unit testing anti-patterns article series. Today, we will talk about code pollution.

I haven’t done one of these for a while. This post is a review of a code submitted by a reader.

I was asked a question recently which I find quite interesting. It is actually a part of a code review request (which I’ll cover next week) but I decided to elevate it to its own blog post.

I’m continuing the series about unit testing anti-patterns I started a couple months ago. This article is about leaking domain knowledge to tests.

To TDD or not to TDD? Is this question even relevant or maybe it’s enough to just write tests, no matter before the code or afterward? Let’s see.

This news went mostly unnoticed but that’s actually a big one, at least for those of us who uses NHibernate as their primary ORM: NHibernate 5 now supports async IO bound operations.

I got a suggestion recently about using .NET structs to represent DDD Value Objects to which I repeated what I’ve been saying and writing for several years now: structs are not a good choice for DDD Value Objects. But then I realized that I never actually dove into the details of why it is so.

So here it is, the blog post where we’ll talk about using .NET Value Types (structs) as DDD Value Objects and what effect it has on the domain model, performance, and mapping the model to the database using ORMs.

My new training course Refactoring from Anemic Domain Model Towards a Rich One went live.

Last time, we talked about making private methods public in order to enable unit testing. It’s not the only way people expose implementation details to the outside world for unit testing purposes, though. Today, we’ll look at a similar anti-pattern: exposing private state.

I’m starting a new series about unit testing anti-patterns. This post is the first article in that series.

When it comes to unit testing, one of the most commonly asked questions is: how to test a private method?

Today, I’d like to write about a simple and reliable way to implement domain events.

In this post, I’m answering a reader’s question about how to combine an optimistic locking and automatic retry.

This post is about a better implementation of Value Object.

In this post, I’d like to talk about what I think is one of the most damaging attitudes a company or a person can have in the field of software development: short-sighted perspective.

I’m back to the regular posting schedule. No more game development, at least for now.

If you read this blog regularly, you know that I usually write about DDD, functional programming, and enterprise software development best practices in general. These are the techniques I enjoy talking about, as well as applying them in my own projects. However, there was another field I always wanted to try myself in. That is game development. The ability to write my own games was the reason why I started learning to program in the first place. And I believe many programmers had this motivation behind their careers as well.

But let’s start from the beginning.

This post is about how to work with information that is spread across multiple microservices.

In this post, we’ll discuss Value Objects. Specifically, when to introduce them into your code.

In this post, I’d like to talk about naming and Ubiquitous Language.

I apologize to everyone who’s waiting for my response to their code review requests. I was busy dealing with some personal stuff the last couple of weeks. Moving forward, I’m going to maintain a one post a week schedule where "regular" articles would take turns with code reviews. This article is a regular one, so the one next week would be a code review.

Today, I’d like to talk about IEnumerable and IReadOnlyList collection interfaces. We’ll discuss which of them is preferable and in what circumstance.

In this post, we will explore a common design problem: implementing a Main Something property. There’s an equally common solution to this problem which is sub-optimal in most cases.

When I started this blog, I had one idea in mind: create some sort of repository of programming principles and practices so that I myself and other people would have an easier time navigating around them. That’s a nice goal to aim for but I noticed that when it comes to the actual process of writing code, having such a repository is often not enough.

This is a continuation of the topic of error handling. We’ll discuss what an exceptional situation in code actually is and see some examples of it.

In this post, we’ll look at some practical examples of error handling. We will see whether it is better to use exceptions or the Result class to deal with errors.

Today’s topic is about interfaces for repositories. Should you introduce them? Or maybe it’s better to use repositories as is? Let’s see.

This post is about some bad practices in using automappers.

Today, I’d like to talk about the (sometimes subtle) difference between 4xx and 5xx response codes when programming a RESTful API. I’ll try to show when to return what code (400 or 500) and introduce a simple way to implement this logic on the server side.

This topic might seem trivial, especially if you look at all other articles that have beaten it to death already. But I would still like to make a couple of important points here. So, how long should a single method be?

Today’s topic is about custom exception types. That is whether or not you should write your own exception types to throw in different situations.

Today’s topic is gonna be about OOP, FP, and object-relational impedance mismatch. The goal of this article is to show how object-oriented and functional paradigms deal with relational data stores.

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 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 post is a showcase for the Singleton design pattern. In contrast to the common belief, Singleton is not inherently bad and I’ll try to show you in what circumstances it is a good choice.

In this post, I want to take a closer look at the practice of defensive programming.

In this post, I’d like to write about a pretty common discussion in DDD circles: should one have the domain model separated from the persistence model? In other words, should you map your domain objects to the DB tables directly using an ORM or would it be better to use a separate set of Data Access Objects (DAOs) instead?

In this post, I’d like to write about the personal traits we all possess. Namely, I want to talk about being proud of your code and trying to impress people with it.

In this article, I’d like to write about a powerful technique that can potentially save you a lot of work and make your code much more concise: representing reference data as code.

In this post, I write about 2 ways of representing a link to an aggregate.

In this post, I’d like to talk about a mechanical approach to domain modeling. It sometimes arises when teams start applying Domain-Driven Design (DDD) principles to their projects and when they don’t have enough experience with it yet.

Code correctness verification is not an easy task. At the same time, it’s one of the most important problems we have when we build software projects. In this article, I’ll compare 3 different ways of achieving code correctness.

While such classes as Person and Money are pretty intuitive and can be easily attributed to either entities or value objects, the choice isn’t so obvious when it comes to classes that are internal to an aggregate. That is classes that aren’t roots of their own aggregates but rather parts of existing ones.

It’s a small post with an overview of the articles I wrote during this year.

Regions feature in C# is frowned upon by many. There are good reasons for that. In this post, I’d like to discuss why exactly you should avoid using them.

Do you need an ORM for your project given you use a relational database? And not just some lightweight like Dapper but a big one: NHibernate, Entity Framework, Hibernate? I’d like to address this question with this post.

The concept of NoSQL databases has been around for a while, but there still are quite a few misunderstandings regarding the topic of relational SQL vs NoSQL databases. In this post, I’d like to clarify the most common misconceptions and discuss the primary use cases for each of them.

When you enter some field as a novice, there is a lot of stuff you must learn in order to become proficient in it. The learning path can usually be broken down into 4 stages of competence which you can traverse in 2 different ways.

I’d like to wrap up the "Most valuable software development principles" article series with this post.

Another software development principle I advocate you follow is making implicit assumptions explicit in your code. Let’s see what that means.

Today, we’ll look at Coded UI and White automation frameworks in terms of building an automated UI test suite for a WPF application. We are going to compare them from different points of view, such as performance, the ease of getting started and maintainability. You will see which of these two frameworks suits what kind of projects and how to make a decision in your particular circumstances.

The fail fast principle is underlying for many other software development practices. It comes out so often that it’s hard to cover all its appearances in a single article. Nevertheless, that is exactly what I’m going to do here :)

Another principle we should follow when building a software project is the DRY principle. The abbreviation stands for Don’t Repeat Yourself. While it seems pretty straightforward and intuitive, this principle is more than meets the eye. Let’s see how it is so.

This is another post on the most valuable principles in software development.

You might have heard of a guideline saying that we should aim to achieve low coupling and high cohesion when working on a code base. In this article, I’d like to discuss what this guideline actually means and take a look at some code samples illustrating it. I also want to draw a line between these two ideas and show the differences in them.

Last week, we discussed the differences between stubs and mocks. Today, we’ll talk about some general tips and advice that regard to TDD and writing tests in general.

In this article, I’d like to discuss the differences in using stubs and mocks and show how you can abandon using mocks even in the cases where you need to verify that objects interact with each other correctly.

In the previous articles, we discussed what causes the pain while writing unit tests (mocks), and how to make TDD painless (get rid of the mocks). Today, I want to set the groundwork and discuss why mocks actually cause so much pain to us, developers.

Unit testing is good at checking the correctness of your code in isolation, but it’s not a panacea. Only integration tests can give us confidence that the application we develop actually works as a whole. They are also a good substitute for mocks in the cases where you can’t test important business logic without involving external dependencies.

Last week, we nailed the root cause of the problems, related to so-called test-induced damage - damage we have to bring into our design in order to make the code testable. Today, we’ll look at how we can mitigate that damage, or, in other words, do painless TDD.

I’m going to write a couple of posts on the topic of TDD. Over the years, I’ve come to some conclusions of how to apply TDD practices and write tests in general that I hope you will find helpful. I’ll try to distil my experience with it to several points which I’ll illustrate with examples.

The third most important software development principle is Encapsulation.

Today, I’m going to discuss the KISS principle. I consider it the second most valuable software development principle.

I’m starting a new blog post series about the most valuable principles in software development. Not that I think you might not know them, but I rather want to share my personal experience and thoughts on that topic. The order in which I put those principles reflects their significance relative to each other, as it appears to be in my opinion.

That is quite a large subject and I’m going to dilute it with articles on other topics, so it might take a while.

Okay, let’s start.

Today, I’d like to discuss the differences between interfaces, abstractions and .NET interfaces, as well as what the term "implementation details" means.

I guess most developers heard the guideline stating that, when designing methods, you should return the most specific type and accept the most generic one. Is it always applicable? Let’s try to look at it from different perspectives.

We often think that relational and NoSQL databases are somewhat incompatible. But what if we could use both within a single domain model? I’d like to show how to combine SQL Server and MongoDB together and discuss what benefits we could get from it.

Today, I’d like to discuss a particular case with validating input data using NHibernate event listeners.

In this article, I’d like to clarify the differences in DTO vs Value Object vs POCO where DTO stands for Data Transfer Object, and POCO is Plain Old CLR Object, also known as POJO in Java environment.

Did you think about how we think? How do we come up with a solution and how we decide whether it’s good or bad? It seems like a very interesting topic, so let’s dive in!

If you use Resharper, you must have been using some (or maybe most) of its features already. But what I see a lot is that some really useful features are left unattended. I want to describe those lesser known yet very useful features that can help you in your day-to-day work.

Input validation rules are often taken for code contracts. In this post, I’ll try to cover their differences and show what their common use cases are.

Most of the development principles are applicable to any software you might develop. Nevertheless, there are some differences between building a reusable library and an enterprise application. Those differences often become sticking points as we try to apply experience gained in one type of project to projects of the other type.

The differences between shared library and enterprise development grow from differences in requirements and lifetime support cycle.

Did you think about what traits make developers great? Which one is the most valuable for the companies they are working for?

While there might be quite a few of them, I believe there’s one that employers value the most. I also believe getting that characteristic can drastically increase your value as a software developer.

Microservices have got a lot of traction last year. It’s always interesting to read about success stories other people have; they tend to inspire you to try this new trend out in your own project.

However, there are several traps you can fall into if you follow this trend without deep understanding of its fundamentals. Today, I’ll share some bad practices I saw one particular company used on its way to adopt microservices architecture.

I’d like to discuss some common pitfalls of async/await feature in C# and provide you with workarounds for them.

Microsoft has released async/await feature in .Net 4.5. It’s a really great stuff as it significantly simplifies one of the most painful areas - asynchronous programming. Before that, Task Parallel Library (TPL) and Parallel LINQ (PLINQ) were released in .Net 4.0. They address problems with parallel programming - another painful area in .Net.

I often see programmers struggling with a question when to use each of these features. Let’s step back and recall what does it actually mean to be asynchronous or parallel.

It’s the first post on the blog I’m starting today. The idea to start blogging was with me quite for a while, so I decided to give it a try.