Design & Realisation

1. Later

2. Requirements & Design (= early phases)

3. Abscence

4. Changed

5. Hidden (people cannot make assumptions)

Bad code decreases productivity!

Why readability is important?

• code is much more often read than written

• you write code for the next human to read (not for the computer)

• Lehman’s law: code will be changed -> effort required for a change increases the later it occurs! (see curve)

“Code that has been taken care of”

• simple and direct

• reads like well-written prose

• straightforward logic

• minimal dependencies

WTFs/minute (caused by inconsistencies,…)

A design strategy to build a system “made up of interacting objects that maintain their own local state and provide operations on that state information.”

+ maintainability

+ understandability

Five principles of good OO design:

• Single Responsibility Principle (SRP)

• Open Closed Principle (OCP)

• Liskov Substitution Principle (LSP)

• Interface Segregation Principle (ISP)

• Dependency Inversion Principle (DIP)

1st of the 5 SOLID principles for good OO design:

Idea: A class should only have one single responsability! (“Evolution Pressure”)

(“If you have two different concerns/tasks in one class, it is better to split that up”)

There should only be one rease for a class to change

Problem Symptom: Big Class

Fix: Refactoring - Extract Classes (divide class)

Benefits:

• Code easier to understand

• modifying should affect few classes

• risk of breaking code is minimised

  
  

“Evolution Pressure”

= By following SRP, you spread the pressure across multiple smaller classes, each evolving independently and more safely.

Example: Old Fashioned Mode split up into communication and connection

“Not only classes can be split up, but also methods: famous example Command-Query-Separation.“

“Either a method changes state (command)or it returns data (query) — never both.

Not only classes can be split up (SRP), but also methods: (=Erweiterung von SRP)

Either a method changes state (command) or it returns data (query) — never both.

In real world (in Java) it is violated with the iterator pattern.

