Mind map

Estilos Arquitectónicos 1

natalia mejia English

Map content

Introduction
- Unitary Architecture
  - Software run on a single computer
- Monolithic vs. Distributed Architectures
  - Monolithic Architectures
    - All components are part of a single deployment unit
    - Examples
      - Pipeline
      - Microkernel
      - Layered
  - Distributed Architectures
    - Components are spread across multiple deployment units, connected via remote access protocols
      - Fallacies
        Fallacy #1: The Network Is Reliable
        networks can fail, leading to communication issues
        Fallacy #2: Latency Is Zero
        Remote calls take significantly longer than local calls
        Fallacy #3: Bandwidth Is Infinite
        Efficient data transfer and minimizing unnecessary communication are critical.
        Fallacy #4: The Network Is Secure
        every endpoint must be secured
        increase in attack surfaces
        Fallacy #5: The Topology Never Changes
        Network topology is dynamic, not static
        affect latency, availability, and overall system behavior
        Fallacy #6: There Is Only One Administrator
        collaboration with multiple network administrators
        Fallacy #7: Transport Cost Is Zero
        There is a financial cost associated with data transport
        additional hardware, servers, and security measures
        Fallacy #8: The Network Is Homogeneous
        include diverse hardware and software from multiple vendors
      - Other challenges
        Distributed logging
        logs are spread across multiple services and locations
        Different formats
        root-cause analysis complex and time-consuming
        Distributed Transactions
        they rely on eventual consistency
        eventually synchronize to a consistent state
        Contract Maintenance and Versioning
        services are often decoupled
        owned by different teams
    - Examples
      - Service-based
      - Event-driven
      - Space-based
      - Service-oriented
      - Microservices
- Client/Server
  - Separates functionality
    - front‐ end and backend
    - Desktop + database server
      - The desktop handled the user interface and presentation logic
      - The database server managed data storage and processing.
    - Browser + Web Server
      - web browser as the client
      - web server connected to a database server
    - Three-Tier Architecture
      - frontend
      - application tier
      - database tier
Pipeline Architecture Style
- Topology
  - Pipes
    - unidirectional communication channels
    - Pass data from one component (filter) to another
    - Pipes connect filters in a sequence
  - Filters
    - independent, self-contained units that perform a specific task
    - 4 types
      - Producer
        Generates data
      - Transformer
        Modifies or transforms the data
      - Tester
        Evaluates the data and determines whether it should continue through the pipeline
      - Consumer
        Final destination that may persist the data or trigger an action
- Characteristics
  - - Modularity
      - Each filter performs a single, well-defined task
    - Reusability
      - Filters are often reusable components due to their stateless and independent nature
    - Simplicity
      - straightforward to implement and understand
    - Monolithic Deployment
      - deployed as a single unit
    - Scalability and Elasticity
      - low scalability and elasticity due to their monolithic nature
    - Testability and Deployability
      - test and deploy the entire monolith
    - Fault Tolerance and Availability
      - failures in one part can cause the entire system to fail, and recovery times can be significant
- Strengths
  - Cost-effective
  - simple to understand and implement
  - modular
  - facilitates compositional reuse
- Weaknesses
  - Limited scalability and elasticity
  - lack of fault tolerance
  - challenges with availability and reliability
- Pipes and Filters
- Use-case
  - sequential processing of data
    - ETL processes
    - data streaming
    - business process orchestration
  - sequential transformations
Layered Architecture Style
- n-tiered architecture
- Topology
  - logical horizontal layers
  - each serving a specific function
    - presentation
    - business
    - persistence
    - database
  - closed layers
    - request must pass through each layer sequentially
    - support isolation
  - open layers
    - certain layers can be bypassed
- Anti-pattern
  - architecture sinkhole
    - requests move from layer to layer with no business logic performed within each layer
- Why use it
  - supports clear separation of concerns
  - straightforward structure
    - easy to understand and develop
    - Lower cost
  - Rating
- Disadvantages
  - Applications grow
    - Rigid and difficult to maintain
      - affecting agility, testability, and deployability
  - architecture sinkhole anti-patter
  - monolithic nature
    - Scalability, performance, and fault tolerance are limited
    - Less suitable for large, complex systems
- Use Cases
  - small applications
  - websites
  - projects with tight budgets
  - projects with time constraints
  - good starting point for initial development
Service-Based Architecture Style
- Characteristics Ratings
  - - When to use
      - Balancing Power and Simplicity
        Avoiding Over-Engineering
        Pragmatic Choice
      - Domain-Driven Design (DDD)
        Natural Fit for DDD
        Compartmentalization
      - Maintaining Database Consistency
        ACID Transactions
        Reduced Need for Sagas and BASE
      - Achieving Modularity Without Complexity
        Architectural Modularity
        Simplified Coordination
- Service Design and Granularity
  - Coarse-Grained Services
    - encapsulatte large portions of functionality
    - better data integrity and consistency
  - API Facade
    - orchestrates business requests from the user interface
  - Internal vs. External Orchestration
    - business logic is internal within the service
- Topologies
  - Topologies
    - Macro Layered Structure
      - Basic topology
      - Separately deployed
        user interface
        remote coarse-grained services
        monolithic database
    - Service Deployment
      - coarse-grained
      - Deployed similarly to monolithic apps
      - share a single monolithic database
    - Single Instance Deployment
      - single instance of each service
      - multiple instances can be deploye
        based on scalability
        fault tolerance
        throughput needs
    - Service Access
      - Services are accessed remotely
    - Variants
      - User Interface Variants
        The monolithic user interface can be broken down into smaller UI domains
      - Database Variants
        The monolithic database can be divided into separate databases corresponding to each domain service
      - API Layer
        layer between the user interface and services
        manage external access and consolidate cross-cutting concerns
- Database Partitioning
  - Monolithic Database
  - Shared Library for Database Entities
  - Logical Database Partitioning
    - database can be logically partitioned into separate domains
Natalia Mejia Estrada
Microkernel Architecture Style
- structures software into a core system and independent plug-in components
- Topology
  - Core System
    - minimal functionality required to run
    - handles the general processing flow
    - can be implemented as a layered architecture or a modular monolith
  - Plug-In Components
    - standalone modules
      - self-contained and independent of other plug-ins
    - extend or enhance the core system's functionality
    - Implemented as
      - Point-to-Point
        Direct method invocations or function calls
      - Runtime-Based
        Plug-ins dynamically added or removed without redeploying the core system
      - Remote Access
        Plug-ins can be accessed through REST or messagin
      - Each one can have its own data storage
  - Registry
    - manage available plug-ins and their access methods
  - Contracts
    - interaction between the core system and plug-ins
      - define the behavior, input data, and output data
- Benefits
  - extensibility, maintainability, and testability
  - isolating custom logic
- plug-in architecture
- Use case
  - product-based applications
  - deployment as a single monolithic unit
  - custom business applications
- Characteristics Ratings
  - - Simplicity and Cost
      - straightforward design of the core system and plug-ins
    - Scalability and Fault Tolerance
      - architecture is typically monolithic
    - Modularity and Extensibility
      - functionality can be added or removed through plug-ins
    - Testability and Reliability
      - isolated nature of plug-ins
    - Performance
      - ability to streamline the application by removing unnecessary plug-ins
- Trade-Offs
  - less scalable and fault-tolerant
  - all requests must pass through the core system