Database Reference
In-Depth Information
• Is it pattern or anti-pattern (
http://www.oracle.com/technetwork/topics/entarch/
A pattern is a stick for the lame, a remedy for the disease, not the other way around. A
clear realization of the problem must be identified first; otherwise, you'll be left looking
out for a suitable lame for the stick. This is usually unsuccessful and is followed by the
amputation of the healthy application's part, just for making use of the patented remedy
from the catalogue with some catchy name. If fact, the patterns' catalogues should be seen
as common problems' catalogues. The implementation of the pattern as a working solution
could be in jeopardy if:
• You misunderstand the problem on hands, its location (as a framework), root
cause, and its relation with the execution environment
• You misinterpret the existing standards, their areas of application, and, as a result,
attempt to reinvent it
• You misinterpret the design principles, the balance between them, and the areas of
their application
We already gave you a map of the frameworks and standards in relation to the principles,
so it's time now to list all the frameworks we mentioned in this chapter and structure them
for further discussion, as shown in the following table:
Framework
Standards
Foundational
Functional Decomposition, Enterprise Inventory, and Logic Centralization
Design
Contract Centralization, State Messaging, Messaging Metadata, and Service Broker
Agnostic Controller and subcontroller, Compensation Service Transaction, Composition Autonomy, Inventory Endpoint,
Partial State Deferral, Legacy Wrapper, and File Gateway
Implementation
Governance
Service Decomposition, Service Refactoring, and Metadata Centralization
The following figure explains the preceding table:
Search WWH ::
Custom Search