What is CRUD?
Quite often we see criticism of Create-Read-Update-Delete solutions. There are tons of blog posts why CRUD is inferior to Domain-Driven Design. I have probably written a few of them in my life. It seems like everybody is doing proper DDD and advocating doing it so where’s the problem? I haven’t seen so many domain driven systems in the wild. If you take a look at DDD tag on StackOverflow you’ll see that most of questions are actually concerned with CRUD, not DDD solutions. So what is this CRUD?
It is an architectural style where the centre of the solution (or the lowest layer, depending on your perspective) is a package containing structures that represent data in the real world. These structures are usually mapped one-to-one to database tables using some kind of Object-Relational Mapper (NHibernate, remember?). Upper layers contain stateless service classes that operate on these structures.
Modern CRUD architectures borrow much of the terminology from Domain-Driven Design which confuses many people. You can find entities (a fancy name for a data structure), repositories (another fancy name, this time for Data Access Object pattern), domain services (place where the logic lives in CRUD) and so on. Please bear in mind that in the rest of this post I will be using these terms in context (and meaning) of CRUD, not DDD.
So, is CRUD inferior to Domain-Driven Design, like I suggested at the beginning? Not really. It has different architectural properties. It probably doesn’t scale as well when complexity grows. CRUD earned it’s really bad opinion because it can become quite messy if you don’t understand it’s essence.
And the essence of CRUD is Create-Read-Update-Delete. Period. You can do these four and only these forur operations on any entity. As you can see, there is no support in the architecture for establishing one-to-many relations. To be precise, there is no support for entities having collections of other entities. Why? Suppose you have a Parent entity that contains a list of Child entities. If you add a new Child entity to the collection, what should happen? It could be translated as “Update the Parent, Create a Child and AddRelation between Parent and Child” but also could be translated as “AddRelation between Parent and Child”. There is no language in CRUD to define logical relations between entities (like in DDD between aggregate root, entities and value objects) that can help to deal with such ambiguities.
What you can do is stick to many-to-one side of relations if you need them. Looking from Child’s perspective, the aforementioned operation would be unambiguously translated to “Create Child” if child entity doesn’t exist yet or “Read Child, Update Child” otherwise. The reference to it’s parent is part of it’s definition so Update operation can deal with it. But what if you need to get a collection of children of some entity? You can always use repository to query the data source, right?
To sum up, if you happen to build a simple system, please don’t throw DDD at it. It would be both an overkill and a mess. Remember, CRUD can be you friend if you understand it’s rules and follow them. Don’t try to make it DDD-Lite.
