9/18/2019 Software Patterns

Software patterns quick reference

Version: 4

Nikhil Ramabhadra
Contents
Wikipedia patterns list .................................................................................................................................. 2
The HillSide Group ........................................................................................................................................ 2
Design patterns ............................................................................................................................................ 3
GOF and other patterns (selected) ............................................................................................................... 3
C++ Idioms (James Coplien) .......................................................................................................................... 5
Architechtural patterns ................................................................................................................................ 8
UI ................................................................................................................................................................... 8
SOA patterns (Arnon Rotem-Gal-Oz) .......................................................................................................... 10
REST (Representational State Transfer) ...................................................................................................... 15
REST (Richardson Maturity Model) ............................................................................................................. 15
SOA vs REST................................................................................................................................................. 15
Peter Deutsch’s and James Gosling’s 8 fallacies of distributed computing and cloud computing ............. 16
CAP or Brewer’s theorem ........................................................................................................................... 16
Microservices .............................................................................................................................................. 17
Service mesh ............................................................................................................................................... 18
Patterns of Enterprise Application Architecture (Martin Fowler) .............................................................. 19
Enterprise Integration Patterns (Gregor Hohpe, Bobby Woolf) ................................................................. 22
Cloud Design Patterns ................................................................................................................................ 29
Design patterns used in embedded systems ............................................................................................. 34
AntiPatterns................................................................................................................................................ 35
Software Development AntiPatterns .......................................................................................................... 35
Software Architecture AntiPatterns............................................................................................................ 35
Project Management AntiPatterns ............................................................................................................. 35
System design ............................................................................................................................................. 36
ThoughtWorks – Technology Radar........................................................................................................... 36

1
Software Patterns Version: 4
Wikipedia patterns list

https://en.wikipedia.org/wiki/Software_design_pattern

The HillSide Group

https://www.hillside.net/

2
Software Patterns Version: 4
 Design patterns

GOF and other patterns (selected)

• https://www.pluralsight.com/courses/patterns-library
• https://www.dofactory.com/net/design-patterns
• https://sourcemaking.com/design_patterns

Sr Pattern Reference dofactory

No Frequency of
use
Creational
1 Factory 1) https://en.wikipedia.org/wiki/Factory_method_pattern High (5/5)
method 2) http://rahulrajatsingh.com/2015/02/understanding-and-
implementing-factory-pattern-in-c/
2 Builder https://en.wikipedia.org/wiki/Builder_pattern Medium Low
(2/5)
3 Dependency 1) https://en.wikipedia.org/wiki/Dependency_injection
Injection 2) http://rahulrajatsingh.com/2014/06/an-absolute-beginners-
tutorial-on-dependency-inversion-principle-inversion-of-
control-and-dependency-injection/
4 Lazy https://en.wikipedia.org/wiki/Lazy_initialization
initialization
5 RAII https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization
6 Singleton https://en.wikipedia.org/wiki/Singleton_pattern Medium High
(4/5)
7 Multiton https://en.wikipedia.org/wiki/Multiton_pattern
8 Object pool https://en.wikipedia.org/wiki/Object_pool_pattern
9 Abstract https://en.wikipedia.org/wiki/Abstract_factory_pattern High (5/5)
factory
Structural
10 Adapter 1) https://en.wikipedia.org/wiki/Adapter_pattern Medium High
2) http://rahulrajatsingh.com/2014/06/understanding-and- (4/5)
implementing-the-adapter-pattern-in-c-and-c/
11 Bridge https://en.wikipedia.org/wiki/Bridge_pattern Medium (3/5)
12 Composite https://en.wikipedia.org/wiki/Composite_pattern Medium High
(4/5)
13 Decorator* https://en.wikipedia.org/wiki/Decorator_pattern Medium (3/5)
14 Façade https://en.wikipedia.org/wiki/Facade_pattern High (5/5)
Behavioral
15 Chain of https://en.wikipedia.org/wiki/Chain-of-responsibility_pattern Medium Low
Responsibility (2/5)
16 Command 1) https://en.wikipedia.org/wiki/Command_pattern Medium High
2) http://rahulrajatsingh.com/2014/06/understanding-and- (4/5)
implementing-the-command-pattern-in-c/
17 Null Object https://en.wikipedia.org/wiki/Null_object_pattern
18 Observer https://en.wikipedia.org/wiki/Observer_pattern High (5/5)

3
Software Patterns Version: 4
19 Strategy https://en.wikipedia.org/wiki/Strategy_pattern Medium High
(4/5)
20 Specification https://en.wikipedia.org/wiki/Specification_pattern
21 Visitor* https://en.wikipedia.org/wiki/Visitor_pattern Low (1/5)
(Behavior
injection)
Functional
22 Functor https://en.wikipedia.org/wiki/Function_object
23 Generator https://en.wikipedia.org/wiki/Generator_(computer_programming)
24 Closure https://en.wikipedia.org/wiki/Closure_(computer_programming)
Others
25 Event 1) https://prismlibrary.github.io/docs/event-aggregator.html
Aggregator 2) https://martinfowler.com/eaaDev/EventAggregator.html

4
Software Patterns Version: 4
C++ Idioms (James Coplien)

Reference: C++ Idioms – by James Coplien

Sr No Pattern Description
1 Handle/Body Separating interface from implementation.

Split a design class into two implementation classes. One

takes on the role of an identifier and presents the class
interface to the user. We call this first class the handle. The
other class embodies the implementation, and is
called the body. The handle forwards member function
invocations to the body.
2 Counted Body Manage logical sharing and proper resource deallocation of
objects that use dynamically allocated resources.

Add a reference count to the body class to facilitate memory

management; hence the name “Counted Body.”
Memory management is added to the handle class,
particularly to its implementation of initialization,
assignment, copying, and destruction.
It is incumbent on any operation that modifies the state of
the body to break the sharing of the body by making its
own copy. It must decrement the reference count of the
original body.
3 Detached Counted Body Adding reference counting to an object to which a reference
count cannot directly be added.
Associate both a shared count, and a separate shared body,
with each instance of a common handle abstraction.
4 Handle/Body Hierarchy To separate representation inheritance from subtyping
inheritance.

Maintain separate inheritance hierarchies for handle classes

