45,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Learn the importance of architectural and design patterns in producing and sustaining next-generation IT and business-critical applications with this guide.
About This Book
- Use patterns to tackle communication, integration, application structure, and more
- Implement modern design patterns such as microservices to build resilient and highly available applications
- Choose between the MVP, MVC, and MVVM patterns depending on the application being built
Who This Book Is For
This book will empower and enrich IT architects (such as enterprise architects, software product architects, and solution and system architects), technical consultants, evangelists, and experts.
What You Will Learn
- Understand how several architectural and design patterns work to systematically develop multitier web, mobile, embedded, and cloud applications
- Learn object-oriented and component-based software engineering principles and patterns
- Explore the frameworks corresponding to various architectural patterns
- Implement domain-driven, test-driven, and behavior-driven methodologies
- Deploy key platforms and tools effectively to enable EA design and solutioning
- Implement various patterns designed for the cloud paradigm
In Detail
Enterprise Architecture (EA) is typically an aggregate of the business, application, data, and infrastructure architectures of any forward-looking enterprise. Due to constant changes and rising complexities in the business and technology landscapes, producing sophisticated architectures is on the rise. Architectural patterns are gaining a lot of attention these days.
The book is divided in three modules. You'll learn about the patterns associated with object-oriented, component-based, client-server, and cloud architectures. The second module covers Enterprise Application Integration (EAI) patterns and how they are architected using various tools and patterns. You will come across patterns for Service-Oriented Architecture (SOA), Event-Driven Architecture (EDA), Resource-Oriented Architecture (ROA), big data analytics architecture, and Microservices Architecture (MSA). The final module talks about advanced topics such as Docker containers, high performance, and reliable application architectures. The key takeaways include understanding what architectures are, why they're used, and how and where architecture, design, and integration patterns are being leveraged to build better and bigger systems.
Style and Approach
This book adopts a hands-on approach with real-world examples and use cases.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 530
Veröffentlichungsjahr: 2017
Ähnliche
BIRMINGHAM - MUMBAI
Architectural Patterns
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: December 2017
Production reference: 1211217
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78728-749-5
www.packtpub.com
Credits
Authors
Pethuru Raj
Anupama Raman
Harihara Subramanian
Copy Editor
Safis Editing
Reviewer
Dr. Kayarvizhy N
Project Coordinator
Vaidehi Sawant
Commissioning Editor
Aaron Lazar
Proofreader
Safis Editing
Acquisition Editor
Chaitanya Nair
Indexer
Francy Puthiry
Content Development Editor
Rohit Kumar Singh
Graphics
Jason Monteiro
Technical Editor
Ketan Kamble
Production Coordinator
Shantanu Zagade
About the Authors
Pethuru Raj holds the PhD degree in computer science and works as the chief architect and vice-president of the Site Reliability Engineering (SRE) division of Reliance Jio Infocomm. Ltd (RJIL), Bangalore. He previously worked as a cloud infrastructure architect in the IBM Global Cloud Center of Excellence (CoE), IBM India, and as a TOGAF-certified Enterprise Architecture (EA) consultant in the Wipro Consulting Services (WCS) division, Bangalore. He also had a fruitful stint as a lead architect in the Corporate Research (CR) division of Robert Bosch, Bangalore. He has more than 17 years of IT industry experience and 8 years of research experience. He has authored eight books thus far and co-authored the Learning Docker book by Packt.
Anupama Raman recently joined Flipkart as a senior manager. Prior to this, she worked as an architect in the IBM Business Analytics Business Unit (smarter cities product lines) in the IBM Software labs. She has worked extensively on all IBM business analytics product lines, which include products and technologies on predictive and prescriptive analytics. She is very passionate about storage area networking, data centers, and cloud technologies. Anupama is EMC certified as a cloud infrastructure and services management professional, data center architect, storage and management professional, networking design and management professional, and EMC Technology Foundation professional.
Harihara Subramanian works for SABRE Corporation as a principal software architect. He has been evolving and practicing software development and various software architecture concepts since 1999. He is an energetic and highly focused technology leader with a proven track record in software development, software architecture principles, and implementations. He has been an active contributor to various online and offline forums in different technologies and focuses on technology consulting, software development, SOA, and more.
About the Reviewer
Dr. Kayarvizhy N is currently working as an associate professor in the computer science department of BMS College of Engineering, Bangalore. She has over 12 years of experience in academia. She obtained her bachelor's and master's of technology degrees in computer science from Pondicherry University. She was awarded her doctoral degree from Anna University in 2014 for her work in object-oriented metrics. She has published over 17 papers in various journals and conferences and is actively guiding research scholars in several emerging areas. She has also helped set up the IoT curriculum and lab in her department and is pursuing a project sponsored by the Government of Karnataka through the VGST grant program.
www.PacktPub.com
For support files and downloads related to your book, please visit www.PacktPub.com. Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details. At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Fully searchable across every book published by Packt
Copy and paste, print, and bookmark content
On demand and accessible via a web browser
Customer Feedback
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review on this book's Amazon page at https://www.amazon.com/dp/1787287491.
If you'd like to join our team of regular reviewers, you can e-mail us at [email protected]. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Table of Contents
Preface
What this book covers
What you need for this book
Who this book is for
Conventions
Reader feedback
Downloading the color images of this book
Errata
Piracy
Questions
Demystifying Software Architecture Patterns
Envisioning the software-defined world
Software patterns
Why software patterns?
The prime ingredients of a software pattern
The types of software patterns
Software architecture patterns
Object-oriented architecture (OOA)
Component-based assembly (CBD) architecture
Domain-driven design (DDD) architecture
Client/server architecture
Multi-tier distributed computing architecture
Layered/tiered architecture
Event-driven architecture (EDA)
The major issues with EDA
Service-oriented architecture (SOA)
Service-inspired integration (SOI)
Event-driven service-oriented architecture
The EDA fundamental principles
The ED-SOA composite pattern benefits
Microservices architecture (MSA)
Event-driven microservices patterns
Space-based architecture (SBA)
Combining architecture patterns
Special-purpose architectures
Real-time context-aware prediction architecture
Summary
Additional reading materials
Client/Server Multi-Tier Architectural Patterns
Domain name service (DNS) server and DNS client
The workings of a DNS
Functional requirements in two-tier client-server patterns
Distribution of functional requirements in a client-server pattern
The remote data access client-server pattern
The remote presentation client-server pattern
The split logic data client-server architecture pattern
The three-tier pattern / multi-tier pattern client-server
The master-slave pattern
Issues in the master-slave pattern
Peer-to-peer patterns
Advantages of two-tier client-server patterns
Design considerations - when to use a two-tier client-server pattern?
Limitations of two-tier client-server patterns
Three-tier client-server architecture
Design considerations for using three-tier architecture
Design considerations for n-tier architecture
An example of n-tier architecture (shopping cart web application)
The distributed client-server architecture
Motivation for development of web application patterns
Workings of the MVC pattern
The ASP.Net framework
The model view presenter (MVP) pattern
The model-view-viewmodel (MVVM) pattern
Key advantages of the MVVM pattern
Design considerations for using the MVVM pattern
Prism
Design patterns for web application development
The front controller pattern
Spring framework
Summary
Object-Oriented Software Engineering Patterns
Key elements of OOD
Additional elements of OOD
Design principles
Single responsibility principle (SRP) – SOLID
Open and close principle – SOLID
Liskov substitution principle (LSP) – SOLID
Interface segregation principle (ISP) – SOLID
Dependency inversion principle (DIP) – SOLID
Other common design principles
OO design patterns
Creational design patterns
Factory method (virtual constructor)
Abstract factory (kit)
Builder
Prototype
Singleton
Structural design patterns
Adapter class (wrapper)
Adapter (object)
Bridge (handle/body)
Composite
Decorator
Façade
Flyweight
Proxy
Behavioral patterns
Chain of responsibility
Command (action/transaction)
Interpreter
Iterator (cursor)
Mediator
Memento
Observer (dependents/publish/subscribe)
State (objects for states)
Strategy (policy)
The template method
Visitor
Concurrency patterns
Concurrency design pattern
Producer-consumer
Active object
Monitor object
Concurrency architectural pattern
Summary
References
Enterprise Integration Patterns
Need for integration patterns
Integration scenarios in enterprises
Information portal
Data replication
Shared business function
Service-oriented architecture
Distributed business process management
The business-to-business integration
Main challenges in enterprise integration
File transfer
Shared database
Remote procedure invocation
Messaging
Getting started with messaging patterns
Pipe and filter pattern
Message router pattern
Message translator pattern
Message endpoint pattern
Point-to-point channel pattern
Publish-subscribe channel pattern
Datatype channel pattern
Message bus patterns
Command message patterns
Event message patterns
Request-reply pattern
Content-based router pattern
Message filter pattern
Resequencer pattern
Polling consumer pattern
Channel adapter
Mobile integration pattern
Request-response pattern
Defining a push notification pattern
API management pattern
Summary
Domain-Driven Design (DDD) Principles and Patterns
Principles, characteristics, and practices of DDD
Principles
Focusing on the core domain
Collaborate and learn
Model the domain
Evolve
Talk in ubiquitous language
Characteristics
Best practices
DDD patterns
Strategic patterns
Ubiquitous language
Domain, subdomain, and core domain
Bounded contexts
Integrating bounded contexts
Autonomous bounded context
The shared-nothing architecture
Single responsibility codes
Multiple bounded contexts (within a solution)
Adoption of SOA principles
Integrating with legacy systems
The bubble context
The anti-corruption layer
Expose as a service
Distributed bounded context integration strategies
Database integration
Flat file integration
Event-driven architecture and messaging
Tactical patterns
Patterns to model the domain
Entities
Value objects
Domain services
Modules
Aggregates
Factories
Repositories
Emerging patterns
Domain events
Event sourcing
Other patterns
Summary
References and further reading materials
Enterprise Architecture Platforms and Tools
Overview of enterprise architecture frameworks
Getting started with TOGAF
Architecture development method (ADM)
Deliverables, artifacts, and building blocks
Enterprise continuum
Architecture repository
Advantages of using TOGAF
Limitations of TOGAF
Zachman framework for enterprise architecture
Advantages
Restrictions
Guidelines for choosing EAF
Enterprise architecture platforms and tools
Enterprise Architect from Sparx Systems
Dragon1
ABACUS from avolution software
Architecture of ABACUS
Summary
References
Service-Oriented Architecture (SOA)
Web services and SOA
Introduction to SOA
Life cycle of SOA
Primary characteristics of SOA
Service interconnectivity with well-defined interfaces
Standard interfaces and Service level agreements
Event-driven and messaging
Flexible
Evolution
Principles of SOA
Standardized service contract
Service interoperability
Service abstraction
Service autonomy
Service composability
Service discoverability
Service loose coupling
Service reusability
Service statelessness
SOA design patterns
Service messaging
Message screening
Agnostic services
Atomic service transaction
Authentication broker
Message origin authentication
Service façade
Multiple service contract
Service callback
Event-driven messaging
Service refactoring
Metadata centralization
Principles and patterns cross reference
Summary
Event-Driven Architectural Patterns
Service-oriented architecture and event-driven architecture (SOA versus EDA)
Key characteristics of event-driven patterns
Components of an EDA pattern
Event flow layers
Event generators
Event channel
Event processing
Downstream event-driven activity
Design considerations for event-driven patterns
Implementation variants of EDA patterns
Simple event processing patterns
Event stream processing patterns
Complex event processing (CEP) patterns
Types of event-driven patterns
Event mediator topology pattern
Event broker topology pattern
Hub and spoke pattern
Broadcast pattern
Polling pattern
EDA pattern implementation in systems/processes
Event log
Event collectors
Reply queue
Improving the performance of EDA-based processes/systems
IBM WebSphere MQ
Emerging trends in EDA
Event-driven microservices
Complex event processing
Internet of Things (IoT) and EDA
References
Summary
Microservices Architecture Patterns
Microservices patterns
Decomposition patterns
Decomposition by use case pattern
Decomposition by resources pattern
Decomposition by business capability pattern
Decomposition by subdomain pattern
Microservices deployment pattern
Multiple service instances per host pattern
Single service instance per host pattern
Service instance per VM pattern
Service instance per container pattern
Serverless deployment pattern
Service deployment platform pattern
Microservices design patterns
Aggregator microservice design pattern
Proxy microservice design pattern
Chained microservice design pattern
Microservice chassis pattern
Externalized configuration pattern
Microservices database patterns
Database per service pattern
Shared data design pattern
Shared database pattern
Command-query responsibility segregation (CQRS) pattern
Microservices integration patterns
Remote procedure invocation (RPI) pattern
Messaging design pattern
Asynchronous messaging design pattern
Domain-specific protocol pattern
API gateway pattern
Backend for frontend pattern
Microservices registration, discovery, and usage patterns
Service discovery pattern
Service registry pattern
Service registration pattern
Event-driven architecture (EDA) patterns
Event sourcing pattern
Transaction log tailing pattern
Publishing events using the database trigger pattern
Application publishes events pattern
Testing and troubleshooting patterns
Access token pattern
Service component test pattern
Log aggregation pattern
Application metrics pattern
Audit logging pattern
Distributed tracing pattern
Exception tracking pattern
Health check API pattern
Microservices composition patterns
Server-side page fragment composition pattern
Client-side UI composition pattern
Messaging-based microservices composition pattern
Resilient and reliable microservices patterns
Circuit breaker pattern
Shared caching layer pattern
High availability microservices pattern
Concurrent requests for data pattern
Event store pattern
Event streams and the unified event log pattern
Asynchronous command calls pattern
Summary
Patterns for Containerized and Reliable Applications
Introduction
The key drivers for containerization
Design patterns for Docker containers
Container building patterns
Docker image building patterns
Multi-stage image building pattern
The pattern for file sharing between containers
Using bind-mount volumes
Pipes and filters pattern
Containerized applications - Autopilot pattern
Containers - persistent storage patterns
The context for persistent storages
The persistent storage options
Volumes
Bind mounts
The tmpfs mounts
Docker compose configuration pattern
Docker container anti-patterns
Installing an OS inside a Docker container
Go for optimized Docker images
Storing container images only inside a container registry
Hosting only one service inside a container
Latest doesn't mean best
Docker containers with SSH
IP addresses of a container
Root user
Dependency between containers
Patterns for highly reliable applications
Resiliency implementation strategies
The testing approaches for resiliency
The resilient deployment approaches
The deployment patterns
Monitoring and diagnostics
Resiliency realization patterns
Circuit breaker pattern
Bulkhead pattern
Compensating transaction pattern
Health endpoint monitoring pattern
Leader election pattern
Queue-based load leveling pattern
Retry pattern
Summary
Software-Defined Clouds - the Architecture and Design Patterns
Reflecting the cloud journey
Traditional application architecture versus cloud application architecture
The traditional application architecture
The cloud architecture
The cloud application architecture
Cloud integration patterns
Tier/Layer-based decomposition
Process-based decomposition
Pipes-and-filters-based decomposition
Service messaging pattern
Messaging metadata pattern
Service agent pattern
Intermediate routing pattern
State messaging pattern
Service callback pattern
Service instance routing
Asynchronous queuing pattern
Reliable messaging pattern
Cloud design patterns
Cache-aside pattern
Circuit breaker pattern
Compensating transaction pattern
Competing consumers pattern
Compute resource consolidation pattern
Command and query responsibility segregation (CQRS) pattern
Event sourcing pattern
External configuration store pattern
Federated identity pattern
Gatekeeper pattern
Application health monitoring pattern
Leader election pattern
Materialized views pattern
Pipes and filters pattern
Priority queue pattern
Queue-based load leveling pattern
Retry pattern
Runtime reconfiguration pattern
Scheduler agent supervisor pattern
Sharding pattern
Throttling pattern
Workload distribution pattern
Cloud workload scheduler pattern
Cloud reliability and resilience patterns
Resource pooling pattern
Resource reservation pattern
Hypervisor clustering pattern
Redundant storage pattern
Dynamic failure detection and recovery pattern
Redundant physical connection for virtual servers pattern
Cloud security patterns
Cryptographic key management system pattern
Virtual private network (VPN) pattern
Cloud authentication gateway pattern
In-transit cloud data encryption pattern
Cloud storage device masking pattern
Cloud storage data at rest encryption pattern
Endpoint threat detection and response pattern
Threat intelligence processing pattern
Cloud denial of service (DoS) protection pattern
Summary
Bibliography
Big Data Architecture and Design Patterns
The four V's of big data
Big data analysis and technology concepts
Data analysis life cycle
Big data analysis and data science
Data analysis
Data science
Big data platform
Big data engineering
Big data governance
Big data architecture landscape and layers
Big data architecture patterns
MapReduce pattern
Lambda architecture pattern
Data lake architecture pattern
Big data design patterns
Data sources and ingestion layer
Multisource extractor
Multidestination pattern
Protocol converter
Just-In-Time (JIT) transformation pattern
Real-time streaming pattern
Big data workload patterns
Data storage layer
ACID versus BASE versus CAP
Façade pattern
NoSQL pattern
Polyglot pattern
Data access layer
Connector pattern
Lightweight stateless pattern
Service locator pattern
Near real-time pattern
Stage transform pattern
Rapid data analysis pattern
Data discovery and analysis layer
Data queuing pattern
Index-based insight pattern
Machine learning pattern
Converge(r) pattern
Data visualization layer
First glimpse pattern
Portal pattern
Mashup view pattern
Compression pattern
Exploder pattern
Summary
References
Preface
Heterogeneity, along with the multiplicity factor, leads to heightened complexity for any system development and operation. The enigmatic yet exemplary software engineering (SE) space is being stuffed and sandwiched with innumerable and heterogeneous technologies and tools. Their intended and insightful use seems a bit challenging, but their contributions are mesmerizing and meteoric indeed if utilized properly.
Interestingly, every kind of asset and artifact in our personal, professional, and social environments is being embedded and emboldened by pioneering software libraries. With continuous software penetration and participation in everything we touch, feel, and use, we are to have a bevy of sophisticated and smarter applications in plenty. Precisely speaking, we are heading toward the promised software-defined world. However, the developmental and operational complexities of next-generation software applications are literally threatening. That is, leveraging the various delectable advancements in the software engineering domain actually turns out to be a difficult affair. Therefore, there is a clarion call for unearthing easy to understand and use approaches to moderate software engineering complexity.
Accentuating, assimilating, and articulating architecturally sound principles for high-quality software implementation and delivery has been pronounced by technology experts, exponents, and evangelists as a workable way out of this dilemma. Elegantly employing architectural patterns, along with design, deployment, integration, and other specialized patterns, is the way forward for producing and running next-generation software solutions. An arsenal of software patterns (architecture, design, deployment, integration, and so on.) come in handy for the risk-free and rewarding production of highly reliable, scalable, available, performant, adaptive, and secure software systems. This book has been produced with the sole and simple aim of enumerating and expressing prominent and dominant software patterns for its readers. The various chapters and their unique contributions are briefly explained here.
What this book covers
Chapter 1, Demystifying Software Architecture Patterns, illustrates the context for the book and describes the need for software patterns. The various architectural patterns are listed and explained in detail in order to convey the what, why, where, and how of architectural patterns.
Chapter 2, Client/Server Multi-Tier Architectural Patterns, covers the client-server architecture pattern, which is one of the oldest patterns in the enterprise architecture space. There are several variants available in this architectural space, such as two-tier client-server architecture patterns, three-tier patterns, and n-tier patterns. With the evolution of several new types of architecture for enterprises, client-server architecture has taken a back seat in enterprise architecture. The second part of this chapter covers web application patterns. The key types of web application patterns covered in this chapter are MVC, MVP, and MVVM. Several examples of each type of pattern are also provided in this chapter.
Chapter 3, Object-Oriented Software Engineering Patterns, covers object-oriented (OO) software engineering patterns. This chapter serves to give you a refresher on the fundamentals of OO design principles and best practices. We believe that OO programming patterns are the basis of the modern software design paradigm and help you get a better understanding of other patterns. This chapter covers various prominent creational, structural, and behavioral OO patterns, along with concurrency architectural patterns such as half-sync/half-async, and leader/followers as well.
Chapter 4, Enterprise Integration Patterns, describes the various enterprise integration patterns. In the modern world, there are a plethora of commercial applications. Some of them are commercial off-the-shelf applications, while others are legacy applications that are custom built as per the requirements of the organization. Since there are so many silos of applications within an enterprise, it becomes necessary to integrate them to ensure they work seamlessly. This chapter covers the key patterns that are available for enterprise integration. The key types of enterprise integration patterns that are covered in this chapter are messaging patterns, mobile integration patterns, and API management patterns.
Chapter 5, Domain-Driven Design (DDD) Principles and Patterns, illustrates domain-driven design (DDD) principles and patterns. This chapter helps you learn about DDD principles, practices, and a few critical patterns, and how they support technology and business excellence brought together to create sophisticated software. We focus on the domain, ubiquitous language communication, bounded contexts, aggregates, and more DDD aspects. This chapter covers a few critical and prominent DDD patterns to help you learn about strategic, tactical, legacy integration, distributed contexts, and also learn about two emerging patterns, domain events and event sourcing.
Chapter 6, Enterprise Architecture Platforms and Tools, presents the unique capabilities of enterprise architecture platforms and tools. Enterprise architecture helps to map all software-related processes in an enterprise into a framework in such a way that all the objectives of the enterprise are fulfilled. This chapter discusses two prominent enterprise architecture frameworks that are widely used in the IT industry landscape: TOGAF and Zachman's framework. Some prominent architecture platforms and tools, such as Enterprise Architect, Dragon, and Abacus, are also discussed in this chapter.
Chapter 7, Service-Oriented Architecture (SOA), demystifies the popular service-oriented architecture (SOA) patterns that produce service-oriented applications. This chapter provides details on the principles, best practices, and characteristics of SOA. You will also learn about the most common SOA patterns that deal with web service security, inter-service communication, messaging, service versioning, and service refactoring. This chapter has a table that helps you understand various patterns and their associated SOA principles.
Chapter 8, Event-Driven Architectural Patterns, covers emerging and evolving event-driven architecture patterns. Modern organizations are agile in nature and want to adopt architectural styles that permit them to work in an agile manner. Event-driven architectural patterns were developed mainly to meet this need. This chapter provides exhaustive coverage of popular event-driven patterns. Recent trends in the event-driven architecture space are also discussed in this chapter.
Chapter 9, Microservices Architecture Patterns, explains the various microservices architecture (MSA). With containerization spreading its wings wider, the roles and responsibilities of microservices in producing enterprise-scale, elastic, extensible, and dynamic applications is bound to increase. The various architecture and design patterns are explained, along with use cases.
Chapter 10, Patterns for Containerized and Highly Reliable Applications, talks about the distinct contributions of various design patterns for producing containerized and highly reliable applications. The convergence of containers and microservices, along with the arrival of various container and cluster management and orchestration platforms, guarantees the realization of highly resilient microservices that in turn lead to reliable applications.
Chapter 11, Software-Defined Clouds - Architecture and Design Patterns, provides information about cloud application architecture and its various design patterns. As we all know, all kinds of legacy and monolithic applications are being modernized and migrated to cloud environments. This chapter prescribes the ways and means of smartly leveraging the patterns for swift and sagacious cloud adoption.
Chapter 12, Big Data Architecture and Design Patterns, provides you with a head start with big data architecture patterns and big data design patterns. The patterns are grouped by layers, such as the data ingestion layer, data storage layer, and data access layer, to help you learn about unified architecture involving data sources, data messaging, data analysis, and consumption. A few of the prominent patterns covered in this chapter are data lakes, lambda architecture, short summaries for workload patterns, polyglots, and connectors. This chapter also covers a few of the fundamentals of big data.
What you need for this book
There are no specific requirements before you start with this book. You will find all the required information as you go through the chapters.
Who this book is for
This book will empower and enrich IT architects (such as enterprise architects, software product architects, and solution and system architects), technical consultants, evangelists, and experts.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "We can include other contexts through the use of the include directive."
A block of code is set as follows:
package mainimport "fmt"// this is a commentfunc main() { fmt.Println("Hello World")}
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
package mainimport "
fmt
"// this is a commentfunc main() { fmt.Println("Hello World")}
Any command-line input or output is written as follows:
docker run --rm -ti -v $(pwd):/go/src/myapp google/golang go build myapp
New terms and important words are shown in bold.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book-what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of. To send us general feedback, simply e-mail [email protected], and mention the book's title in the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Downloading the color images of this book
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/ArchitecturalPatterns_ColorImages.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books-maybe a mistake in the text or the code-we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title. To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy. Please contact us at [email protected] with a link to the suspected pirated material. We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at [email protected], and we will do our best to address the problem.
Demystifying Software Architecture Patterns
It is going to be the software-defined, digitization-enabled, cloud-hosted, context-aware, service-oriented, event-driven, and people-centric era. It is a well-known and widely accepted truth that reactive and cognitive software plays a very vital role in shaping up the projected and pronounced era of knowledge-filled and insight-driven services and applications. That is, we need highly responsive, reliable, scalable, adaptive, and secure software suites and libraries to fulfill the identified goals for the forthcoming era of knowledge. There are competent information and communication technologies(ICTs), tools, techniques, and tips emerging and evolving fast to artistically enable the realization of such kinds of advanced and astute software modules.
The quickly-enlarging domain of patterns has been there for several decades. The complexity of software engineering is also increasing in an uninhibited fashion. Software experts, evangelists, and exponents have articulated and accentuated the deft and decisive leverage of software patterns in order to mitigate the rising complexity of software engineering. Therefore, software patterns are widely being recognized as one prime and paramount method for building resilient and versatile software packages and programs. Professionals and professors have been steady in unearthing newer patterns. As a result, a bevy of path-breaking and promising architectural, design, deployment, delivery, and integration patterns are quickly emerging and evolving to speed up and streamline the increasingly complicated processes of designing, developing, debugging, deploying, and delivering robust and rewarding software applications.
This chapter aims to explain the prominent software patterns, particularly the following widely deliberated and detailed architecture patterns:
Object-oriented architecture
(
OOA
)
Component-based assembly
(
CBD
) architecture
Domain-driven design architecture
Client/server architecture
Multi-tier distributed computing architecture
Layered/tiered architecture
Event-driven architecture
(
EDA
)
Service-oriented architecture
(
SOA
)
Microservices architecture
(
MSA
)
Space-based architecture
(
SBA
)
Special-purpose architectures
Envisioning the software-defined world
There are newer requirements such as smarter homes, hotels, hospitals, and so on, and the crucial role and responsibility of information and communication technologies (ICT) fulfilling the varying business and people needs are growing steadily. There are a variety of noteworthy trends and transitions happening in the enigmatic ICT space these days. The prominent ones include the following:
IT industrialization through cloud computing
IT compartmentalization through virtualization and containerization
IT consumerization through handhelds, wearables, mobiles, nomadic devices, and so on
The extreme and deeper connectivity amongst all kinds of physical, electrical, mechanical, and electronic systems through the leverage of the
Internet of Things
(
IoT
) technologies,
cyber-physical systems
(
CPSs
), and so on
Cognitive IT to empower our everyday systems to be cognitive of their actions and reactions
With everything getting connected with one another, the amount of data getting generated, collected, cleansed, and crunched goes up exponentially. There are integrated platforms for big, fast, streaming, and IoT data analytics to extricate useful information and actionable insights out of data heaps. The database paradigm is going through a slew of changes and challenges.
The middleware domain is upping the ante as there are heterogeneous and multiple systems and services to be integrated and made to work together. I can go on and on. In short, both the IT and business landscapes are changing day by day. Also, businesses expect their IT service providers to be innovative, disruptive, and transformative in order to achieve more with less. As the IT budgets are being pruned by businesses across the world, the IT domain has to pick the latest advancements in order to be right and relevant to their stakeholders.
As usual, the field of software engineering is also progressing steadily with a dazzling array of noteworthy progressions. There are agile programming models for enabling the business agility. In the recent past, there have been DevOps methods germinating for guaranteeing IT agility. There are newer software infrastructure and platform solutions coming up fast in order to meet various requirements from different stakeholders. Professionals and professors are working overtime to ensure process excellence and infrastructure optimization. Strategically sound architectural paradigms and styles are being assimilated. Further on, the automation level will pick up and reach greater heights with the adoption of artificial intelligence (AI) methods.
As we all know, the most powerful domain of software engineering has been accomplishing grandiose things for the business acceleration, augmentation, and automation. With the arrival and articulation of the IoT and CPS paradigms, the software field is steadily and sagaciously veering towards the much-expected people empowerment. Accordingly, there is a greater demand for software applications and services to intelligently empower not only business operations and offerings, but also to contribute to everyday decisions, deals, and deeds of individuals, innovators, and institutions. The currently available programming models, frameworks, and tools are helping us out in producing applications that fulfill functional requirements. Hereafter, the crucial challenge ahead for software professionals and practitioners is to bring forth software libraries and suites that comply with all kinds of non-functional requirements (NFRs) / Quality of Service (QoS) attributes. That is, we ought to construct applications that innately ensure various abilities, such as reliability, scalability, availability, modifiability, sustainability, security, and so on. Software patterns come in handy here. Precisely speaking, the penetration, participation, and pervasiveness of software patterns are consistently on the increase.
Software patterns
As we all know, patterns are a kind of simplified and smarter solution for a repetitive concern and recurring challenge in any field of importance. In the field of software engineering, there are primarily many designs, integration, and architecture patterns. These patterns come in handy in speedily surmounting some of the routine and fresh issues being encountered by software architects, developers, and integrators in their everyday assignments and engagements. Design patterns are very popular and are used for expertly designing enterprise-class software systems whereas architectural patterns are used for skilfully deciding the optimized and organized architecture for a system under development. The changes and complexities are substantially taken care of through the deft leverage of various architectural patterns. The architectural patterns enable taking a series of decisions regarding the choice of technologies and tools. The various system components, their distinct capabilities, and how they connect and collaborate with one another are the key ingredients in architecting and designing next-generation software systems. The architectural patterns render their yeoman services here. With system architectures increasingly becoming complicated, the role and responsibility of architectural patterns are consistently on the increase. Similarly, as we tend towards the distributed and decentralized era, the integration patterns are very significant as they bring a lot of praiseworthy simplifications and delegations.
With the flourishing of the DevOps concept, there are additional patterns emerging in IT agility. Patterns also assiduously accelerate the process of building newer and powerful software packages. Besides the development-centric patterns, there are deployment and delivery-specific patterns also. In the ensuing DevOps and NoOps days, the deployment patterns are going to be highly beneficial in automating the time-consuming and tedious tasks. Similarly, there are delivery-enablement patterns. Patterns are fast-evolving and stabilizing tellingly with more usage and continuous refinements. Patterns are capable of overcoming the initial hiccups for newer technologies, too. Patterns will be a key ingredient for IT to survive and shine in the market-driven, knowledge-driven and cut-throat competitive environment. Precisely speaking, patterns are a crucial enabler in building sophisticated software by minimizing the workload of software developers. The risks being associated with constructing enterprise-scale, high-quality, and microservices-based applications are being substantially moderated by meticulously using the proven software patterns.
Why software patterns?
There is a bevy of noteworthy transformations happening in the IT space, especially in software engineering. The complexity of recent software solutions is continuously going up due to the continued evolution of the business expectations. With complex software, not only does the software development activity become very difficult, but also the software maintenance and enhancement tasks become tedious and time-consuming. Software patterns come as a soothing factor for software architects, developers, and operators.
Software systems are becoming extremely complicated and sophisticated in order to meet up the newer demands of the business. The field of software architecture helps to smoothen and straighten the path towards producing well-defined and designed software suites. Software architecture is primarily tuned for moderating the rising software complexities and changes. Hence, there are purported efforts to bring forth software architecture patterns to arrive at easy-to-implement and sustainable software architectures. This section begins with some basics about architecture and goes on to elaborate on some of the widely used software architectural patterns.
Architecture is essential for systems that are increasingly becoming complex due to the continuous addition of fresh modules. Architectures generally are decided by three crucial aspects: the participating components, the distinct capabilities of each of those components, and, finally, the connectivity between those components. Establishing software architectures is not an easy job. A variety of factors need to be taken into consideration while deciding the architecture. A number of architectural decisions need to be meticulously considered in order to strengthen the final architecture. Not only functional requirements but also non-functional requirements too need to be inscribed in the architecture. Typically, the architecture pattern is for designing a generic architecture for a system, such as a software solution.
The prime ingredients of a software pattern
Several different formats are used in the literature for describing patterns, and no single format has achieved widespread acceptance. The following elements described will be found in most patterns, even if different headings are used to describe them. In the Opengroup.org site, the following terminologies are used:
Name
: A meaningful and memorable way to refer to the pattern, typically a single word or short phrase.
Problem
: This is a concise description of the problem at hand. It has to throw some light on the intended goals and objectives to be reached within the context.
Context
: The context typically illustrates the preconditions under which the pattern can be applied. That is, it is a description of the initial state before the pattern is applied.
Forces
: This is for describing the relevant forces and constraints and how they interact/conflict with each other. It inscribes the intended goals and objectives. The description should clarify the intricacies of the problem and make explicit the kinds of trade-offs that must be considered. The notion of
forces
more or less equates to the
QoS attributes
(availability, scalability, security, sustainability, composability, maneuverability, resiliency, reliability, reusability, and so on) that architects seek to obtain and optimize besides the concerns they seek to address in designing architectures.
Solution
: This is all about clearly explaining how to achieve the intended goals and objectives. The description should identify both the solution's static structure and its dynamic behavior.
Resulting context
: This indicates the post-conditions after the pattern is applied. Implementing the solution normally requires trade-offs among competing forces. This element describes which forces have been resolved and how, and which remain unresolved. It may also indicate other patterns that may be applicable in the new context.
Examples
: This is about incorporating a few sample applications of the pattern for illustrating each of the elements (a specific problem, the context, the set of forces, how the pattern gets applied, and the resulting context).
Rationale
: It is necessary to give a convincing explanation/justification of the pattern as a whole or of the individual components within it. The rationale has to indicate how the pattern actually works and how it resolves the forces to achieve the desired goals and objectives.
Related patterns
: There are other similar patterns and hence the relationships between this pattern and others have to be clearly articulated. These may be predecessor patterns, whose resulting contexts correspond to the initial context of this one. Or, these may be successor patterns, whose initial contexts correspond to the resulting context of this one. There may also be alternative patterns, which describe a different solution to the same problem, but under different forces. Finally these may be co-dependent patterns, which may/must be applied along with this pattern.
Known uses
: This has to detail the known applications of the pattern within existing systems. This is for verifying that the pattern does indeed describe a proven solution to a recurring problem. The known uses can also serve as value-added examples.
Patterns may also begin with an abstract providing an overview of the pattern and indicating the types of problems it addresses. The abstract may also identify the target audience and what assumptions are made of the reader.
The types of software patterns
Several newer types of patterns are emerging in order to cater to different demands. This section throws some light on these.
An architecture pattern expresses a fundamental structural organization or schema for complex systems. It provides a set of predefined subsystems, specifies their unique responsibilities, and includes the decision-enabling rules and guidelines for organizing the relationships between them. The architecture pattern for a software system illustrates the macro-level structure for the whole software solution. An architectural pattern is a set of principles and a coarse-grained pattern that provides an abstract framework for a family of systems. An architectural pattern improves partitioning and promotes design reuse by providing solutions to frequently recurring problems. Precisely speaking, an architectural pattern comprises a set of principles that shape an application.
A design pattern provides a scheme for refining the subsystems or components of a system, or the relationships between them. It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context. The design pattern for a software system prescribes the ways and means of building the software components. The design pattern articulates how the various components within the system collaborate with one another in order to fulfil the desired functionality.
There are other patterns, too. The dawn of the big data era mandates for distributed computing. The monolithic and massive nature of enterprise-scale applications demands microservices-centric applications. Here, application services need to be found and integrated in order to give an integrated result and view. Thus, there are integration-enabled patterns. Similarly, there are patterns for simplifying software deployment and delivery. Other complex actions are being addressed through the smart leverage of simple as well as composite patterns. In the next section, we will discuss the various dimensions of IT with the intention of conveying the tremendous impacts of software patterns for next-generation IT.
Software architecture patterns
This section is allocated for describing the prominent and dominant software architecture patterns.
There are several weaknesses associated with monolithic applications:
Scalability
: Monolithic applications are designed to run on a single and powerful system within a process. Increasing the application's speed or capacity requires fork lifting onto newer and faster hardware, which takes significant planning and consideration.
Reliability and availability
: Any kind of faults or bugs within a monolithic application can take the entire application offline. Additionally, updating the application typically requires downtime in order to restart services.
Agility
: Monolithic code bases become increasingly complex as features are being continuously added, and release cycles are usually measured in periods of 6-12 months or more.
As already mentioned, legacy applications are monolithic in nature and massive in size. Refactoring and remedying them to be web, cloud, and service-enabled is bound to consume a lot of time, money, and talent. As enterprises are consistently pruning the IT budget and still expecting more with less from IT teams, the time for leveraging various architectural patterns individually or collectively to prepare and put modernized applications has arrived. The following sections detail the various promising and potential architecture patterns.
Object-oriented architecture (OOA)
Objects are the fundamental and foundational building blocks for all kinds of software applications. The structure and behavior of any software application can be represented through the use of multiple and interoperable objects. Objects elegantly encapsulate the various properties and the tasks in an optimized and organized manner. Objects connect, communicate, and collaborate through well-defined interfaces. Therefore, the object-oriented architectural style has become the dominant one for producing object-oriented software applications. Ultimately, a software system is viewed as a dynamic collection of cooperating objects, instead of a set of routines or procedural instructions.
We know that there are proven object-oriented programming methods and enabling languages, such as C++, Java, and so on. The properties of inheritance, polymorphism, encapsulation, and composition being provided by OOA come in handy in producing highly modular (highly cohesive and loosely coupled), usable and reusable software applications.
The object-oriented style is suitable if we want to encapsulate logic and data together in reusable components. Also, the complex business logic that requires abstraction and dynamic behavior can effectively use this OOA.
Component-based assembly (CBD) architecture
Monolithic and massive applications can be partitioned into multiple interactive and smaller components. When components are found, bound, and composed, we get the full-fledged software applications. Components emerge as the building-block for designing and developing enterprise-scale applications. Thus, the aspects of decomposition of complicated applications and the composition of components to arrive at competent applications receive a lot of traction. Components expose well-defined interfaces for other components to find and communicate. This setup provides a higher level of abstraction than the object-oriented design principles. CBA does not focus on issues such as communication protocols and shared states. Components are reusable, replaceable, substitutable, extensible, independent, and so on. Design patterns such as the dependency injection (DI) pattern or the service locator pattern can be used to manage dependencies between components and promote loose coupling and reuse. Such patterns are often used to build composite applications that combine and reuse components across multiple applications.
Aspect-oriented programming (AOP) aspects are another popular application building block. By deft maneuvering of this unit of development, different applications can be built and deployed. The AOP style aims to increase modularity by allowing the separation of cross-cutting concerns. AOP includes programming methods and tools that support the modularization of concerns at the level of the source code. Aspect-oriented programming entails breaking down program logic into distinct parts (concerns, the cohesive areas of functionality). All programming paradigms intrinsically support some level of grouping and encapsulation of concerns into independent entities by providing abstractions (for example, functions, procedures, modules, classes, methods, and so on). These abstractions can be used for implementing, abstracting, and composing various concerns. Some concerns anyway cut across multiple abstractions in a program and defy these forms of implementation. These concerns are called cross-cutting concerns or horizontal concerns.
Logging exemplifies a cross-cutting concern because a logging strategy necessarily affects every logged part of the system. Logging thereby cross-cuts all logged classes and methods. In short, aspects are being represented as cross-cutting concerns and they are injected on a need basis. Through the separation of concerns, the source code complexity comes down sharply and the coding efficiency is bound to escalate.
Agent-oriented software engineering (AOSE) is a programming paradigm where the construction of the software is centered on the concept of software agents. In contrast to the proven object-oriented programming, which has objects (providing methods with variable parameters) at its core, agent-oriented programming has externally specified agents with interfaces and messaging capabilities at its core. They can be thought of as abstractions of objects. Exchanged messages are interpreted by receiving agents, in a way specific to its class of agents.
A software agent is a persistent, goal-oriented computer program that reacts to its environment and runs without continuous direct supervision to perform some function for an end user or another program. A software agent is the computer analog of an autonomous robot. There are a set of specific applications and industry verticals that require the unique services of software agents. Thus, we have software objects, components, aspects, and agents as the popular software construct for building a bevy of differently abled applications.
Domain-driven design (DDD) architecture
Domain-driven design is an object-oriented approach to designing software based on the business domain, its elements and behaviors, and the relationships between them. It aims to enable software systems that are a correct realization of the underlying business domain by defining a domain model expressed in the language of business domain experts. The domain model can be viewed as a framework from which solutions can then be readied and rationalized.
Architects have to have a good understanding of the business domain to model. The development team has too often worked with business domain experts to model the domain in a precise and perfect manner. In this, the team agrees to only use a single language that is focused on the business domain, by excluding any technical jargon. As the core of the software is the domain model, which is a direct projection of this shared language, it allows the team to quickly find gaps in the software by analyzing the language around it. The DDD process holds the goal not only of implementing the language being used, but also improving and refining the language of the domain. This, in turn, benefits the software being built.
DDD is good if we have a complex domain and we wish to improve communication and understanding within the development team. DDD can also be an ideal approach if we have large and complex enterprise data scenarios that are difficult to manage using the existing techniques.
Client/server architecture
This pattern segregates the system into two main applications, where the client makes requests to the server. In many cases, the server is a database with application logic represented as stored procedures. This pattern helps to design distributed systems that involve a client system and a server system and a connecting network. The simplest form of client/server architecture involves a server application that is accessed directly by multiple clients. This is referred to as a two-tier architecture application. Web and application servers play the server role in order to receive client requests, process them, and send the responses back to the clients. The following figure is the pictorial representation of the client/server pattern:
The peer-to-peer (P2P) applications pattern allows the client and server to swap their roles in order to distribute and synchronize files and information across multiple clients. Every participating system can play the client as well as the server role. They are just peers working towards the fulfillment of business functionality. It extends the client/server style through multiple responses to requests, shared data, resource discovery, and resilience to the removal of peers.
The main benefits of the client/server architecture pattern are:
Higher security
: All data gets stored on the server, which generally offers a greater control of security than client machines.
Centralized data access
: Because data is stored only on the server, access and updates to the data are far easier to administer than in other architectural styles.
Ease of maintenance
: The server system can be a single machine or a cluster of multiple machines. The server application and the database can be made to run on a single machine or replicated across multiple machines to ensure easy scalability and high availability. The multiple machines eventually form a cluster through appropriate networking. Lately, the enterprise-grade server application is made up of multiple subsystems and each subsystem/microservice can be run on the separate server machine in the cluster. Another trend is each subsystem and its instances are also being hosted and run on multiple machines. This sort of single or multiple server machines being leveraged for executing server applications and databases ensures that a client remains unaware and unaffected by a server repair, upgrade, or relocation.
However, the traditional two-tier client/server architecture pattern has numerous disadvantages. Firstly, the tendency of keeping both application and data in a server can negatively impact system extensibility and scalability. The server can be a single point of failure. The reliability is the main worry here. To address these issues, the client-server architecture has evolved into the more general three-tier (or N-tier) architecture. This multi-tier architecture not only surmounts the issues just mentioned, but also brings forth a set of new benefits.
Multi-tier distributed computing architecture
The two-tier architecture is neither flexible nor extensible. Hence, multi-tier distributed computing architecture has attracted a lot of attention. The application components can be deployed in multiple machines (these can be co-located and geographically distributed). Application components can be integrated through messages or remote procedure calls (RPCs), remote method invocations (RMIs), common object request broker architecture (CORBA), enterprise Java beans (EJBs), and so on. The distributed deployment of application services ensures high availability, scalability, manageability, and so on. Web, cloud, mobile, and other customer-facing applications are deployed using this architecture.
Thus, based on the business requirements and the application complexity, IT teams can choose the simple two-tier client/server architecture or the advanced N-tier distributed architecture to deploy their applications. These patterns are for simplifying the deployment and delivery of software applications to their subscribers and users.
Layered/tiered architecture
This pattern is an improvement over the client/server architecture pattern. This is the most commonly used architectural pattern. Typically, an enterprise software application comprises three or more layers: presentation / user interface layer, business logic layer, and data persistence layer. Additional layers for enabling integration with third-party applications/services can be readily inscribed in this layered architecture. There are primarily database management systems at the backend, the middle tier involves an application and web server, and the presentation layer is primarily user interface applications (thick clients) or web browsers (thin clients). With the fast proliferation of mobile devices, mobile browsers are also being attached to the presentation layer. Such tiered segregation comes in handy in managing and maintaining each layer accordingly. The power of plug-in and play gets realized with this approach. Additional layers can be fit in as needed. There are model view controller (MVC) pattern-compliant frameworks hugely simplifying enterprise-grade and web-scale applications. MVC is a web application architecture pattern. The main advantage of the layered architecture is the separation of concerns. That is, each layer can focus solely on its role and responsibility. The layered and tiered pattern makes the application:
Maintainable
Testable
Easy to assign specific and separate
roles
Easy to update and enhance layers separately
This architecture pattern is good for developing web-scale, production-grade, and cloud-hosted applications quickly and in a risk-free fashion. The current and legacy-tiered applications can be easily modified at each layer with newer technologies and tools. This pattern remarkably moderates and minimizes the development, operational, and management complexities of software applications. The partitioning of different components participating in the system can be replaced and substituted by other right components. When there are business and technology changes, this layered architecture comes in handy in embedding newer things in order to meet varying business requirements.
As illustrated in the following figure, there can be multiple layers fulfilling various needs. Some layers can be termed as open in order to be bypassed during some specific requests. In the figure, the services layer is marked as open. That is, requests are allowed to bypass this opened layer and go directly to the layer under it. The business layer is now allowed to go directly to the persistence layer. Thus, the layered approach is highly open and flexible.
In short, the layered or tiered approach is bound to moderate the rising complexity of software applications. Also, bypassing certain layers, the flexibility is being incorporated easily. Additional layers can be embedded as needed in order to bring highly synchronized applications.
Event-driven architecture (EDA)
Generally, server applications respond to clients requests. That is, the request and reply method is the main one for interactions between clients and servers as per the famous client-server architectural style. This is kind of pulling information from servers. The communication is also synchronous. In this case, both clients and servers have to be available online in order to initiate and accomplish the tasks. Further on, when service requests are being processed and performed by server machines, the requesting services/clients have to wait to receive the intended response from servers. That means clients cannot do any other work while waiting to receive servers' responses.
The world is eventually becoming event-driven. That is, applications have to be sensitive and responsive proactively, pre-emptively, and precisely. Whenever there is an event happening, applications have to receive the event information and plunge into the necessary activities immediately. The request and reply notion paves the way for the fire and forgets tenet. The communication becomes asynchronous. There is no need for the participating applications to be available online all the time.
An event is a noteworthy thing that happens inside or outside of any business. An event may signify a problem, an opportunity, a deviation, state change, or a threshold break-in. Every event occurrence has an event header and an event body. The event header contains elements describing the event occurrence details, such as specification ID, event type, name, creator, timestamp, and so on. The event body concisely yet unambiguously describes what happened. The event body has to have all the right and relevant information so that any interested party can use that information to take necessary action in time. If the event is not fully described, then the interested party has to go back to the source system to extract the value-adding information.
EDA is typically based on an asynchronous message-driven communication model to propagate information throughout an enterprise. It supports a more natural alignment with an organization's operational model by describing business activities as series of events. EDA does not bind functionally disparate systems and teams into the same centralized management model. EDA ultimately leads to highly decoupled systems. The common issues being introduced by system dependencies are getting eliminated through the adoption of the proven and potential EDA.
