Tag DDD
Having the domain model separated from the persistence model
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?
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.
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. 1. 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.
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.
Domain-centric vs data-centric approaches to software development
In this post, I’d like to make a comparison of two approaches that prevail in the world of (mostly enterprise) software development: domain-centric and data-centric. If you read my last post (or any other post, quite frankly), you might have noticed I personally gravitate towards the domain-centric approach. Although this article is intended to be an impartial one, keep in mind that my bias can leak out. Domain-centric vs data-centric approaches The main difference between the two approaches is in the way people adhering to them treat software.
DRY revisited
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.