and body classes. The base interface class contains a
reference to the base implementation class.
5 Envelope/Letter To tie together common semantics of handle and body
classes.

Derive all solution body classes from a common base class. To

reflect the commonality in signature between the handle and
the body, use the handle class as the common base class for
alternative bodies. Make handle member functions virtual.
Each alternative implementation derived from the handle
class (in its role as the class defining the interface to the
implementations) overrides suitable virtual functions. The

5
Software Patterns Version: 4
 base class implementation of these member functions
defines the handle class functionality: it forwards requests to
its associated body class instance.
6 Virtual Constructor How to build an object of known abstract type, but of
unknown concrete type, without violating the encapsulation
of the inheritance hierarchy.

Implement envelop letter. The base class is an intermediary

agent that selects the appropriate derived type from context.
7 Concrete Data Type Determine whether to allocate an object on the heap or in
the current scope.

Objects that represent “real-world” entities that live outside

the program should be instantiated from the heap using
operator new. The lifetime of these objects is likely to be
independent of the lifetime of any procedure or class scope,
so it is unwise to declare them as objects in any scope.
Window is an example of such a class.

Objects that represent abstractions that live “inside” the

program that are closely tied to the computational model,
the implementation, or the programming language.
Collection classes (string, list, set) are examples of this kind of
abstraction (though they may use heap data, they themselves
are not heap objects). They are concrete data types—they
aren’t “abstract,” but are as concrete as int and double.
8 Algebraic Hierarchy Structuring classes whose type relationships follow classic
algebraic types.

Use bridge pattern.

9 Homogenous Addition Simplify implementation of operations in a algebraic
hierarchy.
10 Promote and Add How to add objects of two different types when only
homogenous addition is supported.
11 Promotion Ladder How to assign type promotion responsibility to classes in an
algebraic hierarchy.
12 Non-Hierarchical Addition How to deal with arithmetic operations between types when
neither can be promoted to the other.

Detect cases where neither type can be promoted to the

other. Promote both to a more general type and retry the
operation.
13 Type Promotion How to use two type conversion mechanisms – operator
functions and constructors – to build a consistent type
promotion structure
14 Curiously recurring template https://www.fluentcpp.com/2017/05/12/curiously-recurring-
pattern template-pattern/

6
Software Patterns Version: 4
 PDF

In this pattern:
• Create a base template class
• Create a derived class that passes itself to the base
template classes parameter T.
The intention of this idiom is to use the derived class in the
base class.

7
Software Patterns Version: 4
Architechtural patterns

UI

https://martinfowler.com/eaaDev/uiArchs.html

Sr Pattern Description
No
1 Forms and Form that defines layout. Form logic programmed using controls. There is no
Controls separation between presentation and logic in this pattern.
2 MVP In this pattern the presentation elements communicate with the domain via
the presenter. When events are raised in a presentation element these are
not acted upon but are passed to the presenter. The presenter then decides
to react to the event by updating the domain and triggering a view update.

View logic can remain with the view or can be moved to the presenter.
3 MVC This pattern clearly creates a division between the presentation elements and
the domain objects. In MVC domain element is the model and the
presentation elements form the view. The controller’s job is to take the user’s
input and act on it. The controller, therefore, orchestrates between user
input, domain, and the view.
4 Presentation https://martinfowler.com/eaaDev/PresentationModel.html
Model or
Application Presentation Model is used to move state and behavior out of the view and
Model (Visual into a model class that is a part of the presentation. The Presentation Model
Works coordinates with the domain layer and provides an interface to the view. The
Smalltalk) view can keep its state and then synchronize this with the Presentation
Model.

5 MVVM or
model-view-
binder

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel

MVVM is a variation of Martin Fowler’s Presentation Model pattern.

8
Software Patterns Version: 4
 In this pattern there is a separation between the presentation and the
domain. The view model acts as a value converter that converts domain
objects into presentation objects. It enables the separate development of the
presentation layer. The view model can implement a mediator pattern for
organizing access to back end logic.
https://en.wikipedia.org/wiki/Mediator_pattern

WPF, Silverlight, Angular, Aurelia, Durandal, Ember, Knockout, React, Omi,

Oracle JET, Vue, Ext_JS implement MVVM.
6 MVW (W - https://stackoverflow.com/questions/13329485/what-does-mvw-stand-for
Whatever) or Whatever stands for "whatever works for you".
MV*
In this pattern the controller can be replaced with something else.
7 Micro https://martinfowler.com/articles/micro-frontends.html
Frontends
This is not a architecture pattern but a trend that aims to break a monolithic
frontend into smaller manageable pieces.

This is similar in thought to microservices.

8 Others http://ui-patterns.com/patterns

9
Software Patterns Version: 4
SOA patterns (Arnon Rotem-Gal-Oz)

Sr No Pattern Description
Foundation structural patterns.
1 Service Host A framework that acts as a container for services. The
framework calls back into the service code. The callback
principle is known as Inversion of Control. Azure Service
Fabric, Spring, PicoContainer are examples.
2 Active Service Idea is to have an active or scheduled thread within the
service or in the edge component that can call external
services to update cache, monitor itself, etc… Pre-requisite
for patterns like Decoupled Invocation, Service Watchdog
etc…
3 Transactional Service This pattern involves creating a transaction envelope in which
it opens a transaction, reads the request, handles the
message, sends the response, and closes the transaction.
ACID.
4 Workflodize Introduce a workflow engine in a service to handle volatile
processes and orchestrate stable logic. .NET - Windows
Workflow Foundation, Skelta, K2, Azure Logic Apps. Java –
IBM JBoss, IBM Flux, Oracle WF_ENGINE.
5 Edge Component An edge component contains concerns other than the
business logic. Such concerns can be cross-cutting. Security,
Audit, Transform, Load balance, are examples of concerns of
an edge component. JAX-WS, WCF are limited to bindings.
Better examples are Restlet SAS, Turmeric SOA framework.
Patterns for performance, scalability, and availability.
6 Decoupled Invocation Separates replies from requests. Basic components a handler,
a queue, and a dispatcher. Handler acknowledges request
and places request into an in queue. Business logic processes
request and places this into an out queue. Dispatcher then
calls an endpoint with the response. Dispatcher and handler
can be put in an edge component.
7 Parallel Pipelines This breaks a process/request into sub tasks and adds a
queue in between them. Each sub task is an independent
component or pipeline. Different requests can have different
flows via the sub task piplelines. Akka actors, Javaspaces.
8 Gridable Service In this the service business logic transfers a computationally
intensive task to a grid or a cloud-based solution line Azure
batch. Pattern encourages scaling out.
9 Service Instance Scale out using multiple instances of a service. Auto scaling in
Azure, AWS, etc…
10 Virtual Endpoint Load balancing implements this pattern.
11 Service Watchdog This actively monitors internal state, self-heals when
required, logs. Service needs to implement Active service
pattern to monitor itself.

