-1

I am learning Event Sourcing in my spare time. I see lots of references to 'CRUD type systems' online. I understand a CRUD type system to be:

1) A database driven system (website or application) i.e. a system that supports creates, reads, updates and deletes. A domain model is not needed in this case.

or

2) A system that "should" (a bit opinionated) have a domain model, however all the domain logic is contained inside application services I.e. the domain model is anemic.

However, recently I have read references to systems that do not use Event Sourcing as CRUD. For example, if I implemented CQRS with a reltional database on the write side (not an event log) and MongoDB on the read side, then is this a CRUD system?

What exactly is meant by a CRUD system? Does this depend on who I talk to?

  • I don't really know if that's helping, but I used to say CRUD referring to web applications which have little to no extra value other than providing an UI to a database table. As Doc Brown suggests I suppose the meaning is context dependent. – Arthur Havlicek Sep 26 '18 at 19:47
2

Does this depend on who I talk to?

Yes

What exactly is meant by a CRUD system?

Robert Harvey has the right idea - a crud system is just domain agnostic storage. That might mean durable storage (on disk, or in a database), or ephemeral storage (the models that we use in memory).

In the context of CQRS and Event Sourcing, the term is often use to distinguish problems where the benefits of separate reads and rights (CQRS) and temporal query support (Event Sourcing) won't offset the extra complexity those patterns introduce.

The point being if the intention is simply to store somebody else's data (saving files where we never look at the contents, or caching local copies of data where the book of record is outside of your system), then we should consider carefully the benefits of solving the problem with simple technologies.

For example: consider the source history of your project -- are temporal queries important there? yes, absolutely. So it may be worth having a detailed history of everything that is happening. But does your package manager care about the historical details of hello-world-1.0.0 ? Not so much.

  • If you are starting a new system and using principles from DDD, then should you always use Event Sourcing instead of CRUD? – w0051977 Sep 27 '18 at 15:14
  • +1 for the reference to temporal queries. – w0051977 Sep 27 '18 at 15:30
4

CRUD is an acronym for Create, Read, Update, Delete, the four fundamental operations of a database system, and that's all it is.

I suppose you could describe a system as CRUD-like. Where I currently work we are having ongoing discussions about this, because the existing system is very database-operation-centric, and while this is very convenient for the programmers, it's not of much help to the users, who are working in a business domain and would prefer a workflow-style application that is tailored to their business operations instead of thinking about adding to and deleting records from a database.

Further Reading
Create, read, update and delete on Wikipedia

  • +1 for the reference to workflows. If a system does not use event sourcing and is built with a rich domain model then does that make it CRUD? I believe the answer is no. – w0051977 Sep 26 '18 at 18:49
  • Those concepts are unrelated. You can have a data access layer that works in a CRUD-like fashion and still have a rich domain model and event sourcing. – Robert Harvey Sep 26 '18 at 18:50
  • Thanks. I believe you are saying that the resistance of event sourcing is irrelevant when describing a system as crud or not. – w0051977 Sep 26 '18 at 18:53
  • 1
    The only thing that needs to be present to describe a "system" as CRUD (for some arbitrary definition of "system") are the operations Create, Read, Update and Delete. – Robert Harvey Sep 26 '18 at 19:02
  • If a system uses an event log/event store on the write side (append only) and nosql on the read side then I guess it could be described as non CRUD. – w0051977 Sep 26 '18 at 19:33
0

CRUD is short for Create/Read/Update/Delete capability. It is using problem domain naming rather than programming domain naming which is preferable as best practice.

Functions with those name are usually public methods on Data Access Object (DAO) and will roughly map on to SQL programming domain of Insert/Select/Update/Delete.

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.