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.
More about Ids in domain entities →
I’d like to discuss some common pitfalls of async/await feature in C# and provide you with workarounds for them.
Pitfalls of async/await →
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.
I/O threads →
Last week we compared Entity Framework and NHibernate from a DDD perspective. Today, I’d like to dive deeper into what Separation of Concerns (SoC) is and why it is so important. We’ll look at some code examples and features that break the boundaries between the domain and persistence logic.
Separation of Concerns in ORM →
This comparison is obsolete. Read the new version here: EF Core 2.1 vs NHibernate 5.1: DDD perspective
There is quite a bit of Entity Framework vs NHibernate comparisons on the web already, but all of them cover mostly the technical side of the question. In this post, I’ll compare these two technologies from a Domain Driven Design (DDD) perspective. I’ll step through several code examples and show you how both of these ORMs let you deal with problems.
Read the comparison →
I often see programmers saying that .NET read-only collections violate Liskov Substitution Principle (LSP). Do they? The quick answer is no, they don’t, because IList interface has IsReadOnly flag. The exception is Array class, it does violate LSP since version 2.0 of .NET. But let’s go through the whole story first.
Read-Only Collections in .Net and LSP →
Mark Seemann brings up a very interesting subject in his post: how to fit Command Query Separation principle in case you have to save a brand-new object in a database and also need the created id back? Sure, you can have GUIDs for identifiers (which have some drawbacks as I’ll show later on), but what if you really need integers?
I’ve been asked the same question for several times, so in this post I’ll share the solution I use for this problem.
CQS with Database-Generated Ids →
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 what exactly should be included in that base entity and how it should be presented.
Domain Object Base Class →
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.
I’ve been in software development industry for 10+ years. Most of this time I worked on various enterprise projects as a developer, lead developer or software architect. I was often asked about architectural decisions I made and what I noticed is that most of my answers were about the same set of rules and principles I discovered on my career path. I’d like to share my experience with others and also to create some sort of wiki I could refer to when I need to describe one of the topics I’ve covered here. I’ll try to expose all my knowledge in a structured and compact way, although sometimes it might be hard to boil all the thoughts in my head down to one or two useful points. But as I’ve already said I will give it a try.