10
Software Patterns Version: 4
 Self healing:
1 Fail fast
2 Restart
3 implement circuit breaker
4 Clear logs, temp files etc…
Amber Point SOA Management System, WebLayers for WS*
monitoring. Nagios, HP OpenView, IBM Tivoli, MS Operations
Manager.
Security and manageability patterns
12 Secured Message Pattern expects a single component that enforces security on
top of raw messages. Encryption or decryption, digital
signatures. Cryptographic service providers.
13 Secured Infrastructure Secure communication infrastructure for services using an
off-the-shelf solution. SSL/TLS, WS*, ESBs.
14 Service Firewall Intercept incoming and outgoing messages with a dedicated
software or hardware component. This is an edge
component. Implement and deploy in a DMZ. Deploy a
regular firewall behind this and the actual service behind the
regular firewall.
15 Identity Provider Pattern enables to get single sign-on for the service
consumer’s authorization. Provisioning, Token server are
components of this pattern.
16 Service Monitor This pattern centralizes the monitoring of security, networks,
QoS, policies etc… There are 3 main components:
1 Collection component – Collect incoming statuses like
performance, faults, number of calls, and data transferred.
2 Monitor – Validates data collected by executing rules, check
against promised QoS.
3 Notifier – If a problem has been identified this goes into
action and notifies operators. An operator is an edge service
that can restart a faulty service, change policy for a running
service, etc…
Oracle AmberPoint, Nagois, IBM Tivoli Suite, CA infrastructure
management.
Message exchange patterns
17 Request/Reply Pattern describes handling requests synchronously.
18 Request/Reaction Pattern describes handling of requests asynchronously.
Reaction consists of calling the consumer endpoint once a
request has been processed rather than using .NET async
await mechanism. The request can contain the reaction end
point that it needs to call. Apache Axis2 Java library.
19 Inversion of Add event-driven architecture or EDA to SOA. Service
Communications publishes events that occur in them. A service edge
component is required that in turn hides the actual service
behind it. The edge implements EDA (event handlers and
propogators). It receives an event that translates to a service
call. A reply from a service is translated by the edge

11
Software Patterns Version: 4
 component into events that are sent to subscribed service
consumers.
20 Saga A saga is a sequence of related small transactions. This
pattern breaks service interactions into small actions with
counteraction or compensation. In this pattern each service
acts on a saga (long running transaction) independently sent
to it. The services do not wait on each other to complete the
transaction. Each service processes the transaction and calls
the next service in the chain. In case of a failure the fault is
propagated up the service chain and each service then
performs a compensating action to roll back the action it took
for the saga; thus rolling back the transaction. The services
can use a coordinator like a database to ensure that all the
individual transactions have been completed successfully.
Drawbacks:
1 Compensation failure due to data alteration required for
the compensating action.
2 Cancellation (example of an order) can be difficult to
handle.
3 Coordinator failure.
4 Sagas can run for a long-time locking resources (example
ordered items).
Service consumer patterns
21 Reservation Pattern requires a service to provide a level of guarantee on
internal resources (example ordered item) with a time limit.
This overcomes the 4th deficiency of a saga. An incoming
order is considered as a reservation with an expiration limit. If
the order process is not completed within the expiration
limit, then the validation step that is run before completing
the order process would fail. Expirations can be used to
prioritize assignment of resources.
22 Composite Front End UIs aggregate data from services into a useful whole. This
(Portal) pattern helps in solving challenges of having a UI that works
with multiple services. There are two components:
1 Portlet – There are UI building blocks. Each block has UI
logic and an associated service proxy.
2 Host – This provides the glue to bin the portlets into a
cohesive whole.
23 Client/Server/Service This is used in case the UI and service technology are
incompatible. In such a case an intermediate server is
introduced, and this allows the UI and services to change
independently.
Service integration patterns
24 Service Bus Make services interact in a decoupled manner when services
use different protocols, configurations, and routing. Service
bus abstracts communications between services.

12
Software Patterns Version: 4
 25 Orchestration In this pattern one creates a workflow engine that is external
to the services it calls. Model business processes as flows of
service interactions. The engine executes, monitors, and
manages them.

This pattern is a particular implementation of the saga

pattern in which the coordinator is external to all
participants.
26 Aggregated Reporting Create a service that gathers immutable data from multiple
services for reporting.

Antipatterns:

Sr No Pattern Description
1 Knot A knot is antipattern where the services are tightly coupled by
hardcoded point-to-point integration and context-specific
interfaces.

Refactor code to use the Workflowdize, Orchestration, or

Inversion of communications.
2 Nanoservice This is an antipattern where a service is too fine-grained. In
this case the overheads (communications, maintenance etc…)
outweighs its utility.

Every time a request is sent to a service costs such as

serialization, call needs to be routed through the OS network
service, network protocol conversion, travelling on the
network, OS network service to service process,
deserialization, security, routing and retries are added.
Modern networks can handle this but if you have a lot of
nanoservices these numbers add up and become significant.

Nanoservices by definition cause fragmented logic. A point is

reached where you need to call a bunch of services to achieve
something meaningful.

A proliferation of Nanoservices causes overhead. This includes

development time, management, keeping track of service in a
service registry, policy compliance, etc…

False assumptions when moving to nanoservices:

1) Bandwidth is infinite.
2) Transport cost is zero.

Consolidate nanoservices into a larger service or move

functionality into other services.

13
Software Patterns Version: 4
 3 Transactional Integration This an antipattern where transactions extend across service
boundaries. Issues that occur are performance, security, and
rigidity.

Transactions introduce temporal coupling. Rigidity in achieving

