Multi-tenancy is never simple and can be addressed at different levels. Arguably, the most interesting solution would be where the app and the database both support multiple tenants. Here I bring this solution to the YABT project.

Practical modelling of a NoSQL database using the DDD (Domain Driven Design) practices to define the problem area (Bounded context) of the project, its domain entities and aggregates. Comparison to designing a relational model for a traditional SQL.
This post is a part of the YABT series dedicated to building an enterprise application leveraging the .NET Core + RavenDB bundle.

Following up on my "7 reasons not to NoSQL", here are my two reasons to go with NoSQL in enterprise projects - Cheaper to scale and Convenience of development.

Have you seen people affiliated with NoSQL databases aggressively advertising them as a solution for everything? And early adopters swearing allegiance to the NoSQL and claiming to pass the point of no return to SQL? Unsurprisingly, one may think of NoSQL as the silver bullet which solves all the problems. Should we always use NoSQL?