Now it has 3 steps, which reduces performance :( -> bad if called often

2nd of the 5 SOLID principles for good OO design:

Idea: Classes (Software entities) should be open for extension, but closed for modification

= Modify behaviour by adding new code, not by changing old code

3rd of the 5 SOLID principles for good OO design:

Idea: Subclasses should be usable anywhere their base class is used, without breaking the program.

(I dont want to look at the details to understand it)

“Square-class violates this principle. We overwrite width and heigth. -> If we calculate with square now (see code) it breaks the code.”

“Rectangle has now different methods than rectangle, both inherit from rectangle”

4th of the 5 SOLID principles for good OO design:

Clients should not be forced to depend upon interfaces (methods) that they do not use.

Fix: Split interface

e.g. Worker mit work(), eat() - 1. Human 2. Robot => Robot braucht kein eat()

Comparable Interface in Java: imagine this method also has encryption -> every time you want to use comparable interface you also have to implement encryption

5th of the 5 SOLID principles for good OO design:

1. High-level modules should not depend on low-level modules

1. Abstract things (copy) should only depend on abstract methods. Details should only depend on abstractions aswell. (abstract must not depend on details! (something concrete))

Fix: Introduce abstract interfaces (maybe Inversion)

e.g. cantine sells food to you (abstract) display screens are the details

Two Software Packages, A references B

If you apply principle: A references in same package, B is implementing the new package

We inject a Method into A (dependency injection)

to realize dependency inversion (reverse dependency from A to B, to B to A)

Clean Code Principle:

Dont have too many dependencies (“dont talk to strangers”)

Symptom: myCar.engine.start() -> myCar.prepareForDriving()

Rule:

method m of class C should only call the methods of

- C

- an object created by m

- an object passed as an argument to m

- an object held in an instance variable of C

Example:

Clean Code Principle:

“Leave the campground cleaner than you found it”

-> cleaning up is part of the concept of “done”, refactor the code before checking in

Clean Code Principle:

“Implement behaviour that another programmer could reasonably expect it”

-> programmer intutition can be applied (konkludentes Verhalten)

Clean Code Principles:

Use names that are

• standardised

• meaningful (clear for everyone)

• intention-revealing

How? Make meaningful distinction and avoid disinformation by giving

• hints on context (accountName instead of name)

• hints on types (accountList instead of accounts)

• prefixes

“Don’t be shy with long variable names”

Use Formatting: vertical and horizontal whitespaces

“Dont comment bad code, rewrite it”

Good comments are

• explaining (intent)

• warning (of consequences)

• informative (open issues)

Whenever possible: use well-named code instead of comments

(if they get outdated, they are even worse than no comment)

Don’t

• use redundant comments

• comment out (nobody deletes it)

Clean Code Principle:

Do not duplicate pieces of code

-> understandability (code is elss compact, passage has to be understood multiple times)

-> maintainability (lose track of copies, undocumented dependencies are horror, modify all componentes)

Clean Code Principle:

Code should be as simple as possible

-> easy to understand

-> addresses the problem adequately

-> don’t add unnecessary functionality

Clean Code Principle:

Only implement required features (= don’t add unnecessary functionality)

-> more features more cost

-> do not create platform (abstract) unless explicitly asked and payed for

-> don’t optimize every last detail (too costly, only treat the symptoms)

KISS says: if you have a solution, keep it simple,

Yagni says: do you need that? dont blow up your code base

Clean Code Principle:

Establish a well ordered hierarchy (abstraction levels) -> abstraction should decrease depth-first

Start with something that has no dependencies (least coupled) and move up from there

History

Shared working

Tagging

Reverting

Idea: write tests first = implementation driven by requirements (Test-Driven Development)

-> when you write test cases first, you also validate if you understand the requirements

Clean tests follow the FIRST rules:

• Fast - to run them frequently

• Independent - a failing test does not influence others

• Repeatable - in any environment, so there is no excuse for failing tests

• Self-Validating - tests either pass or fail automatically

• Timely - tests are written right before production code

Run code against classes of metrics which detect possible errors

Review and explain your code to others

-> detect errors

-> spread knowledge

“Disciplined technique for restructuring code, altering internal structure without changing external behavior”

Prerequisite: refactor with tests only! (otherwise you might introduce new bugs into the program)

How?

- extract cohesive parts into new methods

- move methods / rename / …

- Long method

-> Extract Methods

- feature envy (one class calls excessively other class’s methods)

-> extract or move method

- data class (only has attributes, no methods -> not desired in OO)

-> enforce information hiding principle

- duplicated code

- god class (tries to do too much)

Bad smells as indication

Generally:

- when you frequently look up details

- when you want to write a comment

negative performance

difficult code to refactor

- already published interfaces

Order of Implementation

Use Version control System

Test First

Static Code analysis

Code Reviews

Refactoring

Software architecture is the important structure(s) of the system: includes design decisions which are hard to revert (made early)

- SA links the code and the requirements

- identifies major system components and their communication

Software architecture is

• the result of a set of design decisions

• compromising the structure of the system (with components their relationships and their deployment)

-> Architectural design decisions are made in the early phases of the software development process

Architectural design is a creative process depending on the type of system being developed

• Architectural design decisions are made in the early phases of the software development process

• (analogy: “this building is built in a baroque style” -> sub decisions/characteristics follow)

= identifying major system components, their communications and mapping to hardware resources

• early stage of the system design process

• requirement engineering process and software design process are interleaved

• (analogy: “We need 3 bedrooms, 2 bathrooms, and energy-efficient materials.”)

Different people (developers, testers, managers) care about different things

-> Choose the set of views appropriate for your project

“An architecture cannot be modeled on one view type, you need several ones”.

The minimum of view types is to include a

• structural view (static properties of the system: component repository)

  example: class diagram

• behavioural view (functional and execution semantics of the system: intra and inter component behaviour)

  example: activity diagram

• deployment view (where components run and how they are deployed: allocation)

  example: component diagram

-> tool for stakeholder communication (common vision, shared language)

-> identify what requirements can be met

-> large-scale reuse (architecture may be reusable for more systems)

-> helps for project planning (cost estimation)

=> helps predicting the quality of an artefact during design!

Yes ideally record

• decisions and why chosen

• alternatives

• influential factors

Why?

• others and you can understand later

• requirements, especially constraints: “It has to be compatible with our old system/techstack”

• re-use (architectures, styles, patterns, components) “I want to have

• organisation (team size, experience, orga structure)

  -> Conways Law “A system (usually) reflects the organizational structure that built it”

Quality requirements indentify (quantify) the most important goals of the architecture (for evaluation)

SAMPSS:

• Performance

• Security

• Safety

• Availability

• Maintainability

• Scalability

-> They may often contradict with each other and thus need to be balanced!

• Separation of concerns

• Single Responsibility principle

• Information Hiding

• Principle of Least Knowledge

• Don’t repeat yourself (DRY)

• Minimize upfront design (as much as reasonable)

Architectural Pattern

solution to reocurring problem where several forces have to be balanced at the architecture level

Architectural Style

system wide solution principle that you stick to (object-oriented style, modular style), independent of application, should be used throughout the architecture

Reference Architecture

template that can be used to construct a system in a specific domain

-> defines domain concepts, components and subsystems that can be used by concrete instances

Architectural Style on how to decompose a large system into layers:

Difference:

In UP you have the stakeolders view of concpets in the domain

In layered architecture: you describe what to do in the implamantation, what are concepts of the real world domain and their interactions?

Tipp: Start with extremes: what is layer 1 and what is layer 4

layer 1: outer things, database, external providers

layer 2: oftentimes controllers, connected to layer 1 (if there is an obvious layer 1, labeles with “Subsystem” or “External”)

layer 3: more concrete use cases that deal with entities (handle stuff relate to the entity: we need user management for our web store, but this is not an entity)

layer 4: foundational application domain (my whole application does not make any sense without it)

it is allowed to skip layers, dependency rule is the only important thing

note:

names of components and remembering their level is very bad idea: only because hibernate is level 2 here, it does not mean that hibernate is level 2 in another example

Divide application into three elements:

• model (core funcitonality)

• view (displays info)

• controller (user input)

SmartUI = anti-pattern (avoid it)

-> we need model-view separation

object that carries data between processes or architectural elements

Architectural Pattern

generic reference architecture

-> acts as a standard against which systems can be built and evaluated

-> derived from a study of the application domain

Have both in mind: Use Cases = Application Business Rule

Principle: Business Logic Insie, Dependencies from outside to inside!

• Enterprise Business Rules (Entities)

• Application Business Rules (Use Cases)

• Interface

• Framework & Drivers

Why?

Inner parts are more stable (“we want to depend on things that are more stable than we are”)

Testing

=> Benefit: Inner parts dont depend on anything, you can test and change if you want! -> minimum impact of change

Entity = Core model of my software (Cantine example -> Food)

Use Case = Applying this entity to one application (Cantine example -> provide info on who provides potatos)

Controllers = Things built around my domain model, purposes, have a layer between entity and use cases and the outside (Cantine example -> layer between external service (=layer 4) where I order food)

External Interface =

Independence of Frameworks

Inner core easily Testable

Independence of UI

Independence of DB

Problem: communication

Resolve: dependency Inversion principle

Hexagonal

Onion

BCE

=> common objective: separate concerns using layers

Here: Interfaces are outer layers, model is inner layer, dependency rule: from interface to controller to model is good direction

ADG is bad

SOLID: D principle -> interface as abstraction

Here: Interfaces are outer layers, model is inner layer, dependency rule: from interface to controller to model is good direction

ADG is bad

(Distribute = Deployment, what is running on the client, what is on cloud)

Decouple layers and use cases

“Components are for composition, much beyond is unclear…”

-> building blocks for software (which can be adapted without understanding its internals)

systems are based on components

Problem: When you overwrite a method (from superclass) and another superclass method has a dependency to this method

you need to know this dependency

Components are not in the user interface

Defines what a component is, how it offers services,…

Most approaches are object oriented and rather not component based

(e.g. CORBA, EJB)

Java components?

no, we use packages, classes, …

Potential Solution to the main problem of realising components (object oriented is problematic when realising components):

OSGi offers bundles as solutions to that

Web services are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web

• self contained

• self describing

• modular

• published

• located

• invoked

=> Web services are basically deployed components

System of web services with:

• service requestor (bind to provider to invoke service)

• service provider (publishes)

• service broker (finds service from registry)

SOAP -> Messaging the Service (through passing XML encoded data)

(only SOAP really established)

WSDL -> Description of service

UDDI -> Discovery of Service

Stricter adherence to CBSE (Component-Based Software Engineering) principles and performance analysis.

1. SOFA: Protocol checking, compositionality, infrastructure.

2. ROBOCOP: Focus on consumer electronics, analyzes non-functional properties.

3. KobrA: UML-based, hierarchical modeling; supports software product lines.

4. Palladio: Predicts performance at design time, supports CBSE roles, maps to EJB.

(siehe Handy Bild)

ATM requires ->

• Card Validator, Authorization, Database (obvious chain)

• Cardreader

• Cash Dispenser

ATM provides ->

• User Interface

A domain-specific modeling language (DSL) for early performance prediction in component-based software.

Key Goals:

• Model business information systems.

• Predict performance at design time.

Components declare:

• Preconditions: What they expect (requires-interface).

• Postconditions: What they deliver (provides-interface).

Use models to predict quality attributes like:

• Performance

• Reliability

• Cost

→ Based on analytical techniques and simulations

New Palladio idea: Took into performance analysis all 4 factors:

• Usage context

• External services

• Implementation

• Runtime environment

  
  

How to handle context changes?

• Allocation context: Hardware/VM placement

• Usage context: Load, user behavior

• Assembly context: Other components used

• Hardware changes → e.g., different CPUs

• Usage changes → e.g., user load, interaction patterns

• Assembly changes → e.g., replacing connected components

Why? To enable design-time performance prediction that reflects real-world variability.

• To predict performance (e.g., delays, bottlenecks)

• To simulate changes before implementation

• To extend legacy software systems

• To analyze performance jumps and critical conditions

1. Inputs: Component behavior, usage profiles

2. Outputs: Response times, throughput, ressource utilisation

1. Component Developer: Components, interfaces, SEFFs

2. Software Architect: System architecture

3. System Deployer: Resource mapping

4. Domain Expert: User behavior

Service Effect Specification — describes a component’s externally visible behavior in an abstract way.

-> Activity diagram from Palladio

1. Abstracts a component’s internal logic

2. Describes:

   • What it provides

   • What it requires

3. Can include loops, branches, external calls

Roles, SEFF, parameterisation

1. A component made from other components

2. Enables hierarchical modeling

Assembles system from components.

System Model:

Purpose: Model the full architecture.

• Connect interfaces

• Include only relevant parts

• Prepares for performance simulation

• Defines hardware/software environment

• Maps components to resources

1. Abstract resource types (CPU, RAM, Net)

2. Allows flexibility across different hardware setups

• Knows the business domain

• Defines user scenarios and workloads

• models User behavior

  • Number of users

  • Request patterns

  • Input parameters

• Doesn’t model internal logic

• Developer → components + SEFFs

• Architect → assembly

• Deployer → resources

• Domain Expert → usage

Keeps black-box principle of components at model level for assembly, allocation, and usage

What needs to be done by who?

An architectural style for building an application as a suite of small services

-> Primarily, it is about scaling your development team (& application)

Goal: Decoupling for independent development and deployment (“Microservice: separate components into user processes to maximize decoupling and independent deployability”)

Each application:

• Runs in its own process

• Communicates via lightweight protocols (e.g., HTTP/REST)

Decoupling for independent dev/deployment (achievable in monoliths too).

1. Componentization via services – Functional units as services

2. Business capability alignment – Each service supports a business goal

3. Product-oriented – Ongoing ownership, not just project completion

4. Smart endpoints, dumb pipes – Logic in services, simple communication

5. Decentralized governance – Teams choose tools/patterns

6. Decentralized data management – Services own their own DB

7. Infrastructure automation – CI/CD & deployment automation

8. Design for failure – Handle and recover from service outages

9. Evolutionary design – Flexible and adaptable service structure

Try to split up your services by functionality: Each service implements a recognizable part of the product

-> independently deployable

=> Each service is user-facing, independently deployable, and interacts via remote mechanisms like HTTP or RPC.

Products not projects:

Focus on services enhancing business capabilities. Teams own development and operations (DevOps).

Microservice architecture splits up systems into services organized around business capabilities

-> Align services with business functions

-> Supports Conway’s Law – Structure reflects communication patterns

Services are autonomous, handling logic and responding over simple REST-like interfaces:

-> Endpoints (microservices) should do the work — they handle logic, processing, and behavior.

-> Pipes (the communication between them) should be as simple as possible — just carry data with minimal transformation or coordination.

=> Microservices are about independence, not about software reuse

Microservice teams prefer creating and sharing useful tools and standards.

Tolerant Reader: If interface provides additional data, i just ignore it.

(skipped: Consumer-Driven Contracts (CDC): Consumers define what they need; providers conform.)

Each microservice owns its own database. (Monolith: only one database)

Autonomy:

− Consistency becomes challenging, data redundancy

e.g. shipping and invoice both need address

Use CI/CD pipelines and tools to automate

Each service is a small, independent unit that:

• Has its own database

• Exposes a clear interface (e.g., HTTP API)

• Can be tested and deployed independently

If Microservice gets large: Clean Architecture

"Component" = Microservice

Reality: Services will fail — plan for it. Dont make the assumption that once it is running, it stays that way.

-> Idea: Randomly kill processes (Chaos Monkeys), how does my system react? Is it still working? It should

Practices:

• Monitor both technical (e.g., requests/sec) and business metrics (e.g., orders/min)

• Use resilience tools like Netflix’s Chaos Monkeys

• Split services gradually

• Look for low-coupling points to extract services

• Favor user functionality over tech layers when slicing

Avoid: Manual versioning and early over-engineering.

Benefits:

• Strong Module Boundaries: Supports large teams by reinforcing separation of concerns.

• Independent Deployment: Small, autonomous services are easier to deploy and debug.

• Technology Diversity: Teams can choose the best language, framework, or database per service.

Costs:

• Distribution Complexity: Remote calls are slower and prone to failure → harder to program reliably.

• Eventual Consistency: Strong consistency is hard; must design around delays and sync issues.

• Operational Complexity: Managing many services (monitoring, logging, deployments) requires mature DevOps capabilities.

-> it depends: You gain flexibility and scalability, but pay in complexity and operational overhead.

Software that supports businesses, especially business processes and business transactions & data.

Counter examples: infrastructure, nothing tied to a specific business

1. Persistent Data: Must survive app/server lifecycles

2. Large Data Volumes: Millions of records, fast access needed

3. Concurrent Access: Many users, potential for conflicts

4. Multiple UIs: For different types of users

5. System Integrations: REST, SOA, batch, etc.

6. Conceptual Dissonance: Terms mean different things to different people

7. Business "Illogic": Rules may be complex or arbitrary

1. Presentation Layer: User interface, handles input/output (lecture of Abeck)

We are talking about: “Backend”:

1. Domain Layer: Business logic (calculations, rules)

2. Data Source Layer: Communicates with databases and other systems

Pattern families: one problem, multiple patterns to solve it

• Domain Logic

• Data source architecture

• Object-relational structural patterns

-> choosing pattern depending on requirements of system at hand (advantages/disadvantages,..)

Setting: Complex business logic

Main Patterns:

1. Transaction Script – For each Use case you have your own script

2. Domain Model – OO model with behavior and data

3. Table Module – One class per DB table, procedural logic on record sets

Organizes business logic by procedures, where each procedure handles a single user request or transaction.

-> for each use case you have a script that handles a full operation

Advantages:

• ✅ Simple & fast to implement

• ✅ Easy to understand for developers

• ✅ Clear transaction boundaries

Disadvantages:

• ❌ Does not scale well with complex logic

• ❌ Tends to cause code duplication

= An object-oriented model that incorporates data and behavior

(= classic object oriented design as fix for dealing with complexity)

Designing a Domain Layer (=layer with business logic) using a domain model (artefact), low representation gap between classes and domain model

Advantages:

• ✅ Organizes complex business logic well

• ✅ Encapsulates logic with the relevant data

Disadvantages:

• ❌ Steeper learning curve, especially for non-OO teams

• ❌ More complex mapping to relational databases

A single class that handles business logic for all rows in a database table or view.

• One class handles business logic for a table

Advantages:

• ✅ Separates logic for different concepts

• ✅ Straightforward mapping to data

• ✅ Good if used technology supports it (e.g., .NET, COM)

Disadvantages:

• ❌ No object instances: Not suitable for complex, object-oriented logic

• ❌ Limited reusability and abstraction

Depends on complexity of domain logic:

simple DL: Transaction Script

data centric logic: Table Module

complex or evolving: Domain Model

(Transaction script and table module do not scale very well)

Problem: I have OO-code and i have a data source, how do i connect (Map) here? (they dont fit together well)

=> separate domain logic from database access

Common Patterns:

• Record Set (basic pattern)

• Table Data Gateway

• Active Record

• Row Data Gateway

• Data Mapper

“An in-memory representation of tabular data“

A class that acts as a gateway to a database table, with one method per SQL operation (e.g., insertCustomer(), findAllOrders()).

-> simplest solution for DB access

-> separates SQL statements (one instance per table)

An object that wraps one row in a database table or view, encapsulates database access, and adds domain logic on that data.

→ Good for simple domain logic needing fast CRUD

→ Becomes problematic with complex business rules or multiple responsibilities (no separation of concerns)

An object that acts as a gateway to a single row in a database table. There is one instance per row. (= encapsulates the SQL code to load, insert, update, or delete that row.)

Idea: Active record increases complexity -> implement gateway

→ can be built automatically (since only metadata needed)

→ but leads to (up to) three data representations:

I. (business logic (domain model))

II. Row Data Gateway

III. database

A cache (map) that ensures each database record is represented by only one object instance during a session.

→ Prevents duplicate loads, preserves object identity

→ Needs to stay synchronized with the actual database

A layer that maps data between domain objects and database tables, keeping them independent. (layer between domain objects and database)

→ Excellent for clean, decoupled architecture

When to use?

When database and domain model should evolve independently

→ Best suited for complex domain logic

They define how inheritance in object-oriented models is mapped to relational database tables.

Goal: Map OO Structure onto relational database

→ because relational databases don't support inheritance natively

Main strategies:

• Single Table Inheritance

• Class Table Inheritance

• Concrete Table Inheritance

All classes in an inheritance hierarchy are stored in one table with a type column (key) to distinguish rows.

✅ Simple schema (one table)

✅ Fast queries (no joins)

✅ Refactoring does not require chagne of DB

❌ Unused fields

❌ Large table

❌ one namespace for all fields exists

→ Use when subclasses share many fields and performance matters.

Each class in the inheritance hierarchy is stored in its own table, joined by foreign keys.

✅ Clean normalization

✅ Each table contains only relevant fields

❌ Slower reads (joins required)

❌ Refactoring implies database scheme changes

❌ More complex schema

→ Use when class differences are significant and normalization is preferred.

Answer: Each concrete subclass has its own table with all fields (including inherited ones). No base table.

✅ No irrelevant fields

✅ Simple to query one type -> no joins required

✅ Fast reads for concrete types

❌ Changes influence all subtypes

❌ Refactoring

❌ No easy polymorphic queries across types or complex joins

→ Use when you mostly query one subclass at a time.

JPA supports all major ORM inheritance mappings via annotations:

• @Inheritance(strategy = InheritanceType.SINGLE_TABLE)

• @Inheritance(strategy = InheritanceType.JOINED)

• @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)