success involves holding onto locks for a long time even in
case of partial failures. Introduction of new service calls to
handle business rules that were not initially intended.
Introducing more services to a transaction increases surface
area for attacks like DOS. Distributed transactions also
increase coupling between them.

Orchestration, Inversion of communication, or Saga are ways

to get around this antipattern.
4 Same Old Way This is an antipattern where non-SOA architectures are
implemented using SOA tools without the SOA benefits.

Example a data service that provides CRUD operations could

have been a data access layer instead of as a service. There
extra effort involved in testing, deploying, and monitoring.

14
Software Patterns Version: 4
REST (Representational State Transfer)

REST’s basic component is the resource. Constraints defined by REST are as follows:

1. Layered system: Layered architecture.

2. Client/Server: Introduces SOC between consumers and providers.
3. Stateless Communications: The server should have enough context on what to do with a
request. Cookies are a way to achieve this.
4. Replicated repository: It is okay for more than one process to provide a service to achieve
scalability and availability.
5. Cacheable: Messages can specify if they can be cached to reduce server round trips.
6. Uniform interface: REST uses a limited vocabulary of 8 methods GET, POST, PUT, DELETE,
OPTIONS, HEAD, TRACE, CONNECT.
7. Virtual machine: Ability to run scripted code. This is a prerequisite for the next constraint “code
on demand”.
8. Code on demand: This is an optional constraint that allows you to download code to the client
for execution such as Javascript.
9. HATEOAS (Hypermedia as the Engine of Application State): Replies from a service should
provide links (URIs) to available options for moving forward from the current state.

REST (Richardson Maturity Model)

https://martinfowler.com/articles/richardsonMaturityModel.html

SOA vs REST

SOA constraints:

1. Distributed agents.
2. Pipes and filters.
3. Layered system.
4. Client/Server
5. Optional:
a. Stateless communications
b. Cacheable

APIs are around operations rather than resources.

15
Software Patterns Version: 4
Peter Deutsch’s and James Gosling’s 8 fallacies of distributed computing
and cloud computing

The first seven were defined by Peter and the last one was added by James. Could computing does not
solve these fallacies but makes them more apparent.

1. The network is reliable.

2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn’t change: The notion of elasticity in the cloud means that there is no way that
topology stays the same.
6. There’s one administrator.
7. Transport cost is 0.
8. The network is homogenous: Homogenous network is a network of computers that use similar
configurations and communication protocol.

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

https://dzone.com/articles/understanding-the-8-fallacies-of-distributed-syste

CAP or Brewer’s theorem

Consistency, Availability, and Partition Tolerance. No distributed data store can provide more than two
of the three guarantees.

https://en.wikipedia.org/wiki/CAP_theorem

https://dzone.com/articles/understanding-the-cap-theorem

http://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html

https://en.wikipedia.org/wiki/PACELC_theorem

16
Software Patterns Version: 4
Microservices

https://microservices.io/

Microservices - also known as the microservice architecture - is an architectural style that structures an
application as a collection of services that are

• Highly maintainable and testable

• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by a small team

The microservice architecture enables the rapid, frequent and reliable delivery of large, complex
applications. It also enables an organization to evolve its technology stack.

https://www.redhat.com/en/topics/microservices

Microservices are both an architecture and an approach to writing software. With microservices,
applications are broken down into their smallest components, independent from each other. Instead of
a traditional, monolithic, approach to apps, where everything is built into a single piece, microservices
are all separated and work together to accomplish the same tasks. Each of these components, or
processes, is a microservice.

17
Software Patterns Version: 4
Service mesh

Reference: https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh

This concept aims to move the code that performs communication into infrastructure sidecar (see
sidecar pattern in cloud patterns) out of a microservice.

In a service mesh, requests are routed between microservices through proxies in their own
infrastructure layer.

18
Software Patterns Version: 4
Patterns of Enterprise Application Architecture (Martin Fowler)

Sr No Pattern Description
1 Active Record An object that wraps a row in a database table or view,
encapsulates the database access, and adds domain logic on
that data.
2 Application Controller A centralized point for handling screen navigation and the
flow of an application.
3 Association Table Mapping Saves an association as a table with foreign keys to the tables
that are linked by the association.
4 Class Table Inheritance Represents an inheritance hierarchy of classes with one table
for each class.
5 Client Session State Stores session state on the client.
6 Coarse-Grained Lock Locks a set of related objects with a single lock.
7 Concrete Table Inheritance Represents an inheritance hierarchy of classes with one table
per concrete class in the hierarchy.
8 Data Mapper A layer of mappers that moves data between objects and a
database while keeping them independent of each other and
the mapper itself.
9 Data Transfer Object An object that carries data between processes in order to
reduce the number of method calls.
10 Database Session State Stores session data as committed data in the database.
11 Dependency Mapping Has one class perform the database mapping for a child class.
12 Domain Model An object model of the domain that incorporates both
behavior and data.
13 Embedded Value Maps an object into several fields of another object’s table.
14 Foreign Key Mapping Maps an association between objects to a foreign key
reference between tables.
15 Front Controller A controller that handles all requests for a Web site.
16 Gateway An object that encapsulates access to an external system or
resource.
17 Identity Field Saves a database ID field in an object to maintain identity
between an in-memory object and a database row.
18 Identity Map Ensures that each object gets loaded only once by keeping
every loaded object in a map. Looks up objects using the map
when referring to them.
19 Implicit Lock Allows framework or layer supertype code to acquire offline
locks.
20 Inheritance Mappers A structure to organize database mappers that handle
inheritance hierarchies.
21 Layer Supertype A type that acts as the supertype for all the types in its layer.
22 Lazy Load An object that doesn’t contain all the data you need but
knows how to get it.
23 Mapper An object that sets up communication between two
independent objects.
24 Metadata Mapping Holds details of object-relational mapping in metadata.

19
Software Patterns Version: 4
 25 Model View Controller Splits user interface interaction into three distinct roles.
