...
We will start with Architectural Approach A in the PoC with the aim of fully supporting ArchitectueArchitectural Approach C.
Details
Micro-service architecture strives to control coupling. The deployment of micro-services enforces good behavior, only published interfaces are available at run-time. This is not new. Encapsulation and data hiding have been around as long as software. What is new is the enforcement at run-time. Note also that mechanisms been put in place to soften this encapsulation: the C++ friend declaration; Java package protected. There are reasons for both approaches and as always there is a balance. The two approaches are not mutually exclusive.
...
- is the data (related to a all models and instances) stored in a single database or
- is the data (related to a specific model and instance) stored in separate databases
- Secondary question for 2: within a shared or separate DBMS
Architectural approach A
All data access id via interfaces provided by the owning service.
Classic µService architecture. (One extreme)
...
- Latency in data access (multiple serializations)
- Data transformation (multiple representations)
- Data duplication (multiple representation 'cached' in multiple data stores)
- Data deployment purely a deployment concern.
Architectural approach B
Data access to any data is allowed regardless of ownership.
Common information model and data lake. (Another extreme)
...
Access control may be used to mitigate the negatives of this approach. However this can be problematic in the selection of the DB technology, and the load on the DBMS
Architectural approach C
Data access is permitted only when there is an explicit agreement between components.
Hybrid approach.
- A single component is designated owner of the model and data related to it. This is not a common information model.
- Knowledge of the model is always via an interface provided by the µService that owns it.
- Access to data is not possible without knowledge of the model. This is not a data lake.
- Data deployment involves understanding use cases
...
This approach is backwardly compatible with Option Architectural Approach A.