→ Matches to:

• Single Table

• Class Table

• Concrete Table

Use annotations to configure how JPA maps inheritance to tables, often influenced by performance and schema goals.

cloud computing provides scalable, network-centric, abstracted IT infrastructure, platforms, and applications as on-demand services that are billed by consumption.

-> The illusion of infinite IT-resources

• always available

• network accessible

• on demand services

• not require ownership

pay for use business model

1. Elasitic Scalability (dynamically add or remove resources based on load)

2. On-Demand Self-Service

3. Ubiquitous Network Access

4. Resource Pooling

5. Measured Service

unpredictable load, varies

-> Cloud computing solves the resource provisioning problem

compute power

storage

network

Scalability is the ability of an application to counter high load through the utilisation of more ressources.

Elasticity is the ability of a ressource management system to provide ressources according to varying demand.

-> providing more ressources, as the load increases

-> de-allocating ressources, as the load decreases

An architecture where multiple customers share the same infrastructure, while their data and workloads are isolated.

each customer uses metadata to configure application

→ better resource utilization

A method to abstract physical hardware into logical units, enabling multiple OSes or containers to run independently.

-> logical, instead of physical view

→ Achieved via hypervisors (VMs) or container engines (e.g., Docker).

Hypervisor

= control program

Partitioning: Multiple OS on signle server

