Skip to main content
Abstract Document

Intent

The Abstract Document design pattern is a structural design pattern that aims to provide a consistent way to handle hierarchical and tree-like data structures by defining a common interface for various document types. It separates the core document structure from specific data formats, enabling dynamic updates and simplified maintenance.


iluwatarAbout 4 minStructuralAbstractionExtensibilityDecoupling
Abstract Factory

Also known as

Kit

Intent

The Abstract Factory design pattern provides a way to create families of related objects without specifying their concrete classes. This allows for code that is independent of the specific classes of objects it uses, promoting flexibility and maintainability.


iluwatarAbout 3 minCreationalAbstractionDecouplingGang of Four
Acyclic Visitor

Intent

The Acyclic Visitor pattern decouples operations from an object hierarchy, allowing you to add new operations without modifying the object structure directly.

Explanation

Real world example

We have a hierarchy of modem classes. The modems in this hierarchy need to be visited by an external algorithm based
on filtering criteria (is it Unix or DOS compatible modem).


iluwatarAbout 2 minBehavioralDecouplingExtensibility
Aggregator Microservices

Intent

The user makes a single call to the aggregator service, and the aggregator then calls each relevant microservice.

Explanation

Real world example

Our web marketplace needs information about products and their current inventory. It makes a call to an aggregator
service which in turn calls the product information microservice and product inventory microservice returning the
combined information.


iluwatarAbout 1 minArchitecturalCloud distributedDecouplingMicroservices
Ambassador

Intent

Provide a helper service instance on a client and offload common functionality away from a shared resource.

Explanation

Real world example

A remote service has many clients accessing a function it provides. The service is a legacy application and is
impossible to update. Large numbers of requests from users are causing connectivity issues. New rules for request
frequency should be implemented along with latency checks and client-side logging.


iluwatarAbout 2 minStructuralDecouplingCloud distributed
API Gateway

Intent

Aggregate calls to microservices in a single location, the API Gateway. The user makes a single call
to the API Gateway, and the API Gateway then calls each relevant microservice.

Explanation

With the Microservices pattern, a client may need data from multiple different microservices. If the
client called each microservice directly, that could contribute to longer load times, since the
client would have to make a network request for each microservice called. Moreover, having the
client call each microservice directly ties the client to that microservice - if the internal
implementations of the microservices change (for example, if two microservices are combined sometime
in the future) or if the location (host and port) of a microservice changes, then every client that
makes use of those microservices must be updated.


iluwatarAbout 2 minArchitecturalCloud distributedDecouplingMicroservices
Balking

Intent

Balking Pattern is used to prevent an object from executing a certain code if it is in an incomplete
or inappropriate state.

Explanation

Real world example

There's a start-button in a washing machine to initiate the laundry washing. When the washing
machine is inactive the button works as expected, but if it's already washing the button does
nothing.


iluwatarAbout 2 minConcurrencyDecoupling
Business Delegate

Intent

The Business Delegate pattern adds an abstraction layer between
presentation and business tiers. By using the pattern we gain loose coupling
between the tiers and encapsulate knowledge about how to locate, connect to,
and interact with the business objects that make up the application.


iluwatarAbout 2 minStructuralDecoupling
Circuit Breaker

Intent

Handle costly remote service calls in such a way that the failure of a single service/component
cannot bring the whole application down, and we can reconnect to the service as soon as possible.

Explanation

Real world example

Imagine a web application that has both local files/images and remote services that are used for
fetching data. These remote services may be either healthy and responsive at times, or may become
slow and unresponsive at some point of time due to variety of reasons. So if one of the remote
services is slow or not responding successfully, our application will try to fetch response from
the remote service using multiple threads/processes, soon all of them will hang (also called
thread starvation) causing our entire web application to crash. We should be able to detect
this situation and show the user an appropriate message so that he/she can explore other parts of
the app unaffected by the remote service failure. Meanwhile, the other services that are working
normally, should keep functioning unaffected by this failure.


iluwatarAbout 5 minBehavioralPerformanceDecouplingCloud distributed
Client Session Pattern

Name

Client Session pattern

Intent

  • Create stateless servers that removes the problem of clustering, as users can switch between servers seamlessly.
  • Makes data more resilient in case of server fail-over.
  • Works well with smaller data sizes.

iluwatarAbout 2 minArchitecturalDecoupling
2
3
4
5