System Architecture Overview

System Architecture

• Represents a system by mapping functionalities onto hardware and software components, ensuring seamless human interaction with those components.
• Three primary architectural structures:

  Module Structure

  • Defines the system's organization into code or data units, with each module having a specific function or responsibility.
  • Structures within Module Structure:
    • Decomposition: Breaks down modules into smaller, more manageable units.
    • Uses: Illustrates dependencies between modules, like which modules rely on others' services or functionalities.
    • Layer: Organizes the system in layers, each depending on the layer below and providing services to the layer above.
    • Class: Defines relationships (inheritance, associations, aggregations) between classes or objects in object-oriented systems.
    • Data Model: Describes the static information structure in terms of data entities and their relationships.

  Component and Connector Structure

  • Defines how the system is organized into elements that perform actions during runtime (components) and how those elements interact (connectors).
  • Structures within Component and Connector Structure:
    • Service: Units are services that inter-operate through mechanisms like SOAP. Supports systems composed of independent components, even if developed independently.
    • Concurrency: Shows how components execute concurrently, including threads, processes, and synchronization methods, highlighting parallel/concurrent execution management.

  Allocation Structure

  • Defines how software interacts with non-software elements in its environment, like CPUs, file systems, networks, and development teams.
  • Structures within Allocation Structure:
    • Deployment: Maps software to hardware processing and communication elements.

C4 Model

• Provides a detailed map of code using an abstraction-first approach, like zooming in and out on Google Maps.
• Simplifies communication and understanding of software architecture.
• Utilizes four diagram levels:
  • Context or System Context: Outlines the software system's scope and interactions with users and other systems.
  • Container: Represents a running application or data store, essential for making the system functional.
  • Components: Individual elements within each container, outlining their interactions.
  • Codes: Shows how components are implemented, with classes and interfaces supporting those components.

Microservices

• Splitting large systems into smaller modules (microservices), each focusing on a specific task or functionality.
• Derived from Unix philosophy, emphasizing minimal, modular software development.
• Benefits:
  • Legacy Application: Microservices handle specific requests while leaving others to legacy systems.
  • Time-to-Market: Introduced into production one-by-one, allowing for independent scaling of each service.
  • Free Choice of Technologies: Test new technology within a single microservice, limiting risk to other services.
  • Continuous Delivery: Small microservices can be deployed independently, allowing simultaneous deployment of different versions.
• Challenges:
  • Data Management: Complexity due to the autonomy of each microservice, especially when multiple services need shared data.
  • Refactoring: Difficult, as improving internal structures or design is challenging across microservices deployed on different environments.
  • Domain Architecture: Defining bounded contexts and separating services aligning with business domains is crucial for a seamless flow.
  • Running Microservices is Complex: Each microservice requiring independent deployment, versioning, scaling, and updates adds complexity.

SOA (Service-Oriented Architecture)

• Composed of independent, reusable services that communicate through interfaces.
• Focuses on larger, coarser-grained services, minimizing dependencies.
• Service Characteristics:
  • Provides domain functionality and can be used independently.
  • Network availability.
  • Compatibility with different programming languages and platforms.
  • Services have interfaces for platform-agnostic communication.
  • Coarser-grained, meaning they are larger in scope and function independently.
• Team Structure:
  • Different teams manage individual systems and portals.
  • A dedicated team handles integration and orchestration, ensuring smooth communication between services.
• Integration platform enables communication between services.
• Orchestration coordinates different services.
• Portals provide interfaces for users to interact with SOA services (web, mobile, etc.)

SOA vs Microservices:

• SOA: Focuses on the entire enterprise's IT landscape. Different teams work on specific areas, like backend services or user interface.
• Microservices: Each team works on both backend and frontend within a single project, enhancing communication and accelerating feature development.