- Overview
- Introduction
- History
- Acknowledgements
- Podcasts
- Candidate Patterns
- Forms
- Press Releases
- Resources
- Compound Patterns
- Design Patterns (alphabetical)
- Overview
-
Agnostic Capability
-
Agnostic Context
-
Agnostic Sub-Controller
-
Asynchronous Queuing
-
Atomic Service Transaction
-
Brokered Authentication
-
Canonical Expression
-
Canonical Protocol
-
Canonical Resources
-
Canonical Schema
-
Canonical Versioning
-
Capability Composition
-
Capability Recomposition
-
Compatible Change
-
Compensating Service Transaction
-
Composition Autonomy
-
Concurrent Contracts
-
Content Negotiation
-
Contract Centralization
-
Contract Denormalization
-
Cross-Domain Utility Layer
-
Data Confidentiality
-
Data Format Transformation
-
Data Model Transformation
-
Data Origin Authentication
-
Decomposed Capability
-
Decoupled Contract
-
Direct Authentication
-
Distributed Capability
-
Domain Inventory
-
Dual Protocols
-
Endpoint Redirection
-
Enterprise Inventory
-
Entity Abstraction
-
Entity Linking
-
Event-Driven Messaging
-
Exception Shielding
-
File Gateway
-
Functional Decomposition
-
Idempotent Capability
-
Intermediate Routing
-
Inventory Endpoint
-
Legacy Wrapper
-
Lightweight Endpoint
-
Logic Centralization
-
Message Screening
-
Messaging Metadata
-
Metadata Centralization
-
Multi-Channel Endpoint
-
Non-Agnostic Context
-
Partial State Deferral
-
Partial Validation
-
Policy Centralization
-
Process Abstraction
-
Process Centralization
-
Protocol Bridging
-
Proxy Capability
-
Redundant Implementation
-
Reliable Messaging
-
Reusable Contract
-
Rules Centralization
-
Schema Centralization
-
Service Agent
-
Service Callback
-
Service Data Replication
-
Service Decomposition
-
Service Encapsulation
-
Service Façade
-
Service Grid
-
Service Instance Routing
-
Service Layers
-
Service Messaging
-
Service Normalization
-
Service Perimeter Guard
-
Service Refactoring
-
State Messaging
-
State Repository
-
Stateful Services
-
Termination Notification
-
Trusted Subsystem
-
UI Mediator
-
Utility Abstraction
-
Validation Abstraction
-
Version Identification
- Design Patterns (by category)
- Foundational Inventory Patterns
- Logical Inventory Layer Patterns
- Inventory Centralization Patterns
- Inventory Implementation Patterns
- Inventory Governance Patterns
- Foundational Service Patterns
- Service Implementation Patterns
- Service Security Patterns
- Service Contract Design Patterns
- Legacy Encapsulation Patterns
- Service Governance Patterns
- Capability Composition Patterns
- Service Messaging Patterns
- Composition Implementation Patterns
- Service Interaction Security Patterns
- Transformation Patterns
- REST-inspired Patterns
- Cloud Computing Patterns
- Service Technology Specs
- SOA School
Pattern Contribution Form
Please be sure to complete all of the required fields in the form, as only completed forms will be reviewed. Because design patterns are expected to provide proven solutions to common design problems, submitted patterns must have at least three successful and verifiable implementations in order to be considered. This is why you are asked to provide the three Pattern Application Reference contacts below. Note that all references will be contacted as part of the pattern review process. After your pattern has been verified, you will be e-mailed a template similar to the pattern profile structure used to document design patterns on this site. You will be asked to complete the template and then formally submit your design pattern for inclusion in this pattern catalog.
Note that if you have an idea for a design pattern and/or you do not have sufficient application references, you can submit it as a Candidate Pattern via the Candidate Pattern Contribution Form.
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura YouTube Channel