1.

Architectural Design Decisions

These decisions shape the system’s architecture and directly impact its performance,
scalability, maintainability, and overall success. Key considerations include:

Factors Affecting Decisions

 Functional Requirements: What the system must do.

 Non-Functional Requirements: Performance, security, usability, etc.
 Technology Choices: Platforms, frameworks, and tools.
 Scalability and Flexibility: Will the system grow with future needs?
 Budget and Timeline: Constraints on time and resources.

Common Decisions

 Technology Stack: E.g., .NET vs Java, MySQL vs MongoDB.

 Deployment: Cloud-based, on-premises, or hybrid.
 Integration: How will third-party systems be connected?
 Architectural Style: Choosing between layered, microservices, client-server, etc.

2. Architectural Views

These provide different perspectives of the architecture to address stakeholder concerns.

IEEE 1471 (ISO/IEC 42010) defines views as specific representations of a system's
architecture.

Common Views

1. Logical View:
o Focuses on functionality.
o Represents system components and their relationships.
o Diagrams: UML class or sequence diagrams.
2. Physical View:
o Depicts hardware and system deployment.
o Diagrams: Deployment diagrams.
3. Development View:
o Focuses on software structure (modules, packages).
o Diagrams: Component diagrams.
4. Process View:
o Describes system runtime behavior (threads, processes).
o Diagrams: Activity diagrams.
5. Use Case/Scenarios View:
o Represents how the system interacts with users.
3. Architectural Patterns

Patterns are reusable solutions to common problems in software architecture.

Key Architectural Patterns

 Layered Pattern:
o Divides the system into layers like Presentation, Business Logic, and Data.
o Suitable for systems requiring clear separation of concerns.
 Microservices Pattern:
o Structures the system as a collection of small, independent services.
o Best for highly scalable systems.
 Event-Driven Pattern:
o Reacts to events and uses event queues or buses.
o Ideal for systems with asynchronous communication.
 Client-Server Pattern:
o Separates clients from servers for resource sharing.
o Common in web applications.
 Model-View-Controller (MVC):
o Separates user interface, business logic, and data management.
o Popular in web frameworks like Django and Laravel.

4. Application Architectures

These refer to the overall structure of an application, defining how different modules interact.

Common Types of Application Architectures

 Web-Based Applications:
o Uses client-server architecture.
o Typically built using frameworks (e.g., React, Angular, Django).
 Mobile Applications:
o Native apps: Built for specific platforms (iOS or Android).
o Hybrid apps: Use web technologies but function like native apps (e.g.,
Flutter).
 Desktop Applications:
o Standalone apps running on local systems (e.g., Microsoft Word).
 Enterprise Applications:
o Large-scale apps for business operations (e.g., ERP, CRM systems).
 Cloud-Native Applications:
o Designed to run on cloud infrastructure, leveraging containers, microservices,
and CI/CD.

Do you need further detail on any specific pattern or architecture, or would you like help
applying these concepts to a project?
Here’s a more in-depth explanation of each concept, including real-world examples and
technical reasoning, for a deeper understanding of Architectural Design:

1. Architectural Design Decisions

These are choices made during the system's design that influence its structure, functionality,
and performance. Architectural decisions must balance technical and business goals.

Key Considerations in Decisions

1. Generic Application Architectures:

o Predefined structures help speed up development.
o Example: For a banking system, a transaction processing architecture is
commonly reused because it supports concurrent user requests efficiently.
2. System Distribution:
o Decides whether the system will run on one device (monolithic) or be
distributed across a network (distributed systems).
o Example: An e-commerce platform may use a distributed system where a
database server, application server, and web server are on separate machines
to handle high traffic.
3. Modular Decomposition:
o Systems are divided into modules for easier development and maintenance.
o Example: In a hospital management system, modules could be:
 Patient registration
 Billing
 Inventory management
4. Control Strategies:
o Defines how components interact:
 Centralized Control: One component oversees the entire process
(e.g., a mainframe system).
 Distributed Control: Control is decentralized, and components
communicate asynchronously (e.g., microservices architecture).
5. Documentation and Evaluation:
o Use diagrams like UML class diagrams or deployment diagrams to
visualize decisions.
o Evaluate using metrics like response time, scalability, and fault tolerance.

2. Architectural Views

To manage complexity, the architecture is represented using multiple perspectives:

4+1 View Model (IEEE 1471 Standard)

1. Logical View:
o Focuses on the software's functionality and structure.
 o Example: In an online bookstore, logical view defines classes like Book,
User, and Order.
2. Process View:
o Depicts runtime behaviour, including concurrency and interactions.
o Example: In a chat application, process view shows concurrent threads
handling multiple user sessions.
3. Development View:
o Describes the software's structure for development purposes.
o Example: A mobile app might have modules for UI, backend logic, and API
handling.
4. Physical View:
o Represents the system's deployment on hardware.
o Example: A cloud-based application might have its database hosted on AWS
and application code running on a Kubernetes cluster.
5. Scenarios (+1):
o Use cases or stories that tie together all views.
o Example: A use case in a ticket booking system:
 A user selects a seat (Logical View).
 Backend processes the request (Process View).
 Codebase for seat allocation module (Development View).
 Server hosting the application (Physical View).

3. Architectural Patterns

These are standardized solutions to common architectural problems.

Key Patterns

