3 ms·

Well - if you mean that MongoDB has a CRUD-like API, and Meteor uses MongoDB, yes, but other than that I do not see the connection. Can you explain?

goloroden 9y ago
E.g., if you have a look at Meteor's documenation, especially the part on collections (https://guide.meteor.com/collections.html 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 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-part-1-whats-wrong-with-crud/ 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-part-2-semantics-over-crud/ https://www.thenativeweb.io/blog/2017-11-01-11-13-ddd-and-co...
- maxsavin 9y ago
  I'm not super familiar with DDD but I do like the ideas behind it - in some cases I think I am doing something similar to it. However - isn't that essentially creating another layer on top of MongoDB? It looks like this could be implemented as a library for Meteor. I'm only saying that to clarify that I do not think it's Meteor CRUD versus this. I think of Meteor more as a boilerplate than an application framework.

goloroden 9y ago

E.g., if you have a look at Meteor's documenation, especially the part on collections (https://guide.meteor.com/collections.html 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 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-part-1-whats-wrong-with-crud/ 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-part-2-semantics-over-crud/ https://www.thenativeweb.io/blog/2017-11-01-11-13-ddd-and-co...

maxsavin 9y ago
I'm not super familiar with DDD but I do like the ideas behind it - in some cases I think I am doing something similar to it. However - isn't that essentially creating another layer on top of MongoDB? It looks like this could be implemented as a library for Meteor. I'm only saying that to clarify that I do not think it's Meteor CRUD versus this. I think of Meteor more as a boilerplate than an application framework.