Isolation: no side effects between VMs

A virtualization technique where the guest OS is aware it’s virtualized and communicates directly with the hypervisor via hypercalls.

→ More efficient than full virtualization, but requires modified guest OS

Containers are lightweight, isolated execution environments that package code, runtime, libraries, and dependencies.

→ Run on a shared host OS, unlike VMs which include full OS images

→ Example: Docker

Consolidation

Availability

QoS

Overbooking of resources

logical view

no performance penalty

IaaS provides virtualized infrastructure (compute, storage, network) over the internet.

-> Consumer is able to deploy and run software

→ Consumer controls the OS, storage, networking…

→ Provider manages the underlying hardware and virtualization.

Examples: AWS EC2, Azure VMs, Google Compute Engine

PaaS delivers a ready-to-use environment for developing, testing, and deploying applications.

→ Users manage code and configurations; the provider manages runtime, OS, and infrastructure.

Examples: Google App Engine, Heroku, Azure App Services

SaaS delivers fully functional applications over the internet.

→ Users just use the app; everything else (infrastructure, OS, runtime, data) is managed by the provider.

→ Often accessed via browser, with minimal setup.

Examples: Google Workspace, Salesforce, Dropbox

Network based access

managed from central locations

one-to many

centralized feature updating

1. Private Cloud: Customer and provider belong to the same organization → More control and customization, often on-premises

