JsonStore: Not-only SQL with SQL
I’m always fighting against myself when the topic is mapping domain objects correctly to a relational model. I wrote an article about it: “Why storing aggregates with NoSQL?” with a strong opinion on this topic and I recommend the read.
Basically my opinion hasn’t changed since that post, but lately I’m using a new approach to the subject that is worth sharing.
As the title of this article says: NoSQL with SQL, I’m proposing storing domain objects as documents with SQL.
This subject isn’t something new in the market and great companies are using it, like Particular Software (creators of NServiceBus) with their saga storage or Octopus Deploy with their storage framework Nevermore.
These examples shown above are awesome and worth checking. I used them in the past and came up with the conclusion: IMO it is somehow opinionated on your domain model and/or it can only be used within their own framework (like the saga storage from Particular).
Introducing JsonStore
JsonStore was born to be a lightweight C# library that offers a layer of abstraction on top of your domain objects that can translate them as Documents without interfering in your current domain model.
See the repository link: https://github.com/arleypadua/JsonStore, please any feedback is welcome ✌
As a brief introduction on the programming model, here are a feel concepts in this library:
- Document: Represents an identifiable document. It can be any class that will be serialized and persisted.
- Collection: Represents a collection of documents. You can perform actions on a collection such as: restore a document by id, change the state of a document (unmodified, changed, added or delete), and finally commit the changes present in the collection.
- Documents Store: This is the abstraction for a technology that stores documents. Currently only SQL Server is supported.
- Serializer: Implements the behavior of serializing a Document. The collection uses Json.NET as the default serializer.
And bellow a dependency relationship of the model:
In essence, the flow would be:
- Your application asks the document collection to add/change/remove a document.
- Your application asks to commit all the changes present in the collection.
- The document store gets all the documents with their changed state and persists on the database.
I also created an example based on the solution of the article: “Commands + Domain Events + Real time notification — Hands on”
Check it out:
https://github.com/arleypadua/domain-events-signalr-jsonstore
It basically persists an order whenever the user clicks on the button “Place Order” and any new connection receives all previous stored documents.
Thanks for reading 😉
Follow me on Twitter: @_arleypadua