26 Money Represents a monetary value.
27 Optimistic Offline Lock Prevents conflicts between concurrent business transactions
by detecting conflict and rolling back the transaction.
28 Page Controller An object that handles a request for a specific page or action
on a web site.
29 Pessimistic Offline Lock Prevents conflicts between concurrent business transactions
by allowing only one business transaction at a time to access
data.
30 Plugin Links classes during configuration rather than compilation.
31 Query Object An object that represents a database query.
32 Record Set An in-memory representation of tabular data.
33 Registry A well-known object that other objects can use to find
common objects and services.
34 Remote Façade Provides a coarse-grained façade on fine-grained objects to
improve efficiency over a network.
35 Repository Mediates between the domain and the data mapping layers
using a collection-like interface for accessing domain objects.
36 Row Data Gateway An object that acts as a gateway to a single record in a data
source. There is one instance per row.
37 Separated Interface Defines an interface in a separate package from its
implementation.
38 Serialized LOB Saves a graph of objects by serializing them into a single large
object (LOB), which it stores in a database field.
39 Server Session State Keeps the session state on a server system in a serialized
form.
40 Service Layer Defines a application’s boundary with a layer of services that
establishes a set of available operations and coordinates the
application’s response in each operation.
41 Service Stub Removes dependence upon problematic services during
testing.
42 Single Table Inheritance Represents an inheritance hierarchy of classes as a single
table that has columns for all the fields of the various classes.
43 Special Case A subclass that provides special behavior for cases.
44 Table Data Gateway An object that acts as a gateway to a database table. One
instance handles all the rows in the table.
45 Table Module A single instance that handles the business logic for all rows
in a database table or view.
46 Template View Renders information into HTML by embedding markers in an
HTML page.
47 Transaction Script Organizes business logic by procedures where each
procedure handles a single request from the presentation.
48 Transform View A view that processes domain data element by element and
transforms it into HTML.
49 Two Step View Turns domain data into HTML in two steps: first by forming
some kind of logical page, then rendering the logical page
into HTML.

20
Software Patterns Version: 4
 50 Unit of Work Maintains a list of objects affected by a business transaction
and coordinates the writing out of changes and the resolution
of concurrency problems.
51 Value Object A small simple object, like money or a date range, whose
equality isn’t based on identity.

21
Software Patterns Version: 4
Enterprise Integration Patterns (Gregor Hohpe, Bobby Woolf)

Sr No Pattern Description
1 File Transfer Files can be used to transfer data between applications. One
disadvantage being that systems can get out of
synchronization due to infrequent updates. Producing a large
number of files for maintaining synchronization can become
prohibitive in terms of the resource cost with processing files.
2 Shared Database To gain timeliness a shared database can be used to tie
applications together. One of the big difficulties is coming p
with a suitable design. The schema may become difficult to
work with for programmers. Rigidity to change is also another
issue with shared databases. Political issues can arise
between different departments in an enterprise. Multiple
applications updating a shared database can lead to
performance bottlenecks and may cause deadlocks. Shared
databases across a WAN are too slow to be practical. A
distributed database with locking conflicts can become a
performance nightmare.
3 Remote Procedure RPI involves calling a function in another application. RPI
Invocation causes tight coupling between systems. RPIs are prone to
failure leading to invalid or incorrect data in the system.
4 Messaging Messaging is asynchronous and allows decoupling
applications. Messages can be transformed in transit.
Messaging can lead to lag issues. Another place where
messaging can cause an issue is where a user expects an
immediate response.
Messaging Systems
5 Message Channel Channels are logical addresses in a messaging system.
Messaging applications transmit data via a message channel.
6 Message A message is an atomic packet of data that can be
transmitted on a channel.
7 Pipes and Filters Is an architectural style to divide a large processing task into a
sequence of smaller, independent processing steps (filters)
that are connected by channels (pipes).
8 Message Router A router routes messages through channels.
9 Message Translator This translates a message to a format acceptable to
applications that receive the message.
10 Message Endpoint Most applications do not have any built-in capability to
interface with a messaging system. A layer of code needs to
this. This bridge code is a set of message endpoints that
enables an application to send and receive messages.
Messaging Channels
11 Point-to-Point Channel In this channel there can only be one receiver.
12 Publish-Subscribe Channel In this channel there can be multiple receivers.
13 Datatype Channel In this channel the data sent is of a particular type or format.

22
Software Patterns Version: 4
 14 Invalid Message Channel If an improper message is received and none of the receivers
can process it, then this should be moved to an invalid
message channel.
15 Dead Letter Channel A messaging system moves a message to a dead letter
channel if it is unable to deliver it.
16 Guaranteed Delivery In this a built-in data store is used to persist message. Some
messaging systems have a retry timeout built in to avoid
persisting messages for a long-time consuming disk space.
100% guarantee cannot be assumed in guaranteed delivery.
17 Channel Adapter A channel adapter follows an application whose code we do
not wish to modify for sending and receiving messages. The
adapter calls the application API and then sends and receives
messages on behalf of the application. The adapter can also
subscribe to events from the application.
Types of channel adapters:
1) User interface adapter that reads a user interface.
2) Business logic adapter that calls the public API of an
application.
3) Database adapter that can extract information from a
database. A trigger can also be a database adapter
that can send messages on table changes.
18 Messaging Bridge A messaging bridge is a connection between messaging
systems that can replicate messages. This enables connecting
messaging systems.
19 Message Bus This is similar to communication bus in a computer that
enables communication between CPU, main memory, and
peripherals. It acts as middleware between applications that
enables them to work together using messaging.
Message Construction
20 Command Message RPI is synchronous. In line with the GOF command pattern a
command object could be turned into a message that could
be passed into a message channel.
21 Document Message This is used to pass data between applications.
22 Event Message This is used for asynchronous event notification between
applications.
Push model sends information. A pull model sends minimal
information. Observers must send a request for more
information in case of a pull model.
Pull model has 3 messages:
1) Update is an event message.
2) State request is a command message where the
observer requests details from the subject.
3) State Reply is a document message the subjects uses
to send details to the observer.
23 Request-Reply This is used in the case 2 way communication is required
between applications. The request and reply traverse over
separate channels.

23
Software Patterns Version: 4
 24 Return Address If a request message contains data to send a reply to the
