Patterns

A pattern is usually defined as a solution to a problem in a context. If your context does not match the context of the pattern you will probably not be able to use it. Patterns can be combined. They also have intrinsic strengths and weaknesses that need to be evaluated in the context of your project. There are also some common Antipatterns that should be avoided.

Have you used patterns that are not described here? Please contribute your experiences!

Risk reduction patterns
1. Limited releases
2. [Backwards compatible schema modifications]
3. Separate schema modifications from data migration
4. Sanity check versions
Facilitator patterns
1. Pain relievers
2. Differentiators
3. Minimize releases in production
4. Automate releases
5. [Automate database migrations]
6. Continuous deployment
7. Continuous production
Feature reduction patterns
1. Workflow by workflow
2. Partition the workflow
3. Workflow tail first
4. Product by product
5. User set by user set
Coexistence patterns
1. Customer by customer
2. New orders
3. New product
4. New user set
5. Competing system
6. Umbrella (mask new system)
7. Duplicate input
8. [Input strangler]
9. Live beta
19. Facilitate switching
Legacy data patterns
1. Shared database
2. Synchronized database
3. Replicated database
4. Database views
5. Incremental migration
6. [Proxy data services]
7. Partial history
8. [Share services]
9. [Data service layer]
10.Tag data
11.Read only operations
Multiple systems patterns
1. Synchronous deployment
2. Asynchronous deployment
3. [Upgrade upstream first]
4. [Upgrade downstream first]

Patterns

Risk reduction patterns

Facilitator patterns

Feature reduction patterns

Coexistence patterns

Legacy data patterns

Multiple systems patterns

33 Child Pages