1. Model-View-Controller (MVC):
o Description: Separates system into:
 Model: Manages data.
 View: Manages presentation.
 Controller: Handles user interaction.
o Use Case: Web frameworks like Django and Ruby on Rails.
o Benefits: Easy to update UI without changing data logic.
o Drawback: Adds complexity for simple applications.
2. Layered Architecture:
o Description: Divides functionality into layers (e.g., UI, Business Logic, Data
Access).
o Example: Email systems where:
 UI handles the inbox view.
 Logic layer filters spam.
 Data layer stores emails.
o Benefits: Supports team-based development.
o Drawback: May result in performance overhead due to layered processing.
3. Repository Pattern:
o Description: Central data repository accessed by subsystems.
 o Example: Integrated Development Environments (IDEs) store design
information in a central database.
o Benefit: Promotes consistency and data sharing.
o Drawback: A single point of failure.
4. Client-Server Architecture:
o Description: Clients request services from servers.
o Example: A library system where clients search books, and the server
handles requests.
o Benefit: Services can be replicated for scalability.
o Drawback: Server failures affect clients.
5. Pipe and Filter:
o Description: Data flows through components (filters) that transform it.
o Example: Unix shell commands (grep | sort | uniq).
o Benefit: Easy to add new stages (filters).
o Drawback: Requires standardized data format between components.

4. Application Architectures

General architectures tailored for specific domains.

Examples

1. Data Processing Applications:

o Process data in batches.
o Example: Payroll systems that calculate salaries monthly.
2. Transaction Processing Applications:
o Handle user requests and update a database.
o Example: ATM systems process withdrawal requests in real-time.
3. Event Processing Systems:
o Respond to real-time events from the environment.
o Example: Sensors in an automated factory triggering alarms when a fault is
detected.
4. Language Processing Systems:
o Interpret user input in a formal language.
o Example: Compilers convert source code into machine code.

Why Use Application Architectures?

 They provide a reusable starting point.

 Help teams focus on domain-specific issues.
 Serve as blueprints for designing new systems efficiently.

Practical Example: E-Commerce Platform Design

Let’s put these concepts into practice:

1. Architectural Decisions:
o Use a microservices architecture for scalability.
o Deploy on the cloud for global access.
o Integrate a repository for product catalog data.
2. Views:
o Logical View: Classes for Product, User, and Order.
o Process View: Concurrent threads for handling checkout processes.
o Development View: Separate codebase for UI, backend services, and database.
o Physical View: Deployed on AWS with distributed servers.
3. Patterns:
o MVC for separating data management, UI, and user interaction.
o Repository for central product catalog data.
o Client-Server for communication between users and the platform.
Architectural Design with Data and Process Modeling

1. Linking Data Models to Architecture

 Data Models define how data is structured, stored, and accessed, while architecture
defines where and how those data operations occur.
 Integration Example:
o Repository Architecture works best when shared, structured data models
(e.g., ER diagrams) are needed.
o Pipe and Filter Architecture often processes data modeled as sequential
transformations, like CSV processing or ETL pipelines.

2. Process Modeling and Architectural Design

 Process Models (e.g., Data Flow Diagrams - DFDs) describe how data moves and is
transformed within the system.
 In architectural design, these processes can map directly to components or modules.
o Example:
 A Client-Server Architecture might handle user requests (DFD
processes) by dividing responsibilities:
 Client: Captures input data.
 Server: Processes and stores the data.

3. Integration Example: Online Library System

Let’s combine the two fields for designing a Library Management System:

1. Architectural Design Decisions:

o Use Client-Server Architecture.
o Include a Repository for centralized data storage (books, user info).
o Ensure security with layered architecture:
 Public (catalog search),
 Authentication (login),
 Admin (restricted access).
2. Data Modeling:
o ER Diagram:
 Entities: Book, User, Loan.
 Relationships: User borrows Book.
o DFD:
 Context Diagram: Shows the system interacting with users and
external systems.
 Level 1 DFD: Breaks down processes like:
 Search catalog.
 Process loan requests.
3. Mapping Data Models to Architecture:
o Repository stores:
 Books (ISBN, Title, Author, Availability).
 Users (ID, Name, Loan History).
 o Processes (from DFD):
 Search Catalog maps to the client-side and uses API calls to query the
database.
 Loan Processing maps to server-side modules that update the
repository.

Detailed Example: E-Commerce Platform

Here’s another case study integrating Data and Process Modeling with Architectural
Design:

Requirements:

 Users search and purchase products.

 Admins manage inventory.
 Real-time order tracking.

Step 1: Architectural Design

 Use Microservices Architecture:

o Product service (handles catalog).
o Order service (manages orders).
o User service (tracks users).
 Repository to centralize product data.
 Client-server model for user interactions.

Step 2: Data Modeling

 ER Diagram:
o Entities: User, Order, Product.
o Relationships: User places Order, Order contains Product.
 DFD:
o Context Diagram: Captures external interactions like user queries and admin
actions.
o Level 1 DFD: Details processes:
 Add product to cart.
 Check out and update inventory.

Step 3: Integration

 Data Flow to Architecture:

o Search Product:
 Logical View: Microservice (Product service).
 Physical View: REST API queries database.
o Order Processing:
 Logical View: Order microservice validates user data and inventory.
 Process View: Runs as concurrent threads to handle multiple orders.