requester then that data is called as the return address. The
return address could be a URI for example. The reply would
be on a separate channel.
25 Correlation Identifier Every reply should contain a correlation identifier. The
correlation identifier involves 6 steps:
1) Requester – The sender of the request.
2) Replier – Application that fulfils the request and
replies.
3) Request – Message containing a request ID.
4) Reply – A message containing the correlation ID.
5) Request ID – Unique ID
6) Correlation ID – Unique ID.
26 Message Sequence In case a large piece of data is broken into chunks and is sent
as a message sequence then it is required to mark each
message with a sequence identifier fields. There are 3 fields:
1) Sequence identifier – Distinguishes this cluster of
messages from others.
2) Position identifier – Uniquely identifies and
sequentially orders message in a sequence.
3) Size or End indicator – specifies number of messages
or marks the last message.
27 Message Expiration This is used to indicate for how long a message is valid. After
the expiration the message is stale.
28 Format Indicator Specifies what the format of the message is. 3 alternatives to
implement this are version number (XML version), foreign key
(unique ID – XML doc type), format document (XML DTD).
Message Routing
29 Content-Based Router This is used to route a message based on its content. Example
in case of orders; the orders can be examined and routed to
the correct inventories.
30 Message Filter This is used to eliminate undesired messages from a channel
based on a criterion.
31 Dynamic Router This is a router that changes its configuration and routes
based on dynamic rules. The rules can be stored in a database
which on update triggers a configuration change.
32 Recipient List This is a white list which can be used to forward messages
only to the channels associated with the recipients in the list.
33 Splitter This is used to split a message into a series of messages
containing data for each item in the original message.
Example an order message can be split up into messages
based on the items present in the order.
34 Aggregator An aggregator aggregates messages into a single message.
35 Resequencer A resequencer collects and reorders messages for publishing
to a channel.

24
Software Patterns Version: 4
 36 Composed Message This splits up a composite message and routes them to
Processor channels and then waits and combines responses into a single
message.
37 Scatter-Gather This broadcasts a message to multiple recipients and
aggregates the responses into a single message.
38 Routing Slip A routing slip contains the sequence of steps that need to be
executed to process a message. The slip can be attached to a
message. Components wrapped in a special message router
then read this slip and forward the message to the next
component in the steps list.
39 Process Manager If the steps are not known at design time or are not
sequential then a process manager can be used that
maintains the state of the sequence and determines the next
step based on intermediate results.
40 Message Broker This can be used to receive messages from multiple
destinations, determine the correct destination, and route
the message to the correct destination. A message broker is
referred to as hub-and-spoke architectural style.
Message Transformation
41 Envelope Wrapper If a destination requires a different message format, then a
message can be wrapped in an envelope that conforms to its
format.
42 Content Enricher If a message from the originator does not contain all
information needed a content enricher can add required
information by querying that information from an external
source.
43 Content Filter This is used to simplify a message in the case where we do
not require all the content of the message.
44 Claim Check Moving large amounts of data across a system can be
inefficient. Instead data can be persisted, and a claim check
can be generated. The claim check can be used by another
component along with a content enricher to retrieve the
persisted data.
45 Normalizer If incoming messages are in different formats a normalizer
can be used to transform these into a common format
message. The normalizer is a custom message translator.
46 Canonical Data Model When integrating applications that use different data
formats; a common message format can be designed that will
be used by the participating applications.
Messaging Endpoints
47 Messaging Gateway A messaging gateway encapsulates messaging-specific code
and separates it from the rest of the application code. It
exposes domain-specific API to the application. The
application is thus not aware that it is using a messaging
system.

25
Software Patterns Version: 4
 48 Messaging Mapper A messaging mapper contains mapping logic between the
messaging infrastructure and the domain objects. Its acts as a
conversion layer.
49 Transactional Client A messaging system must coordinate messages so that
senders do not overwrite each other’s messages. In order to
avoid this problem a messaging system must use transactions
internally. The transaction is used to add/read or not
add/read a message to/from a channel. Both the sender and
receiver are thus transactional.
50 Polling Consumer How does a receiver (consumer) know whether there is a
new message is available? The easiest method is to
repeatedly check the channel to see if one is available. This
process is called polling and the consumer is called a polling
consumer. The disadvantage is that a polling consumer blocks
threads and consumes process time even when there are no
messages in the channel.
51 Event-Driven Consumer In this pattern the channel notifies the consumer using an
event when a message is available. The receiver is
asynchronous as it does not have a running thread until a
callback thread delivers a message.
52 Competing Consumers Sequential consumption of messages can be slow in some
cases. In such cases multiple consumers can be created on a
single channel so that messages are processed concurrently.
The consumers can be polling or event driven consumers. In
case of event driven the messaging, system must use
separate threads for each consumer for message delivery.
The consumers could be different applications unlike the
performers in a message dispatcher.
53 Message Dispatcher If there are consumers on a single channel and need to
coordinate with each other a mediator or message dispatcher
can be added that consumes messages form the channel and
then distributes them to the consumers who are now called
performers. Performers can have threads of their own to
concurrently process messages. Performers run in the same
process space as the dispatcher ergo the same application.
54 Selective Consumer This provides the ability to a consumer to select the messages
it wishes to process. Thus, the consumer filters messages
based on a criterion.
55 Durable Subscriber A durable subscriber saves messages published to avoid
missing them.
56 Idempotent Receiver Idempotent receiver can receive the same message multiple
times. It can handle the duplicate messages by de-duping
(removing duplicates) or changing the message so that it does
not affect the system.

Eg for the 2nd strategy: Change “Add $10 to account 12345”

to “Set the balance of account 12345 to $110”

26
Software Patterns Version: 4
 57 Service Activator A service activator enables a service to be written as though
its always going to be invoked synchronously. The activator
receives a message and then determines the service to invoke
synchronously. The service, in this case, was not designed to
work with messaging. The activator wraps and synchronously
invokes the service.
System Management
58 Control Bus The control bus is used to administer a messaging system
across multiple platforms and a wide geographic area. It uses
the same messaging mechanism used by the application data
but uses separate channels to transmit data that is relevant
to the management of components involved in the message
flow.
The types of messages that flow in a control bus are:
1) Configuration – Channel addresses, message data
formats, timeouts etc. are configuration messages.
2) Heartbeat – Each component can send heartbeats so
that a central console application can verify the
functioning of that component.
3) Test Messages – Inject test messages to verify
component functioning along with heartbeat.
4) Exceptions – Each component can channel exception
conditions so that they are evaluated in a central
handler.
5) Statistics – Number of messages processed, average
throughput, average time to process a message, and
so on can be collected by components and sent on
low priority channels. This can be used to check
whether certain messages are flooding the system.
6) Live Console – Operators can use this console to
assess the health of the system and take corrective
actions.
59 Detour A detour is where message can be routed via an alternate
path containing additional steps or be routed normally.
60 Wire Tap In a point-to-point channel a wire tap can be added that can
be used to inspect messages. The wire tap publishes the
messages to the main as well as a secondary channel.
61 Message History A message history is a list of all applications or components
that a message passed through since its origination. This list is
attached to a message and can used to analyze and debug
the flow of messages in a loosely coupled system.
62 Message Store A message store can be used to store information about each
message in a central location. This can be used for reporting.
63 Smart Proxy A smart proxy intercepts messages and replaces the return
address with its own address. It also stores the original return
address. It is used to track both request and reply messages.