2. Public Cloud: Customer and provider belong to different organizations → Scalable, low-cost, managed by third-party (e.g., AWS, Azure)

3. Hybrid Cloud: Combination of public and private cloud → Balances control with scalability, enables data segregation

4. Community Cloud: Shared by a group of organizations with common goals → Cost-shared, collaborative environments (e.g., research, government)

“Grep The Web” refers to an Amazon Web Services (AWS) architectural example for massively parallel data processing.

→ It mimics the UNIX grep command — searching text — but applies it at web scale using cloud infrastructure.

• Demonstrates scalability, elastic resource use, and loose coupling

• Shows how cloud services (like S3, SQS, EC2) are composed to process huge datasets efficiently

→ It’s a real-world case of building resilient, distributed architectures using cloud-native principles.

MapReduce is a programming model for processing and generating large datasets using a parallel, distributed algorithm.

Purpose: Facilitate scalable and fault tolerant data processing

1. Map Phase: Processes input data into key-value pairs Map(k1, v1) → list(k2, v2)

   Shuffle and Sort: Groups all values by key

2. Reduce phase: Processes each key and its values to produce output → Reduce(k2, list(v2)) → list(k3, v3)

• Each component scalable

• loose coupeling

• parallelization

• resilience

• on demand cost

• Decentralization: Avoid central bottlenecks and single points of failure

