Patterns

Skip to end of metadata
Go to start of metadata

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]
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.