27
Software Patterns Version: 4
 64 Test Message Covered in control bus. If a component garbles outgoing
messages due to an internal fault then test messages can be
used to diagnose this fault. This relies on:
1) Test data generator
2) Test message injector
3) Test message separator – extracts results.
4) Test data verifier – compares actual with expected
results.
65 Channel Purger This is used to remove unwanted messages from a channel.

28
Software Patterns Version: 4
Cloud Design Patterns

Sr Pattern Description
No
1 Ambassador This is a out-of-process proxy that sends network requests on behalf of
a consumer service or application.

Monitoring, logging, routing, security tasks can be offloaded to this

service.
2 Anti-Corruption Layer Façade or adapter pattern for the cloud. Acts as a translation layer.
3 Backends for Frontends https://docs.microsoft.com/en-
us/azure/architecture/patterns/backends-for-frontends
Create separate backend services to be consumed by specific frontend
applications or interfaces. This pattern is useful when you want to
avoid customizing a single backend for multiple interfaces. This
pattern was first described by Sam Newman.
4 Bulkhead https://docs.microsoft.com/en-
us/azure/architecture/patterns/bulkhead
The Bulkhead pattern is a type of application design that is tolerant of
failure. In a bulkhead architecture, elements of an application are
isolated into pools so that if one fails, the others will continue to
function. It's named after the sectioned partitions (bulkheads) of a
ship's hull. If the hull of a ship is compromised, only the damaged
section fills with water, which prevents the ship from sinking.

A cloud-based application may include multiple services, with each

service having one or more consumers. Excessive load or failure in a
service will impact all consumers of the service.

Partition service instances into different groups, based on consumer

load and availability requirements. This design helps to isolate failures,
and allows you to sustain service functionality for some consumers,
even during a failure.
5 Cache-aside Load data on demand into a cache from a data store. This pattern can
improve performance and also helps to maintain consistency between
data held in the cache and the data in the underlying data store.
6 Choreography https://docs.microsoft.com/en-
us/azure/architecture/patterns/choreography
Have each component of the system participate in the decision-
making process about the workflow of a business transaction, instead
of relying on a central point of control.
7 Circuit Breaker Handle faults that may take a variable amount of time to rectify when
connecting to a remote service or resource. This pattern can improve
the stability and resiliency of an application.
8 Claim-Check https://docs.microsoft.com/en-us/azure/architecture/patterns/claim-
check

29
Software Patterns Version: 4
 Split a large message into a claim check and a payload. Send the claim
check to the messaging platform and store the payload to an external
service. This pattern allows large messages to be processed, while
protecting the message bus and the client from being overwhelmed or
slowed down. This pattern also helps to reduce costs, as storage is
usually cheaper than resource units used by the messaging platform.

This pattern is also known as Reference-Based Messaging, and was

originally described in the book Enterprise Integration Patterns, by
Gregor Hohpe and Bobby Woolf.
9 Compensating Transaction Undo the work performed by a series of steps, which together define
an eventually consistent operation, if one or more of the operations
fails. Operations that follow the eventual consistency model are
commonly found in cloud-hosted applications that implement complex
business processes and workflows.
10 Competing Consumers Enable multiple concurrent consumers to process messages received
on the same messaging channel. This pattern enables a system to
process multiple messages concurrently to optimize throughput, to
improve scalability and availability, and to balance the workload.
11 Compute Resource Consolidate multiple tasks or operations into a single computational
Consolidation unit. This pattern can increase compute resource utilization, and
reduce the costs and management overhead associated with
performing compute processing in cloud-hosted applications.
12 CQS https://en.wikipedia.org/wiki/Command%E2%80%93query_separation
(CommandQuerySeperation) https://martinfowler.com/bliki/CommandQuerySeparation.html

Every method should be either a command or query but not both.

Queries should not change the state. Commands change the state but
do not return values.
13 Command and Query Segregate operations that read data from operations that update data
Responsibility Segregation by using separate interfaces. This pattern can maximize performance,
(CQRS) scalability, and security; support evolution of the system over time
through higher flexibility; and prevent update commands from causing
merge conflicts at the domain level
14 Event Sourcing Use an append-only store to record the full series of events that
describe actions taken on data in a domain, rather than storing just
the current state, so that the store can be used to materialize the
domain objects. This pattern can simplify tasks in complex domains by
avoiding the requirement to synchronize the data model and the
business domain; improve performance, scalability, and
responsiveness; provide consistency for transactional data; and
maintain full audit trails and history that may enable compensating
actions.
15 External Configuration Store Move configuration information out of the application deployment
package to a centralized location. This pattern can provide
opportunities for easier management and control of configuration

30
Software Patterns Version: 4
 data, and for sharing configuration data across applications and
