Reference data as code
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.
Link to an aggregate: reference or Id?
In this post, I write about 2 ways of representing a link to an aggregate.
Mechanical approach to domain modeling
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.
Partially initialized entities anti-pattern
The topic described in this article is a part of my Domain-Driven Design in Practice Pluralsight course. In this post, I’d like to talk about the partially initialized entities anti-pattern: anti-pattern that is often used in conjunction with repositories. Partially initialized entities Partially initialized entities are entities which are not fully constructed and returned as a result of some operation, usually an operation of fetching them from the database.
3 ways of achieving code correctness
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.
Specification pattern: C# implementation
The topic described in this article is a part of my Specification Pattern in C# Pluralsight course. Specification pattern is not a new topic, there are many of its implementations on the Internet already. In this post, I’d like to discuss the use cases for the pattern and compare several common implementations to each other. Specification pattern: what’s that? Specification pattern is a pattern that allows us to encapsulate some piece of domain knowledge into a single unit - specification - and reuse it in different parts of the code base.
Classes internal to an aggregate: entities or value objects?
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.
Domain-Driven Design in Practice Pluralsight course
My DDD in Practice course for Pluralsight went live. Why should you watch this course? I’ve been consistently applying DDD principles in my projects for about 6 years now and I can’t express enough how much value Domain-Driven Design has brought to me. The blue book written by Eric Evans was the most influential book I’ve ever read in my career. If you read this book too, you must have noticed that while it provides invaluable insights, it doesn’t tell much about how to implement them in practice.
KISS vs database normalization
In this article, I’d like to share an example of how the KISS principle can go against the database normalization principles and how to make a choice in such situation. The example Some time ago, I had a task which required me to implement linkage between the users of an application and their social accounts. At the time, we planned to add only two social providers - Facebook and Google - but others could be potentially integrated as well in the future.
Entity vs Value Object: the ultimate list of differences
The topic described in this article is a part of my Domain-Driven Design in Practice Pluralsight course. I wrote about entities and value objects some time ago. In this post, I’d like to talk about differences between Entity vs Value Object in more detail. I know, the topic isn’t new and there are a lot of articles on the Internet discussing it already. Nevertheless, I didn’t find any with an exhaustive, comprehensive description, so I decided to create my own.
