FI-AE 10 Software-Architektur und Design Patterns (EN)

FI-AE 10 Software Architecture and Design Patterns

Software architecture forms the foundation for maintainable, scalable, and extensible applications. This module imparts the fundamental architectural patterns and design patterns that are indispensable in professional software development. You will learn how to structure complex systems into manageable components and implement proven solutions to recurring problems.

The acquired knowledge enables you to make well-founded architectural decisions, improve the maintainability and extensibility of applications, and optimize communication in development teams. You will be able to identify and apply suitable patterns for specific requirements.

Concepts and Background

Layered Architecture

An architectural pattern that divides an application into horizontal layers with defined interfaces. Typical layers are presentation, business logic, and data access. Each layer only communicates with the layer directly above or below it.

Hexagonal Architecture

An architectural pattern where the core application (hexagon) is isolated from technical details such as databases, user interfaces, or external services. Communication occurs through ports and adapters, enabling high testability and flexibility.

MVC vs. MVVM

Model-View-Controller (MVC) separates the application into data model, user interface, and control logic. Model-View-ViewModel (MVVM) extends this concept with a ViewModel that prepares data for the View and decouples communication between Model and View.

Design Patterns

Proven approaches to solving recurring problems in software development. They represent reusable templates that facilitate communication among developers and improve code quality.

Architecture Diagram

flowchart TB
    subgraph Presentation Layer
        UI[User Interface]
    end
    
    subgraph Business Logic
        Controller[Controller]
        Service[Service Layer]
        Domain[Domain Model]
    end
    
    subgraph Data Access Layer
        Repository[Repository]
        DB[Database]
    end
    
    UI --> Controller
    Controller --> Service
    Service --> Domain
    Service --> Repository
    Repository --> DB

Practical Steps

1. Analyze the requirements and identify the core functionalities of the application. This forms the basis for architectural planning.
2. Design the layered structure and define the interfaces between the layers. Use clear responsibilities for each layer.
3. Implement the Domain Model with core entities and business rules. This should remain independent of technical details such as databases or UI frameworks.
4. Create the Service Layer that encapsulates the business logic and orchestrates communication between the Domain Model and the Data Access Layer.
5. Implement the Repository pattern to abstract data access and decouple business logic from specific database technologies.
6. Apply selected design patterns to solve recurring problems. For example, the Singleton pattern for configuration objects or the Observer pattern for event-driven communication.
7. Implement the Controller components that receive user requests, call the Service Layer, and select the appropriate View.
8. Create the user interface as a thin layer that is solely responsible for presentation and does not directly call business logic.
9. Write unit tests for each component, especially for the Domain Model and Service Layer, to ensure the correctness of the business logic.
10. Integrate the application into the target environment and conduct integration tests to verify the correct collaboration of the components.

Common Pitfalls

Further Resources

• Refactoring.Guru - Design Patterns - Comprehensive explanations and examples for common design patterns
• Martin Fowler - Patterns of Enterprise Application Architecture - Classic work on architectural patterns for enterprise applications
• Alistair Cockburn - Hexagonal Architecture - Original documentation on hexagonal architecture
• Microsoft Docs - Architectural Patterns - Practical guides and examples for .NET applications
• O'Reilly - Software Architecture Patterns - Comprehensive overview of common architectural patterns

Knowledge Check

Four questions for self-assessment. Click on each question to see the correct answer and explanation.

What is a main characteristic of layered architecture?

• A) Each layer can communicate with every other layer
• B) The application is divided into horizontal layers with defined interfaces
• C) There are only three layers: frontend, backend, and database
• D) Layers can be dynamically added at runtime

Correct Answer: B. Layered architecture divides the application into horizontal layers with defined interfaces, while the other options contain false or incomplete descriptions.

What is the main difference between MVC and MVVM?

• A) MVVM has no Controller component
• B) MVVM introduces a ViewModel to prepare data for the View and decouple Model and View
• C) MVC is only used for web applications, while MVVM is for desktop applications
• D) MVVM does not support data binding

Correct Answer: B. MVVM introduces a ViewModel that prepares data for the View and decouples communication between Model and View, which is the main difference from MVC.

What is a key benefit of hexagonal architecture?

• A) It allows for unlimited scalability
• B) It isolates the core application from technical details through ports and adapters
• C) It eliminates the need for testing
• D) It reduces the amount of code needed by 50%

Correct Answer: B. Hexagonal architecture isolates the core application from technical details through ports and adapters, which enables high testability and flexibility.

When should you use the Singleton pattern?

• A) For all objects that need to be accessible from anywhere in the application
• B) For objects that represent global configuration or resources that must be unique
• C) For all database connection objects
• D) For all UI components

Correct Answer: B. The Singleton pattern should be used for objects that represent global configuration or resources that must be unique, not for all objects that need to be accessible everywhere.