There's a progression ever developer that grew up on SQL Server/relational data needs to go through...
1. The models (plural intended) of a business are not necessarily a relational. There could be an upstream/downstream relationship. There could be an event-based relationship. There may be no relations at all (documents are handy in these scenarios).
Stop assuming you start with an entity relation diagram. That's an immediate limiting factor when listening to the business describe their processes.
2. There is no such thing as immediate updates to any database. There is _always_ latency. Build software understanding this.
3. Operational data and Analytical data are TWO DIFFERENT THINGS. (sorry for the shouting)
Operationally, I only need concern myself with the immediate needs of the user or process. If I'm doing "something" to the customer domain, I don't need to know or do anything else. If I'm doing something to the order domain, I may need to notify some other domains of what I'm doing or have done, but that's secondary and not _immediately important_. Inventory systems should have built-in mechanisms for levels and never need to know the exact up-to-date figures.
My operational domains can notify whole other systems on changes in data. So your analytical system can subscribe to these changes and normalize that data all it wants. I can even build user interfaces that display both operational and analytical data.
Micro-services are brilliant at operational domain boundary adherence. Events are brilliant at notifying external boundaries of change.
The caveat I point out to my clients is that thinking in this way is very different than we're used to and often comfortable with. It takes time to identify the best boundaries and events for the models of a business. But if you put in that time, the result will be software that your business personnel can actually understand.
1. The models (plural intended) of a business are not necessarily a relational. There could be an upstream/downstream relationship. There could be an event-based relationship. There may be no relations at all (documents are handy in these scenarios).
Stop assuming you start with an entity relation diagram. That's an immediate limiting factor when listening to the business describe their processes.
2. There is no such thing as immediate updates to any database. There is _always_ latency. Build software understanding this.
3. Operational data and Analytical data are TWO DIFFERENT THINGS. (sorry for the shouting)
Operationally, I only need concern myself with the immediate needs of the user or process. If I'm doing "something" to the customer domain, I don't need to know or do anything else. If I'm doing something to the order domain, I may need to notify some other domains of what I'm doing or have done, but that's secondary and not _immediately important_. Inventory systems should have built-in mechanisms for levels and never need to know the exact up-to-date figures.
My operational domains can notify whole other systems on changes in data. So your analytical system can subscribe to these changes and normalize that data all it wants. I can even build user interfaces that display both operational and analytical data.
Micro-services are brilliant at operational domain boundary adherence. Events are brilliant at notifying external boundaries of change.
The caveat I point out to my clients is that thinking in this way is very different than we're used to and often comfortable with. It takes time to identify the best boundaries and events for the models of a business. But if you put in that time, the result will be software that your business personnel can actually understand.