• Asynchrony: The system should always make progress, even under delays

• Autonomy: Components make local decisions independently

• Local Responsibility: Each component ensures its own consistency

• Controlled Concurrency: Minimize need for concurrency control

• Failure Tolerance: System continues operating despite component failure

• Controlled Parallelism: Use parallelism for performance and recovery, but at suitable granularity

• Decomposition/building blocks: Build with small, well-understood building blocks

• Symmetry: All nodes are functionally equal, require minimal config

• Simplicity: Keep design as simple as possible — but no simpler

DDD is an approach to software development that focuses on modeling software based on the core business domain. -> “Application Domain” (= Domain a software deals with)

1. Identify bounded context of application domains

2. For each application domain

   1. Extract the application domain‘s ubiquitous language

   2. Distill domain model from that language

   3. Reflect this model in working software using building blocks

   4. Employ layered architecture to develop domain application

3. Deploy and Link domain application as indicated by context map

-> today: consider realising each “domain application” as microservice.

Ubiquitous Language is a shared vocabulary used by both domain experts and technical experts

-> translates domain concepts into program constructs

Why is Ubiquitous Language only meaningful within a single context?

terminology depends on the domain's meaning and boundaries, and using the same terms across different domains leads to confusion.

What should be done instead?

1. Separate the application into clear bounded contexts

