Description
Different services access the same database. In the worst case, different services access the same entities of the same schema.
Context
Derived from: “Shared Persistency”
The implementation of services usually follows a “share nothing” philosophy. This is especially relevant for clear data ownership. Each data collection or schema usually belongs to exactly one service. The only allowed access to this data is via this service.
Consequences
This smell highly couples the services connected to the same data, reducing team and service independence.
Detection
Check if multiple services are accessing the same System Software represents a database..
Solution
Possible solutions are to use independent databases for each service, to use a shared database with a set of private tables for each service that can be accessed by only that service, or to use a private database schema for each service.
Cypher query
MATCH p=(a:BusinessObject|DataObject|Systemsoftware)-[r:AccessRelationship]-(b) <br /> WITH a, count (r) as cnt <br /> WHERE cnt> 1 <br /> MATCH p = (a)-[r:AccessRelationship]-(b) <br /> RETURN p <br /> UNION <br /> MATCH p=(a:SystemSoftware)-[r]-(b) <br /> WHERE toLower(a.name) contains "dbms" OR toLower(a.name) contains "data" <br /> WITH a , count (r) as cnt <br /> WHERE cnt> 1 <br /> MATCH p = (a)-[r:AccessRelationship]-(b) <br /> RETURN pCypher count query
MATCH (a:BusinessObject|DataObject|Systemsoftware)-[r:AccessRelationship|ServingRelationship]-(b) with a , count (r) as cnt where cnt> 1 MATCH p = (a)-[r]-(b) return count (distinct a)Diagram

Tags
microservices, soa, application, technology, data management, The Couplers, automatic detection
Related smells
- Scattered Parasitic Functionality (relates)