DDD and avoiding CRUD

Question

It seems that on most articles I read, CRUD is to be avoided in DDD as we are dealing with modeling business process and not data. However, I find it hard to see not to have CRUD operations on certain entities. For example, in a school grading system, before teachers can grade students, a SchoolYear has to be present or perhaps a GradingPeriod. I can't see how we can manage GradingPeriods without CRUD. Could someone enlighten me on this?

Answer 1

A very important part of DDD is bounded contexts.

A bounded context is a delimited part of an application where terminology is consistent. DDD is very seldom the correct approach for an entire application. Therefore we usually divide an application in separate bounded contexts. Within each bounded context you can have a different pattern. Say CRUD for a BC that has very little domain complexity and DDD for an area with high complexity.

CRUD is not to be avoided per sé. CRUD is to be avoided when there are complex business rules in play. DDD is to be avoided when you're providing forms over data with very little rules.

So, it is possible to have an application with some parts doing simple CRUD and other parts with a richer domain model.

That's one part of the equation, to get back to your original question:

"before teachers can grade students, a SchoolYear has to be present or perhaps a GradingPeriod"

You imply here that creating a schoolyear is a CRUD operation, you're probably already thinking about "INSERT INTO schoolyears ...". That is a possibility (and you could do it that way using bounded contexts, see above). Using CRUD for that part is OK, if there's not a lot of domain logic going on.

However, you need to determine whether "inserting a new schoolyear" is not actually technical jargon for "opening a schoolyear". DDD emphasizes language. If you determine that opening a new schoolyear has a lot of rules attached and requires complex code, you should probably put it inside your domain. So if your domain experts keep telling you about how they "open a new schoolyear", then you should model that behavior in your domain. So instead of calling it "InsertNewSchoolYear", you should call your method "OpenNewSchoolYear". Whether that eventually does an insert in the DB is irrelevant, you want to capture that specific domain knowledge in your model.