2. Establish ubiquitous language for each context

3. Map concepts shared between contexts in context map

declares definitional boundary for ubiquitous language

What does it depend on?

• application domain (e.g., actors, functionality)

• team organization (e.g., how many teams work on the system)

• physical structure (e.g., codebase, databases)

-> within Bounded context, the ubiquitous language and domain model should be strictly enforced

core practice of DDD, where domain models guide the software design

-> code tightly related to model

An effective domain model:

• Encodes a deep understanding of the domain

• Includes all relevant concepts — but no more than necessary

• Helps teams develop and use a shared language

• Makes it easier to spot ambiguities or inconsistencies

• Does not expose technical implementation details

→ “All models are wrong but some are useful.” – Box, 1976

Services, Entities, Value Objects

Responses, Aggregates, Factories

DDD uses specific patterns to express domain logic and support implementation, divided into two categories:

✅ Domain Concepts (Green):

• Entities – Have identity, change over time

• Value Objects – Immutable, defined by their attributes

• Services – Operations that don't naturally belong to a specific object

🔴 Support Structures (Red):

• Aggregates – Groups of entities/values with a consistency boundary

• Repositories – Provide access to aggregates (simulate collections)

• Factories – Create complex objects/aggregates consistently

Model-Driven Design encourages expressing your business rules using these building blocks, instead of relying on frameworks or databases.

