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!
Labels:
None
Page:
Customer by customer
Page:
Partition the workflow
Page:
Limited releases
Page:
Product by product
Page:
New orders
Page:
Replicated database
Page:
Shared database
Page:
Synchronized database
Page:
Pain relievers
Page:
User set by user set
Page:
Workflow by workflow
Page:
Trojan Project
Page:
Asynchronous deployment
Page:
Automate releases
Page:
Competing system
Page:
Database views
Page:
Differentiators
Page:
Duplicate input
Page:
Facilitate switching
Page:
Few releases in production
Page:
Incremental migration
Page:
Live beta
Page:
Minimize releases in production
Page:
New product
Page:
New user set
Page:
Partial history
Page:
Read only operations
Page:
Sanity check versions
Page:
Separate schema modifications from data migration
Page:
Synchronous deployment
Page:
Tag data
Page:
Umbrella
Page:
Workflow tail first