Problem: Segmenting software for independent development, modifiability,
and reuse with minimal interaction between parts.
Solution: Divides software into layers (e.g., presentation, business,
persistence, database). Each layer has specific roles and responsibilities.
Closed layers: Requests must pass through each layer directly below.
Open layers: Requests can skip layers.
Weakness: Can lead to performance penalties; adds up-front cost and
complexity.
Usages: Small, simple applications or websites, projects with tight budgets
and time constraints.
Multi-Tier Pattern
Context: Distributing a system's infrastructure into distinct subsets.
Problem: Splitting a system into computationally independent execution
structures (software and hardware groups).
Solution: Organizes the system into tiers, which are logical groupings of
components.
Weakness: Substantial up-front cost and complexity.
Usages: Distributed systems.
Pipe and Filter
Context: Systems that transform streams of discrete data, with a need for
reusable, independent transformation parts.
Problem: Dividing systems into reusable, loosely coupled components with
simple, generic interaction mechanisms for flexible combination and
parallel execution.
Solution: Uses pipes (unidirectional, point-to-point communication
channels) to connect filters.
Filters:
Producer (source): Starts a process.
Transformer (map): Modifies data.
•Tester (reduce): Checks criteria.
•Consumer (sink): Terminates a process.
Weakness: Not ideal for interactive systems; excessive parsing/unparsing
can degrade performance and increase filter complexity.
Usages: Simple, one-way data processing tasks (e.g., EDI, ETL tools,
compilers).
Client-Server
Context: Many distributed clients needing to access shared resources and
services with controlled access.
Problem: Managing shared resources and services to promote
modifiability, reuse, scalability, and availability.
Solution: Clients send requests to a server, which processes them and
sends replies.
Weakness: Server can be a performance bottleneck and a single point of
failure; decisions about functionality placement can be complex and costly
to change.
Usages: Online applications like email, document sharing, and banking.
Model-View-Controller (MVC)
Context: Interactive applications where the user interface is frequently
modified and multiple views of data are needed.
Problem: Separating UI functionality from application functionality while
remaining responsive to user input or data changes; coordinating multiple
UI views.
Solution: Separates application functionality into three components:
Model: Contains the application's data.
View: Displays a portion of data and interacts with the user.
Controller: Mediates between the model and view, managing state change
notifications.
Weakness: May be overly complex for simple UIs; abstractions might not
fit all UI toolkits well.
Usages: Common in web and mobile application user interface
development.
Event-Driven Architecture
Context: Providing computational and information resources to handle
incoming independent asynchronous application-generated events at
scale.
Problem: Constructing distributed systems that can service asynchronous
event-related messages and scale from small to complex.
Solution: Deploys independent event processes/processors to handle
events. Arriving events are queued, and a scheduler distributes them to
appropriate handlers.
Weakness: Performance and error recovery can be challenges.
Usages: E-commerce applications (e.g., order creation publishing events
like "OrderCreated," "Credit Reserved," or "CreditLimitExceeded").
Microservices Architecture
Context: Deploying server-based enterprise applications supporting
various clients and handling requests via business logic, databases, and
messaging.
Problem: Monolithic applications becoming too large and complex for
efficient support and optimal distributed resource utilization (especially in
cloud environments).
Solution: Builds applications as suites of small, independent services.
Each service is:
•
Independently deployable and scalable.
•
Has its own API boundary.
•
Can be written in different programming languages.
•
Manages its own database.
•
Developed by different teams.
Weakness: Systems must be designed to tolerate service failures (requires
more monitoring); increased overhead for service choreography and event
collaboration; higher memory usage.
Usages: Use cases with extensive data pipelines, such as reporting
systems where each step (data collection, cleansing, aggregation) is
handled by a separate microservice