3

How can you know if something is "pure CRUD solution" ("just CRUD")? It seems complexity is a hard thing to define for the various DDD proponents. Everyone says if it's "just CRUD" you don't need DDD. What does "just CRUD" mean? Every application I've made has CRUD operations somewhere.

I realize there are different types of patterns within DDD and much is a mindset (common vocabulary), as you have to know the domain regardless, but if a company is going to invest in a Business Analyst and the whole nine-yards, I'd like to know when that is overkill. "Just CRUD" is pretty vague.

I have seen this, Is Domain Driven Design useful / productive for not so complex domains?

In there "If there's not much behavior, which is to say, you're mostly storing data, and not acting on that data, there may be much less value in building out that domain layer." This is "just CRUD," but I've never seen a system that didn't "acting on that data" either.

For example, Let's say someone is building a Hospital Application, lots of stuff there, essentially a small city. That's complex, but I don't know why other than the sheer amount of things that have to be accounted for, but end the end it is CRUD.

Intuitively, I know a hospital application complex, but I do not know why it is complex in the sense that DDD mean complexity.

What is a non-complex example?

Edit: Sorry, I forgot to say that I know what CRUD means.

4

What does "just CRUD" mean?

Just CRUD means that your application doesn't have any authority of its own; that it is simply collecting and repeating information that is passed in to it. This is typical of a database or a journal, where the app is just being used as a mechanism to store and serve data.

This is "just CRUD," but I've never seen a system that didn't "acting on that data" either.

Yes - there is normally some component that is just storing/retrieving data. The real question is: is there anything else, in front of the data store, that is making authoritative decisions about what gets stored and what doesn't?

That something will usually be a domain model; which has within it the business rules that determine what should be stored.

This talk from Greg Young in 2012 might help.

What is a non-complex example?

My current go-to example is determining whether or not a bank can charge a customer late fees. It does this by reviewing a model of the account activity (deposits and withdrawals, changes in preferred customer status, and so on), applying domain logic, and writing out message that indicate what fees can be charged.

  • What is a non-complex example?. Let's say you have a standalone application that just gather traces. Log tracker. Basically the inputs are redirected to some data store and outputs retrieved from the same data store. The app is a mere bridge between a logs producer app and a data store. There could be some complexity just like queries by date ranges, aggregation, but probably it can not justify a DDD approach. – Laiv Jul 8 '17 at 9:05
  • I guess one way would be to say, "Just Data Entry"? And that means that's all the program does other than validation. All decisions on what to enter happen outside of the system and there is no logic that aids in that in the system? – johnny Jul 10 '17 at 14:45
3

CRUD stands for Create Read Update Delete.

So an application that just offers four methods to create a resource, read it, update it and delete it by its id is a CRUD application. It doesn't contain any domain logic except perhaps some validation that the saved entity is valid. But all the interesting logic lives outside, in the callers of this application and a CRUD application just acts as a datastore.

It's also often said that an application like that implements an anaemic domain model.

An example of a simple CRUD application is when you want to store and retrieve some data but you have some restrictions on the data that can't be directly fulfilled by an off the shelf database or key value store. You can then create a simple CRUD application that's basically a wrapper around your chosen storage solution but adds the extra requirements that your data store cannot fulfil on its own.

  • Thanks. I figured it wasn't a hard and fast line, but more subjective. This helps. – johnny Jul 10 '17 at 14:42
1

Perhaps one heuristic for an application being not 'just CRUD' is that the interests of a user of the application are often in conflict with the interests of the application sponsor.

So a 'pure crud' application may have been made to help someone do their job of recording some information. The user wants to record the information accurately and the application sponsor wants to help with that. There's no conflict.

But with a game, an individual user may want to win easily, while the application sponsor may want the game to be known as challenging to attract more players and prevent easy wins. Or in an e-commerce system of course one class of users would like everything to have a 100% discount. The application sponsor probably doesn't want that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.