Issue

Since we will be working with a microservice architecture, providing an extendable and consistent data model at the same time can prove a challenge. Therefore some standard requirements/procedures are set to make sure this goes well.

The issue at hand can be split:

Providing extendable objects

Should there be a single origin (microservice) for each object?

Should there be allowed multiple origins for each object?

Should it be entirely decentralized, foregoing to concept of origin?

Cascading changes on objects

Microservices might both make use of a same object, lets say member, both have their own fields for this member and an update in one of the microservice could imply that another microservice needs to update as well. Whenever a change is made on an object, every related (dependent) microservice should be notified in order to cascade the change. How to do this?

Theory

CAP - Partitian tolerance + consistency

http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/

Conclusion

It has been decided that for now we will not look into this too much, as this is very complicated matter which is, considering our situation and experience, very hard, unlikely, to get right. It is smarter to implement and refactor this later, even if it would be more efficient to do it now (assuming we get it right).