→ Don't mix with Smart UI: focus on logic, not just user interfaces.

An Entity is a domain object that has a distinct identity which persists over time, regardless of its attribute values.

• unique identity

• continuity throughout life cycle

A Value Object is a domain object that is defined by its attributes, not by an identity.→ It is immutable and interchangeable if all its attributes are equal.

• identity derived from attributes

• immutable

A Service is a domain operation that doesn’t naturally belong to an Entity or Value Object, but is still part of the domain logic.

• encodes functionality (representes verb/action)

• stateless (no internal state is tracked between calls)

Address: Value object (not unique)

Address: Entities

An Aggregate is a cluster of domain objects (entities and value objects) that are treated as a single unit for data changes and consistency.

• defines boundaries around root entity (that control access)

• ensures invariants and concurrent access within the aggregate

A Factory is a design pattern used to create complex objects or aggregates, especially when creation involves multiple steps or invariants.

• hides complexity of object construction

• separates construction concern

A Repository is a mechanism for accessing and storing aggregates, acting like an in-memory collection, even if backed by a database.

• simulate collection of entities or aggregates

• persistence mechanism

A Module is a logical grouping of related domain concepts, used to organize the model into cohesive, understandable parts.

• low coupling

• high cohesion

BookingService = Service

RegistrationProcess = Service (was clear because of task description in exam)

Person = Entity

Venue = Entity (life cycle due to registration)

Event = Entity (here defined with life cycle)

Registration = Entity

Bill = Value Object (well defined and specific value attribute)

Stay = depends on definition: if it cannot be changed = immutable-> value object, if you can change (has lifecycle) = not immutable -> enitity

Hotel

(Lsg. siehe Foto auf Handy)

All classes that have setters are entities

Strategic Design focuses on structuring large systems by dividing them into Bounded Contexts and managing their relationships.

-> combines building blocks and how they interact

Different (Bounded) Contexts:

A Context Map defines how different Bounded Contexts relate to each other

Core Domain

Shared Kernel

Supporting Domain

Generic Subdomain

Upstream Team = Supplier

Downstream Team = Customer