Tag DDD
Types of CQRS
CQRS is a pretty defined concept. Often, people say that you either follow CQRS or not, meaning that it is some kind of a binary choice. In this article, I’d like to show that there is some wriggle room in this notion and how different types of CQRS can look like. Type 0: no CQRS With this type, you don’t have any CQRS whatsoever. That means you have a domain model and you use your domain classes for both serving commands and executing queries.
DTO vs Value Object vs POCO
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.
When inheritance is not an inheritance
Nowadays, notion of composition over inheritance is quite widely accepted. It basically means that when designing a software, you should prefer composition to inheritance, although you could use either one. But what if several classes do have some common attributes? Do you need to extract a base class for them? When inheritance is not an inheritance In OOP, inheritance stands for "is-a" relation. That is, a class A can be treated as a sub-class of a class B if A *is* a B in a way that makes sense for our particular domain.
Value Objects explained
I’ve already written about base entity class. Today, I’d like to continue with Value Object base class I use in my projects. Also, I’ll share some best practices regarding Value Objects implementation. Value Objects: what is it? An object that represents a descriptive aspect of the domain with no conceptual identity is called a Value Object. Value Objects are instantiated to represent elements of the design that we care about only for what they are, not who or which they are.
Don't use Ids in your domain entities!
How often do you see code like this in your domain model? public void Ship(int orderId, int customerId, string address) { Shipment shipment = _existingShipments.Single(x => x.OrderId == orderId); if (shipment.CustomerId == customerId) { // Do something } } Seems pretty good, doesn’t it? Well, it doesn’t. I’ve already pointed using Ids in domain entities as a bad practice, but I see developers - even sophisticated ones - write such code over and over again, so this topic definitely deserves a separate article.
Entity Base Class
If you follow DDD principles, you eventually end up creating a base class for all the domain entities. It’s a good idea as it allows you to gather common logic in one place. When you decide to do that, you inevitably face the question of what exactly should be included in that base entity and how it should be presented.