application instances.
16 Federated Identity Delegate authentication to an external identity provider. This pattern
can simplify development, minimize the requirement for user
administration, and improve the user experience of the application.
17 Gatekeeper Protect applications and services by using a dedicated host instance
that acts as a broker between clients and the application or service,
validates and sanitizes requests, and passes requests and data
between them. This pattern can provide an additional layer of
security, and limit the attack surface of the system.
18 Gateway Aggregation https://docs.microsoft.com/en-
us/azure/architecture/patterns/gateway-aggregation
Use a gateway to aggregate multiple individual requests into a single
request. This pattern is useful when a client must make multiple calls
to different backend systems to perform an operation.
19 Gateway Offloading https://docs.microsoft.com/en-
us/azure/architecture/patterns/gateway-offloading
Offload shared or specialized service functionality to a gateway proxy.
This pattern can simplify application development by moving shared
service functionality, such as the use of SSL certificates, from other
parts of the application into the gateway.
20 Gateway Routing https://docs.microsoft.com/en-
us/azure/architecture/patterns/gateway-routing
Route requests to multiple services using a single endpoint. This
pattern is useful when you wish to expose multiple services on a single
endpoint and route to the appropriate service based on the request.
21 Health Endpoint Monitoring Implement functional checks within an application that external tools
can access through exposed endpoints at regular intervals. This
pattern can help to verify that applications and services are
performing correctly.
22 Index Table Create indexes over the fields in data stores that are frequently
referenced by query criteria. This pattern can improve query
performance by allowing applications to more quickly retrieve data
from a data store.
23 Leader Election Coordinate the actions performed by a collection of collaborating task
instances in a distributed application by electing one instance as the
leader that assumes responsibility for managing the other instances.
This pattern can help to ensure that tasks do not conflict with each
other, cause contention for shared resources, or inadvertently
interfere with the work that other task instances are performing.
24 Materialized View Generate prepopulated views over the data in one or more data stores
when the data is formatted in a way that does not favor the required
query operations. This pattern can help to support efficient querying
and data extraction, and improve application performance.
25 Pipes and Filters Decompose a task that performs complex processing into a series

31
Software Patterns Version: 4
 of discrete elements that can be reused. This pattern can improve
performance, scalability, and reusability by allowing task elements that
perform the processing to be deployed and scaled independently.
26 Priority Queue Prioritize requests sent to services so that requests with a higher
priority are received and processed more quickly than those of a lower
priority. This pattern is useful in applications that offer different
service level guarantees to individual types of client.
27 Publisher-Subscriber Enable an application to announce events to multiple interested
consumers asynchronously, without coupling the senders to the
receivers.
28 Queue-based Load Leveling Use a queue that acts as a buffer between a task and a service that it
invokes in order to smooth intermittent heavy loads that may
otherwise cause the service to fail or the task to timeout. This pattern
can help to minimize the impact of peaks in demand on availability and
responsiveness for both the task and the service.
29 Retry Enable an application to handle temporary failures when connecting
to a service or network resource by transparently retrying the
operation in the expectation that the failure is transient. This pattern
can improve the stability of the application.
30 Runtime Reconfiguration Design an application so that it can be reconfigured without requiring
redeployment or restarting the application. This helps to maintain
availability and minimize downtime.
31 Scheduler Agent Supervisor Coordinate a set of actions across a distributed set of services and
other remote resources, attempt to transparently handle faults if any
of these actions fail, or undo the effects of the work performed if the
system cannot recover from a fault. This pattern can add resiliency to
a distributed system by enabling it to recover and retry actions that fail
due to transient exceptions, long-lasting faults, and process failures.
32 Sharding Divide a data store into a set of horizontal partitions shards. This
pattern can improve scalability when storing and accessing large
volumes of data.
33 Sidecar https://docs.microsoft.com/en-
us/azure/architecture/patterns/sidecar
Deploy components of an application into a separate process or
container to provide isolation and encapsulation. This pattern can also
enable applications to be composed of heterogeneous components
and technologies.
This pattern is named Sidecar because it resembles a sidecar attached
to a motorcycle. In the pattern, the sidecar is attached to a parent
application and provides supporting features for the application. The
sidecar also shares the same lifecycle as the parent application, being
created and retired alongside the parent. The sidecar pattern is
sometimes referred to as the sidekick pattern and is a decomposition
pattern.
34 Strangler https://docs.microsoft.com/en-
us/azure/architecture/patterns/strangler

32
Software Patterns Version: 4
 Incrementally migrate a legacy system by gradually replacing specific
pieces of functionality with new applications and services. As features
from the legacy system are replaced, the new system eventually
replaces all of the old system's features, strangling the old system and
allowing you to decommission it.
35 Static Content Hosting Deploy static content to a cloud-based storage service that can deliver
these directly to the client. This pattern can reduce the requirement
for potentially expensive compute instances.
36 Throttling Control the consumption of resources used by an instance of an
application, an individual tenant, or an entire service. This pattern
can allow the system to continue to function and meet service level
agreements, even when an increase in demand places an extreme load
on resources.
37 Valet Key Use a token or key that provides clients with restricted direct access
to a specific resource or service in order to offload data transfer
operations from the application code. This pattern is particularly
useful in applications that use cloud-hosted storage systems or
queues, and can minimize cost and maximize scalability and
performance.
38 Event Sourcing https://martinfowler.com/eaaDev/EventSourcing.html
https://docs.microsoft.com/en-us/azure/architecture/patterns/event-
sourcing

Limitations of CRUD:
• Perform updates directly against a data store impacting
performance.
• Update conflicts due to concurrent transactions.
• History of changes (audit trails) lost if a log mechanism is
absent or not reliable.

In this pattern changes to data are handled as a series of events. Each

event is thus a set of changes to data. Events are immutable. These
events are recorded in an append-only store. Consumers can subscribe
to these events to update their states or create a materialized view for
presentation.
These events can be queried, used to reconstruct past states, and act
as a log of changes.
This can be used with CQRS.

33
Software Patterns Version: 4
Design patterns used in embedded systems

1. https://www.eventhelix.com/RealtimeMantra/Patterns/
2. https://github.com/ksvbka/design_pattern_for_embedded_system/blob/master/design-
patterns-for-embedded-systems-in-c-an-embedded-software-engineering-toolkit.pdf
3. https://d-nb.info/1007034963/34 - See chapters 7 and 8

34
Software Patterns Version: 4
AntiPatterns

Software Development AntiPatterns

https://sourcemaking.com/antipatterns/software-development-antipatterns

https://deviq.com/antipatterns/

Software Architecture AntiPatterns

https://sourcemaking.com/antipatterns/software-architecture-antipatterns

https://en.wikibooks.org/wiki/Introduction_to_Software_Engineering/Architecture/Anti-Patterns

Project Management AntiPatterns

https://sourcemaking.com/antipatterns/software-project-management-antipatterns

35
Software Patterns Version: 4
System design

https://github.com/donnemartin/system-design-primer/

https://www.educative.io

ThoughtWorks – Technology Radar

https://www.thoughtworks.com/radar

36
Software Patterns Version: 4