AgileDev
- Last Published: 2016-12-13
- |
- Version: 0.1.15-SNAPSHOT
- Guidelines
- Developers Setup
- Site Documentation
- Documentation
- Branching Models
- Javadoc guidelines
- Software Design Principles
-
Patterns
- API gateway
- Automated testing
- Builder
- Bulkheads
- Caching
- Circuit Breaker
- Client Side Discovery
- Command Query Responsibility Separation
- Deployment microservices
- Domain Driven Design
- Enterprise Integration Pattern
- Exception Handling
- Event Sourcing
- Microservice Architecture
- Monitoring
- Monolithic Architecture
- Scale Cube
- Self registration
- Server Side Discovery
- Service Connector
- Service Registry
- Service Statelessness
- Single Responsibility Principle
- System of Record
- Timeouts
- Try-Cancel/Confirm
- UUID
- 3rd party registration
- Glossary
- Abbreviations
- Modules
- Build Configuration
- AsciiDoctor output Doclet
- AsciiDoctor Site Diagram Activator
- Maven Site Indexer
- AgileDev common
- AgileDev parent POM
- JUnit BDD
- Design By Contracts for Java
- Cucumber Reporting
- Cucumber Reporting example
- Embedded MySQL Server
- Maven plugin Embedded MySQL Server
- CQRS for Spring
- Event Sourcing for Spring
- Try Cancel/Commit transactions for Spring
- Narayana Tomcat listener
- Tutorial ArchiMate
- Tutorial regarding CQRS and Event sourcing
- Tutorial Design by Contract
- Tutorial Domain Driven Design
- Tutorial Rest
- Project Documentation
- Project Information
Shared data microservice Design Pattern.
One of the design principles of microservices is autonomy, meaning that the service is full-stack and has control of all components. However a typical problem, especially when refactoring from an existing monolithic application, is database normalization such that each microservice has the right amount of data. In a transition phase, some applications may benefit from a shared data microservice design pattern.
In this design pattern, some microservices, likely in a chain, may share caching and database stores. This would only make sense if there is a strong coupling between the two services. Some might consider this an anti pattern but business needs might require in some cases to follow this. This would certainly be an anti-pattern for greenfield applications that are designed based on upon microservices.