| Thing is, data is relational, and data isn't an object Only if you are more concerned with the data first approach instead of thinking about the domain first. It's much better to use views of data, eg. "get me what I need to display a listing page in an eshop" - which entails getting the price, photos, title, description, delivery cost etc. - in a single list that you can then use - the database can do this for you - and all the underlying details are abstracted away, better yet - your app server will never have to CARE that at some points product.photos changed from being a simple array of strings to a fully fledged table - because the view remains the same. It's only "much better" until everyone wants there own one off view that has to be kept in sync with the code and reverting/branching/versioning has to keep in sync with what the hundreds of brittle views, stored procedures, etc. that are being created. Instead of treating the data store like a dumb data store. By putting as much logic in the business later as possible. I can not only branch, version, etc. I can completely unit test my whole application and mock out the data store. Okay so you're saving the entire list of 'followers' of a user inside the user document
What happens when you have a really popular user with a million followers...
What do you do when you update a user who happens to follow thousands of other users... Mongo best practices are to think about the orthoganility of your relationships - one to few, one to many, or "one to quintillions" and choose whether to embed based on that. But going back to thinking in terms of DDD an aggregate roots, a user would be an entity, an address of the user would be a value type that belongs to the user - embed it into the document. A user's followers would be entities, that would be a related object that should be able to change independently. In that case use Mongo references. and all the underlying details are abstracted away, better yet - your app server will never have to CARE that at some points product.photos changed from being a simple array of strings to a fully fledged table - because the view remains the same. If I'm changing the representation of the data. I still have to change it somewhere - whether the database -- where you don't have proper versioning, branching, source control -- or the app server. If you're changing the representation in the app server in more than one module/microservice, you're doing it wrong. With a microservice/module, I can still represent the data as old clients expect by versioning the API and have much better tooling than have five different versions of the view that never die. |