E.g., if you have a look at Meteor's documenation, especially the part on collections (https://guide.meteor.com/collections.html), it is all about the classical MongoDB-like functions to access data which perfectly represent CRUD. It also describes hooks on INSERT/UPDATE/DELETE (https://guide.meteor.com/collections.html#hooks).

This pretty much shows how Meteor sees data: It's a "thing" that can be created, edited, deleted. That's it. It does not live on its own.

E.g., when you design a shopping cart, you can create a shopping cart, you can update it (which means adding items to it, or removing items from it, or changing the numbers of items in it, …), and you can finally delete it (when the user submits their order, or when they cancel their shopping tour).

What you can NOT do is to access your data using the verbs that are relevant for your domain:

- Put an item to the shopping cart - Increase the count of a specific item - Decrease the count of a specific item - Remove an item from the shopping cart - Discard the shopping card

For the domain "shopping", all these actions are relevant, and if you have to map them to CRUD actions, you lose semantics. What's even worse, update and delete are destructive actions, so you don't have any historical data. Of course you can implement all this, but you have to do it on your own.

wolkenkit, in contrast, uses event-sourcing, which works more like Git: Changes are collected, and you can replay them (either all to get the current state, or some of them for arbitrary analytics).

That's IMHO a major difference on whether you are using a CRUD-like foundation, or another approach.

We have also blogged about this: https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-co... and https://www.thenativeweb.io/blog/2017-11-01-11-13-ddd-and-co...