Data and Microservices

When you first meet the concept of microservices, you find it striking how simple the ideas are. They are also not new. SOA applied at a more fine granularity of service. So? What's new? 

You can get hundreds, and probably, thousands of answers. And they are mostly simple and logical. The most salient one being independent deployablitly, and the "micro" characteristic.i.e, the smallest deployable component. It remains up to you to define what "smallest" means for you. There are many details of design, testability, composability, manageabilty, fit with your agile cycle, etc. There are many best practices readily available online. Nothing new in any of these ares. Most of these problems have existed for a long time and they have solutions and best practices.

The one aspect that I have found the most difficult to wrap my mind around, is the stipulation that there is to be no shared access to data between services and no direct access to data outside of services. That is such a simple and elegant goal - but sounds impossible to implement. After all, that is the very definition of a database - take data ownership away from applications and put it in a "shared" database. It took database technology thirty years to reach a point where this is universally acceptable, and desirable. That is the crux of database thinking, and database design. To remind yourself of how established and accepted this notion is (shared data) browse through a good text on database design.

So, not to make this post too long, I highly recommend googling on "data and microservices", if you want a quick understanding of how to solve this simple, yet difficult, problem.

There seems to be almost universal agreement on a few architectural and implementation concepts. I will just mention them here, and we can later investigate them in more depth. In the meantime check with uncle Google.

The few architectural principles  are:

• Bounded Contexts (from Eric Evans' DDD Domain Driven Design)
• Aggregates (also from DDD)
• CQRS (Command/Query Responsibility Separation). or CQS - Command/Query Separation - inspired by DBC (Design By Contract) at the object level. CQS is the DBC variant for services. DBC helps with clean object design. CQS helps with clean service design. Very beneficial to be familiar with both.
• Event Sourcing - Extremely important if you want to separate data ownership by service. An updating service needs to notify query services of what it has done. Eric Evans introduced Domain Events, after the book was published, and he and the DDD community have written and presented on the concepts extensively.
• Independent Deployment. Technologies like Docker. 

I think if you have a solid understanding of how to implement "no data sharing among microservices", the rest of it are implementation mechanics.