Über arc42

arc42, das Template zur Dokumentation von Software- und Systemarchitekturen.

Erstellt von Dr. Gernot Starke, Dr. Peter Hruschka und Mitwirkenden.

Template Revision: 8.0 DE (asciidoc-based), Februar 2022

© We acknowledge that this document uses material from the arc42 architecture template, https://arc42.org.

1. Introduction and Goals

The dqualizer project is an example of the promotion of innovative small and medium-sized enterprises (SMEs). The sponsor of the initiative called "KMU-innovativ" is the Federal Ministry of Education and Research (BMBF). With the "KMU-innovativ" initiative, the BMBF has set up a "fast lane" for small and medium-sized enterprises. SMEs can submit their project ideas in the field of information and communication technologies at any time and receive preferential support through simplified funding and accelerated approval procedures. The aim is to cushion innovation risks for SMEs and to support SMEs with top performance in the high-tech sector.

How does the dqualizer project intend to be a driver of innovation for SMEs?

In order to outline the objective of dqualizer, the project specification document (german: Vorhabenskurzbeschreibung) [1] is quoted and commented below:

"The runtime quality of a given application system - e.g. in terms of performance, reliability and resilience - plays a critical role on the usage and usability of said application. Runtime quality therefore has a direct impact on a company’s business success. This applies to companies in a wide variety of technical domains. To put it more poetic, one could state that running software is the lifeblood of a running business.

Given this premise it becomes critical to analyse the runtime quality of a given application, e.g. with regards to resiliency. To analyse aspects of runtime quality it is vital to continuously monitor, evaluate and, if necessary, improve runtime quality through analysis measures. In recent years, such suitable analysis measures like load tests or monitoring have become widespread in the field of IT.

At the same time, sophisticated commercial and open source tools have been developed. However, these measures are all based on a technical level or perspective. They are not being interpreted at a functional domain level or perspective. Also at the same time, software architecture and software development approaches such as Domain-Driven Design (DDD) are becoming increasingly widespread. However these do not essentially consider the issues of runtime quality, despite the topics criticality.

So practicioners in the field lack access to

a) sophisticated commercial and / or open source tools to analyze runtime quality of an application system without a strictly technical perspective

b) software architecture and software development approaches that essentially consider the issues of runtime quality.

The dqualizer research project aims to close this gap between the domain expertise of the application systems and the (technical) measures and findings of quality assurance. The focus is on a domain-centered solution approach."

How does dqualizer intend to assist practitioners in SMEs?

To this end, possibilities for modeling and monitoring runtime quality issues are to be integrated into DDD-based techniques. From a technical perspective, dqualizer can be used to automatically generate and interpret meaningful load and resilience tests and establish links to technical monitoring.

The innovative concepts developed are to be implemented in an open source tool and made available and accessible in connection with existing tools. The practical applicability of the dqualizer approach will be evaluated in real case studies. Those will take place in the complex technical domains of insurance and payroll/tax accounting as well as the corresponding technical environments. To this end, multiple case studies are provided by the two associated application partners, DATEV eG and VHV Solutions GmbH.

As a result, employees with responsibilities in the specialist departments and employees with management responsibilities can be involved in the quality management of a company’s software. This can take place throughout the entire software life cycle, from requirements gathering to the operation and maintenance of the running software. Such a broad applicability means a higher level of software quality in terms of non-functional properties, which is particularly beneficial for business-critical applications in Germany.

The rest of this chapter is divided into three sections.

Firstly, a brief description of the requirements in section 1.1 [Requirements overview]. Secondly a list of the most relevant quality goals for the architecture in 1.2 [Quality goals], the achievement of which is critical for the most important stakeholders. Thirdly and finally, the section 1.3 [Stakeholders] provides an overview of the most important stakeholders and their expectations regarding the architecture.

1.1. 1.1. Requirements Overview

To gather and refine user stories and requirements for a potential tool, the dqualizer team conducted a workshop. The results of said workshop is documented below in a tabular use-case format.

Use Case Notes

As a domain expert who is interested in the results of the quality analysis at runtime, I would like to have a display that shows the analysis results obtained in order to be able to interpret the results obtained.

Domain expert

As a domain expert, I would like to know what the response time is between two endpoints to ensure that my SLA remains guaranteed.

Domain expert

As a technical expert interested in the results of the runtime quality analysis, I would like to include the response times in the results of a runtime quality analysis in order to draw a concise conclusion.

Technical expert

As a domain-based dqualizer user, I would like to define an expected response time for a load test to verify that my measurement point meets the SLO/SLA.

Domain-based dqualizer user

As a domain expert, I would like to define a static load for a load test.

Domain expert

As a domain expert, I would like to be able to define a (stimulus of a) load test in order to estimate whether my system shows the desired functions under load.

Domain expert
Use Case Notes

As a domain expert, I would also like to be able to ask questions about a story as a whole, e.g. frequency of occurrence.

Domain expert

As a domain expert interested in resilience, I would like to specify the expected response for a resilience scenario in order to check whether my system is responding correctly.

Domain expert

As a domain expert interested in monitoring, I want to specify a response time threshold to see if my subsystems and components are responding within the acceptable threshold.

Domain expert

As a domain expert, I want to be able to define multiple response metrics in a question.

Domain expert

As a domain expert interested in monitoring, I want to define multiple measurement endpoints to monitor different interfaces within my application.

Domain expert

As a domain expert, I want to know the performance of my application under high load.

Domain expert

1.2. 1.2. Quality goals

The arc42 template recommends listing in the Quality Goals section the three to a maximum of five most important quality objectives for the architecture. The fulfillment of those objectives will be seen as of the utmost importance for the most critical stakeholders. Architectural quality objectives should not be confused with or equated with project objectives.

In our context, the distinction between dqualizer as a project and as a tool should also be noted.

Als Einsteig in die Architektur des dqualizer Werkzeuges dient die Abbildung 1b in der Vorhabenskurzbeschreibung[2], welche die dqualizer-Architektur mit den dq-Teilkomponenten und die Anbindung existierender Laufzeitqualitätsanalysewerkzeuge darstellt.

Abbildung 1b

Table A 3 -5 Quality objectives of the dqualizer tool

Qualitätsziel Beschreibung

dq-Teilkomponenten als interagierende Subsysteme

Qualitätsziel 1 formuliert als Text

Anbindung existierender Laufzeitqualitätsanalysewerkzeuge

Qualitätsziel 2 formuliert als Text

Erweiterbarkeit

Qualitätsziel 3 formuliert als Text

1.3. 1.3. Stakeholder

An overview of business and (IT) technological stakeholders is provided, as well as a description of the respective expectations regarding the architecture.

Business stakeholders

Role Expectations

Manager

As a manager, I would like to know

a) what impact a changing number of customers has on IT resources in order to better estimate costs.

b) what effects technical failures have on business processes in order to estimate possible SLA violations.

c) how I can save IT resources to make my system more efficient.

d) how much individual domains (or processes) cost me.

e) how much it would cost to improve a quality property in order to increase the quality of the system.

(Domain) Product Owner

As a specialist product owner, I would like to

a) record and evaluate the quality requirements of the business expert with little effort.

b) communicate the effects of technical issues on IT resources to the technical expert with little translation effort.

Domain expert

As a domain expert, I would like to

a) define quality requirements and scenarios based on my modeled processes.

b) perform quality analyses based on my modeled processes.

c) always have an insight into the historical development or the current state of the quality of my modeled processes.

IT (-technical) stakeholder

Role Expectation

DevOps professional

As a DevOps professional or DevOps’ler I would like to

a) check what impact a failure of X% of my services will have on the end users.

b) know how I need to configure my system to ensure cost-optimized, error-free operation.

c) know whether my system can cope with the expected load so that I can react in good time.

Operations professional

As an operations professional or operator, I want

a) the maximum functionality with the minimum use of resources.

Development professional

As a development professional or developer, I want

a) to know which parts of the code are worth optimizing in order to use my time wisely.

Software architect

As a software architect, I want to

a) compare the actual architecture with the DDD model (as the target).

b) know which quality property is important for my service in order to be able to select the appropriate resilience mechanisms.

Technical tester

As a technical tester, I want

a) to cover the user stories of the given domain with my tests.

2. Randbedingungen

Dieses Kapitel beleuchtet alles, was das Team beim Design und der Implementierung der Architektur einschränkt. Diese Einschränkungen sind manchmal auch außerhalb eines Projekts in der gesamten Organisation gültig.

Der Inhalt des Kapitels sollte nach arc42 Empfehlung jede Anforderung sein, die Softwarearchitekten in ihrer Freiheit bei Design- und Implementierungsentscheidungen oder Entscheidungen über den Entwicklungsprozess einschränkt. Diese Zwänge gehen manchmal über einzelne Systeme hinaus und gelten für ganze Organisationen und Unternehmen.

Die Motivation hinter diesem Kapitel liegt darin, dass Architekten genau wissen sollten, wo sie in ihren Designentscheidungen frei sind und wo sie sich an Einschränkungen halten müssen. Zwänge müssen immer beachtet werden; sie können jedoch verhandelbar sein.

Die empfohlene Form sind einfache Tabellen mit Einschränkungen und Erklärungen. Bei Bedarf können diese unterteilt werden in technische Randbedingungen, organisatorische und politische Randbedingungen und Konventionen (z.B. Programmier- oder Versionierungsrichtlinien, Dokumentations- oder Namenskonventionen).

2.1. Technische Randbedingungen

Dieser Abschnitt soll nachvollziehbar die Fragestellung klären: Was sind die techn. Randbedingungen (hinsichtlich der Architektur)?

Techn. Randbedingung Beschreibung

<Text>

<Text>

<Text>

<Text>

2.2. Organisatorische Randbedingungen

Dieser Abschnitt erläutert die Fragestellung: Was sind die organisatorischen Randbedingungen?

Hier erfolgt eventuell ein Verweis auf die Stakeholder aus Kapitel 1 hinsichtlich der organisatorischen Randbedingungen.

Organ. Randbedingung Beschreibung

<Text>

<Text>

<Text>

<Text>

2.3. Konventionen

Dieser Abschnitt behandelt und politische Randbedingungen und Konventionen (z.B. Programmier- oder Versionierungsrichtlinien, Dokumentations- oder Namenskonventionen) im Kontext von dqualizer. Er soll die Frage "Was sind (weitere) Konventionen, welche beachtet werden sollen oder müssen?" beantworten.

Konvention Beschreibung

<Text>

Die Dokumentation der Architektur orientiert sich soweit sinnvoll an dem arc42 Template

<Text>

<Text>

3. Kontextabgrenzung

Der Umfang und Kontext des Systems (engl. System Scope and Context) grenzt ein System ab. Diese Abgrenzung bezieht sich auf die Kommunikationspartner des Systems, d.h. Nachbarsysteme und Benutzer. Der Scope legt damit die externen Schnittstellen fest.

Der Kontext wird hier differenziert in den geschäftlichen Kontext (domänenspezifische Ein- und Ausgänge) und den technischen Kontext (Kanäle, Protokolle, Hardware).

3.1. Fachlicher Kontext

Motivation: Die Domänenschnittstellen und die technischen Schnittstellen zu den Kommunikationspartnern gehören laut arc42 zu den kritischsten Aspekten eines Systems. Diese sind möglichst vollständig aufzuarbeiten.

In der Form eignen sich hierfür verschiedene Kontextdiagramme, sowie Listen von Kommunikationspartnern und deren Schnittstellen.

→ Systemkontextdiagram (evtl. via SysML) hier einfügen, um den fachlichen Kontext zu illustrieren.

3.2. Technischer oder Verteilungskontext

Im Vordergrund dieses Abschnittes stehen die technischen Schnittstellen (Kanäle und Übertragungsmedien), die das dqualizer System mit seiner Umgebung verbinden.

Zudem wird in arc42 ein Mapping der bereichsspezifischen Ein-/Ausgabe zu den Kanälen empfohlen (d. h. eine Angabe, welche Ein-/Ausgabe welche Kanäle verwendet).

Examples:

Example via https://docs.arc42.org/examples/technical-context-1/#32-technical-context.

The following diagram shows e.g. the participating computers (nodes) with their technical connections plus the major artifacts etc.

MES-Beispiel (System-) Kontextabgrenzung:

Das Miroboard enthält eine Abbildung bezüglich der Systemkontextsicht. Diese evtl. hier mittels PlantUML einfügen.

Das folgende Diagramm zeigt das Softwaresystem Werkstatt und seinen Systemkontext bestehend aus den Nutzern des Softwaresystems, der eigenen Datenbank und Nachbarsysteme names Mitarbeiter und Originalteile.

actor "Werkstattmeister:in" as meister
actor "Serviceberater:in" as berater
actor "Werkstattmitarbeiter:in" as mitarbeiter

component Werkstatt <<subdomain>>

node Mitarbeiter <<bounded context>>
node Orignalteile <<boundded context>>

database WerkstattDB

Werkstatt --> WerkstattDB
Werkstatt --> Mitarbeiter

meister --> Werkstatt
berater --> Werkstatt
mitarbeiter --> Werkstatt
Orignalteile -- Werkstatt

Context Map Beispiel:

Die Context Map zeigt die Bounded Contexts des Autohauses und gibt einen Überblick über die gesamte Domäne Autohaus und setzt die Subdomäne Werkstatt mit den Bounded Contexts Werkstattplanung und Werkstattservice in das sozio-technische Gesamtbild.

big picture context map

4. Lösungsstrategie

Dieses Kapitel dient als Zusammenfassung der fundamentalen Entwurfsentscheidungen und Lösungsstrategien für die Gesamtarchitektur. Es kann Technologieentscheidungen, Top-Level-Zerlegungsstrategie oder Ansätze zur Erreichung der wesentlichen Qualitätsziele beinhalten, bzw. relevante Organisationsentscheidungen.

Eine kurze Zusammenfassung und Erläuterung der grundlegenden Entscheidungen und Lösungsstrategien, die die Architektur des Systems bestimmen. Dazu gehören technologische Entscheidungen wie:

  • Entscheidungen über die Top-Level-Zerlegung des Systems, z. B. Verwendung eines Architekturmusters oder Entwurfsmusters

  • Entscheidungen darüber, wie wichtige Qualitätsziele erreicht werden können

  • relevante organisatorische Entscheidungen, z. B. die Wahl eines Entwicklungsprozesses oder die Delegation bestimmter Aufgaben an Dritte.

Motivation: Diese Entscheidungen bilden die Eckpfeiler für Ihre Architektur. Sie bilden die Grundlage für viele andere Detailentscheidungen oder Implementierungsregeln.

Form: Fassen Sie sich bei der Erläuterung dieser Schlüssel-Entscheidungen kurz.

Begründen Sie, was Sie entschieden haben und warum Sie sich so entschieden haben, basierend auf Ihrer Problemstellung, den Qualitätszielen und den wichtigsten Einschränkungen. Verweisen Sie auf Einzelheiten in den folgenden Abschnitten.

Qualitätsziel Szenario Lösungsansatz Link zu Details

<Text>

<Text>

<Text>

<Text>

<Text>

<Text>

<Text>

<Text>

5. Bausteinsicht

5.1. dqualizer

5.1.1. White Box Diagram

dqualizer overview Source: Architecture Board

5.2. dqualizer Komponenten

5.2.1. dqcockpit

Zweck / Zuständigkeit

Dqcockpit offers a (readonly) dashboard visualizing the results of executed RQAs and a management overview dashboard that displays the current system state based on automatically extracted analysis data which is translated to the domain level.

Wichtige ADRs

Weitere Klarstellungen

  • Wer macht das translaten? ist das dqtranslator oder cockpit? → dqtranslator

  • Machen wir die Meldung für neue Resultate synchron (Nofification) oder asynchron (MessageQueueing)? → in der ersten Iteration reicht synchron, aber langfristig gehen wir in Richtung asynchron

Variabilität

  • Das Pollen kann vorerst ohne Message Queue direkt von dqtranslator erfolgen und später dahingehend erweitert werden.

Qualitätsattribute

  • Useability

Fehlerverhalten

-

Deployment

  • Frontend deployed über Vercel/Vite

  • Backend als Webservice (k8s)

Offene Fragen

  • Wo werden kurze Zusammenfassungen der Ergebnisse in der Domain Story angezeigt? → Im dqanalyzer oder dqcockpit?

  • Ist der dqanalyzer Teil des dqcockpit?

  • Was wird im Frontend generiert und was wird vom Backend bereitgestellt? Z.B: wer zieht Grafana hoch? Unser Backend und wir deployen das Dashboard rein? Oder kriegen wir nur einen Link zu einem Grafana Dashboard?

Diagramm: dqcockpit black box Source: Architecture Board

5.2.2. dqanalyzer

Zweck / Zuständigkeit

The dqanalyzer component enables domain experts to specify and perform RQA without profound knowledge of the underlying technical infrastructure and analysis tools, e.g., by annotating elements in domain stories. The dqanalyzer does not necessarily provide the functionality to model a domain story. It starts with a provided domain story and its responsibility is in annotating the domain story with tests.

Wichtige ADRs

Weitere Klarstellungen

  • Was ist zuerst? dqanalyzer oder dqedit? Wenn z.B. in dqedit das Mapping bereits vorliegt (und somit teils die Architektur bekannt ist), dann können wir im dqanalyzer die Auswahl der Elemente entsprechend beschränken → Vorerst können wir vereinfacht annehmen, dass Mapping vorhanden, aber mittelfristig sollte es auch ohne funktionieren (evtl. mit eingeschränkter Funktionalität)

  • Das Interface DSTLoader kann intern (Nutzer über GUI) oder auch extern (Button in WPS Modeler) angesprochen werden.

Qualitätsattribute

  • Useability

Fehlerverhalten

-

Deployment

-

Offene Fragen

-

Diagramm: dqanalyzer black box Source: Architecture Board

5.2.3. dqedit

Zweck / Zuständigkeit

The dqedit component is the editor for the mapping necessary to translate domain questions / RQA definitions to technical RQA configurations. The editor can be used by domain and technical experts during DDD-based workshops, e.g., for event storming or DST, where the domain elements are identified and defined.

Wichtige ADRs

-

Weitere Klarstellungen

-

Variabilität

  • Wo kommen DST und API-Beschreibung der Applikation her? → vorläufig nehmen wir an vom Nutzer, später können wir es schöner machen und sie von anderen dqualizer-Komponenten ziehen

Qualitätsattribute

-

Fehlerverhalten

  • Datenbank könnte nicht erreichbar sein, wenn gespeichert wird. (Was soll passieren?)

Deployment

Web-App (mit UI & REST, Browserbasiert)

Offene Fragen

  • Wo können wir API/DST am besten herbekommen?

Diagramm: dqedit black box Source: Architecture Board

5.2.4. dqlang

Zweck / Zuständigkeit

The dqlang is a collection of languages utilized by dqualizer e.g., the DST extension for domain-level RQA specification or the language for defining mappings in dqedit.

Wichtige ADRs

Weitere Klarstellungen

-

Variabilität

-

Qualitätsattribute

  • Traceability (Welche Spezifikationsversion wird verwendet?)

Fehlerverhalten

-

Deployment

GIT Repository (Release mit GitHub Actions; Schema-Files mit dateibasiertem Versioning)

Offene Fragen

-

Diagramm: dqlang black box Source: Architecture Board

5.2.5. dqtranslator

Zweck / Zuständigkeit

Dqtranslator maps (domain) RQA definitions to technical RQA configurations that can be executed by dqexec. It also maps the technical results (metrics) back to the domain level, i.e., domain experts can understand the results.

Wichtige ADRs

Weitere Klarstellungen

-

Variabilität

-

Qualitätsattribute

-

Fehlerverhalten

-

Deployment

-

Offene Fragen

  • dqlang-Abhängigkeiten nicht aufgezeigt.

Diagramm: dqtranslator black box Source: Architecture Board

5.2.6. dqexec

Zweck / Zuständigkeit

The dqexec component executes the RQA configuration by utilizing state-of-the-art monitoring, load testing, and resilience testing tooling. The specification is received in a generic format and then mapped to the input models of the external analysis tooling. Besides delegating the RQA execution, dqexec is also responsible for choosing the most appropriate analysis tool, repeating tests to reach a certain accuracy, and enriching the tests with tool-specific default values.

Wichtige ADRs

-

Weitere Klarstellungen

-

Variabilität

-

Qualitätsattribute

-

Fehlerverhalten

-

Deployment

-

Offene Fragen

  • Interfaces of external tools are currently just displayed in a very abstract manner.

Diagramm: dqexec black box Source: Architecture Board

5.2.7. Weitere Building Blocks

  • Test Status Queue

  • Mapping Database

  • TechnicalResultStoreController

5.3. THIS IS OLD

Notizen von mbe:

Die vollständige Abbildung der fachlichen Module ergibt sich durch die Paketstruktur in der Hexagonal bzw. Clean Architecture. Hier liegt der Fokus auf dem Domänenmodell abgebildet anhand von Aggregates, Entites und Value Objects.

Aufbauend auf der Context Map aus dem Kapitel Systemkontextsicht, wird im folgenden die Subdomäne Werkstatt beschrieben.

Die vollständige Abbildung der fachlichen Module ergibt sich durch die Paketstruktur in der Hexagonal bzw. Clean Architecture. Hier liegt der Fokus auf dem Domänenmodell abgebildet anhand von Aggregates, Entites und Value Objects.

Aufbauend auf der Context Map aus dem Kapitel Systemkontextsicht, wird im folgenden die Subdomäne Werkstatt beschrieben.

5.4. Whitebox Subdomäne Werkstatt

package "Werkstatt" as werkstatt <<subdomain>> {

    package "Werkstattplanung" as werkstattplanung <<bounded context>> {

    }

    package "Werkstattservice" as werkstattservice <<bounded context>> {

    }

    werkstattplanung --> werkstattservice

}
Enthaltene Blackbox Bausteine
Bounded Context Beschreibung

Werkstattplanung

Organisation der Werkstattabläufe und Dienstleistungsprozesse der Werkstatt.

Werkstattservice

Planung des Dienstleistungsangebots gegenüber Privat- und Firmenkunden.

5.5. Whitebox Bounded Context Werkstattplanung

package "Werkstattplanung" as werkstattplanung <<bounded context>> {

    package "Werkstattplan" as werkstattplan <<aggregate>> {

    }

    package "Werkstattauftrag" as werkstattauftrag <<aggregate>> {

    }

    werkstattplan --> werkstattauftrag

}
Enthaltene Blackbox Bausteine
Aggregate Beschreibung

Werkstattplan

Planung der Werkstattauslastung unter Berücksichtigung der Verfügbarkeit und Kompetenz

Werkstattauftrag

Rechtlich bindende Vereinbarung zur Durchführung von Dienstleistungen (Services) am Fahrzeug

5.6. Wichtige Schnittstellen

Aggregate Eingehend Aussgehend

Werkstattplan

Werkstattauftrag planen, Backend for Frontend REST API

Werkstattauftrag

Originalteil verfügbar, Backend for Frontend REST API

Werkstattauftrag planen

5.7. Whitebox Bounded Context Werkstattservice

package "Werkstattservice" as werkstattservice <<bounded context>> {

    package "Werkstattservice"" as werkstattserviceAggregate <<aggregate>> {

    }

    package "WerkstattserviceGruppe" as werkstattserviceGruppe <<aggregate>> {

    }

    werkstattserviceAggregate --> werkstattserviceGruppe

}
Enthaltene Blackbox Bausteine
Aggregate Beschreibung

Werkstattservice

Ein Werkstattservice beschreibt eine Dienstleistung am Fahrzeug. Dies beinhaltet Arbeitszeit, Originalteile und sonstigen Materialverbrauch.

WerkstattserviceGruppe

Ein WerkstattserviceGruppe gruppiert Werkstattservices gleicher Art und beschreibt für die Gruppe den Kostensatz für ein Arbeitswert. Gruppen sind Karroserie, Mechanik und Elektronik.
Wichtige Schnittstellen

Bisher keine

5.8. Whitebox Aggregate Werkstattplan

package "Werkstattplan" as wplan <<aggregate>> {

    class WerkstattplanService <<service>>
    class WerkstattplanRepository <<repository>>

    package "domain.model" as model {
        class "Werkstattplan" as theAggregateRoot <<aggregate root>>
        class "Werkstattplanstatus" as status <<value object>>>
        class "Tagesplan" as tagesplan <<entity>>
        class "Tagesplanstatus" as tagesplanstatus <<value object>>
        class "Werkstatttermin" as termin <<entity>>
        class "Start" as start <<value object>>
        class "Ende" as ende <<value object>>
        class "Bearbeiter" as bearbeiter <<value object>>
        class "WerkstattauftragRef" as werkstattauftragRef <<value object>>
        theAggregateRoot --> status
        theAggregateRoot --> tagesplan
        tagesplan --> tagesplanstatus
        tagesplan --> termin
        termin --> start
        termin --> ende
        termin --> bearbeiter
        termin --> werkstattauftragRef
    }

    WerkstattplanService --> theAggregateRoot
    WerkstattplanService --> WerkstattplanRepository
}

5.9. Whitebox Aggregate Werkstattauftrag

package "Werkstattauftrag" as werkstattauftragModul <<aggregate>> {

    class WerkstattauftragService
    class WerkstattauftragRepository

    package "domain.model" as domainModel {
        class Werkstattauftrag <<aggregate root>>
        class Fahrzeugkennzeichen <<value object>>
        class Bearbeiter <<value object>>
        class Werkstattauftragstatus <<value object>>
        class Auftragsposition <<entity>>
        class Werkstattservice <<entity>>
        class Material <<value object>>
        class MaterialRef <<value object>>

        Werkstattauftrag --> Fahrzeugkennzeichen
        Werkstattauftrag --> Bearbeiter
        Werkstattauftrag --> Werkstattauftragstatus
        Werkstattauftrag --> Auftragsposition
        Auftragsposition --> Werkstattservice
        Werkstattservice --> Material
        Material --> MaterialRef

    }

    WerkstattauftragService --> WerkstattauftragRepository
    WerkstattauftragService --> Werkstattauftrag
}

5.10. Whitebox Aggregate Werkstattservice

package "Werkstattservice" as werkstattserviceModul <<aggregate>> {

    class WerkstattserviceService <<service>>
    class WerkstattserviceRepository <<repository>>

    package "domain.model" as domainModel  {
        class Werkstattservice <<aggregate root>>
        class Bezeichnung <<value object>>
        class WerkstattserviceKennung <<value object>>
        class WerkstattserviceGruppeRef <<value object>>
        class Material <<value object>>
        class Materialpreis <<value object>>
        class Menge <<value object>>
        class Arbeitswert <<value object>>
        class MaterialRef <<value object>>

        Werkstattservice --> Bezeichnung
        Werkstattservice --> WerkstattserviceKennung
        Werkstattservice --> WerkstattserviceGruppeRef
        Werkstattservice -->"*" Material
        Werkstattservice --> Arbeitswert
        Material --> Menge
        Material --> Materialpreis
        Material --> MaterialRef
    }

    WerkstattserviceService --> WerkstattserviceRepository
    WerkstattserviceService --> Werkstattservice

}

5.11. Whitebox Aggregate WerkstattserviceGruppe

package "WerkstattserviceGruppe" as werkstattserviceGruppe <<aggregate>> {

    class WerkstattserviceGruppeService <<service>>
    class WerkstattserviceGruppeRepository <<repository>>


    package "domain.model" as domainModel {
        class WerkstattserviceGruppe <<aggregate root>>
        class WerkstattserviceGruppeBezeichung <<value object>>
        class ArbeitswertKostensatz <<entity>>
        class Kostensatz <<value object>>
        class Waehrung <<value object>>

        WerkstattserviceGruppe --> WerkstattserviceGruppeBezeichung
        WerkstattserviceGruppe --> ArbeitswertKostensatz
        ArbeitswertKostensatz --> Kostensatz
        ArbeitswertKostensatz --> Waehrung
    }

    WerkstattserviceGruppeService --> WerkstattserviceGruppe
    WerkstattserviceGruppeService --> WerkstattserviceGruppeRepository

}

6. Laufzeitsicht

6.1. Define and Execute RQA

runtime execute RQA configuration Source: Architecture Board

  • Annahmen:

    • Eine Domain Story-File ist vorhanden

    • D-A-Mapping ist vorhanden

6.2. Collect and Show Results

runtime collect and show results Source: Architecture Board

  • Annahmen:

    • RQA Test ist durchgelaufen

    • D-A-Mapping ist vorhanden

6.3. OLD

Die Laufzeitsicht beschreibt das konkrete Verhalten und die Interaktionen der Systembausteine in Form von Szenarien aus den folgenden Bereichen:

  • wichtige Anwendungsfälle oder Funktionen: wie werden sie von den Bausteinen ausgeführt?

  • Interaktionen an kritischen externen Schnittstellen: Wie arbeiten die Bausteine mit Benutzern und Nachbarsystemen zusammen?

  • Betrieb und Verwaltung: Start, Inbetriebnahme, Stopp

  • Fehler- und Ausnahmeszenarien

Es sei zu beachten, dass das Hauptkriterium für die Auswahl der möglichen Szenarien (Sequenzen, Workflows) ist ihre architektonische Relevanz. Es ist nicht wichtig, eine große Anzahl von Szenarien zu beschreiben. Sie sollten vielmehr eine repräsentative Auswahl dokumentieren.

6.4. <Bezeichnung Laufzeitszenario 1>

  • <hier Laufzeitdiagramm oder Ablaufbeschreibung einfügen>

  • <hier Besonderheiten bei dem Zusammenspiel der Bausteine in diesem Szenario erläutern>

Siehe Miro Board → unter Bausteinsicht Ebene 1 Iteration 2 → Laufzeitsicht → in PlantUML

6.5. <Bezeichnung Laufzeitszenario 2>

…​ === <Bezeichnung Laufzeitszenario n>

…​

7. Verteilungssicht (Deployment View)

In diesem Kapitel wird die technische Infrastruktur mit (echten oder virtuellen) Prozessoren, Systemtopologie, und die Abbildung der Software-Bausteine auf diese Infrastruktur beleuchtet.

Die Verteilungssicht beschreibt:

  • die technische Infrastruktur, die zur Ausführung Ihres Systems verwendet wird, mit Infrastrukturelementen wie geografischen Standorten, Umgebungen, Computern, Prozessoren, Kanälen und Netz-Topologien sowie anderen Infrastrukturelementen und

  • die Zuordnung von (Software-)Bausteinen zu diesen Infrastrukturelementen.

Oft werden Systeme in verschiedenen Umgebungen ausgeführt, z. B. Entwicklungsumgebung, Testumgebung, Produktionsumgebung. In solchen Fällen sollten Sie alle relevanten Umgebungen dokumentieren.

Dokumentieren Sie insbesondere die Deployment-Sicht, wenn Ihre Software als verteiltes System mit mehreren Computern, Prozessoren, Servern oder Containern ausgeführt wird oder wenn Sie Ihre eigenen Hardware-Prozessoren und Chips entwerfen und konstruieren.

Aus der Software-Perspektive reicht es aus, die Elemente der Infrastruktur zu erfassen, die erforderlich sind, um den Einsatz Ihrer Bausteine darzustellen. Hardware-Architekten können darüber hinausgehen und die Infrastruktur bis zu einem beliebigen Detaillierungsgrad beschreiben, den sie benötigen.

Motivation: Software läuft nicht ohne Hardware. Die zugrunde liegende Infrastruktur kann und wird Ihr System und/oder einige übergreifende Konzepte beeinflussen. Daher müssen Sie die Infrastruktur kennen.

Form: Das Deployment-Diagramm auf höchster Ebene ist vielleicht schon in Abschnitt 3.2. als technischer Kontext mit Ihrer eigenen Infrastruktur als EINE Blackbox enthalten. In diesem Abschnitt werden Sie in diese Blackbox hineinzoomen, indem Sie zusätzliche Deployment-Diagramme verwenden.

  • Die UML bietet Deployment-Diagramme, um diese Sichtweise auszudrücken. Verwenden Sie diese, wahrscheinlich mit verschachtelten Diagrammen, wenn Ihre Infrastruktur komplexer ist.

  • Wenn Ihre (Hardware-)Stakeholder andere Diagrammtypen als UML-Deployment-Diagramme bevorzugen, lassen Sie sie jede Art von Diagramm verwenden, das die Knoten und Kanäle der Infrastruktur darstellen kann.

7.1. Infrastruktur Ebene 1

Beschreiben Sie (normalerweise in einer Kombination aus Diagrammen, Tabellen und Text):

  • die Verteilung Ihres Systems auf mehrere Standorte, Umgebungen, Computer, Prozessoren, …​ sowie die physischen Verbindungen zwischen ihnen

  • eine wichtige Begründung oder Motivation für diese Einsatzstruktur

  • Qualitäts- und/oder Leistungsmerkmale der Infrastruktur

  • die Zuordnung von Software-Artefakten (Bausteinen) zu Elementen der Infrastruktur

<Übersichtsdiagramm>

Begründung

<Erläuternder Text>

Qualitäts- und/oder Leistungsmerkmale

<Erläuternder Text>

Zuordnung von Bausteinen zu Infrastruktur

<Beschreibung der Zuordnung>

7.2. Infrastruktur Ebene 2

Hier können Sie die interne Struktur von (einigen) Infrastrukturelementen der Infrastrukturebene 1 übernehmen.

Bitte kopieren Sie die Struktur aus Ebene 1 für jedes ausgewählte Element.

7.2.1. <Infrastrukturelement 1>

<Diagramm + Erläuterungen>

7.2.2. <Infrastrukturelement 2>

<Diagramm + Erläuterungen>

…​ ==== <Infrastrukturelement n>

<Diagramm + Erläuterungen>

8. Querschnittliche Konzepte

In diesem Kapitel werden übergreifende, grundsätzliche Regelungen und Lösungsideen beschrieben, welche in mehreren Teilen (→ Querschnitt) des Systems relevant sind. Solche Konzepte sind oft mit mehreren Bausteinen verbunden. Sie umfassen viele verschiedene Themen, wie z. B.

  • Domänenmodelle

  • Architekturmuster oder Entwurfsmuster

  • Regeln für den Einsatz bestimmter Technologien

  • prinzipielle, oft technische Entscheidungen von Gesamtentscheidungen

  • Implementierungsregeln

Begründung

Konzepte bilden die Grundlage für die konzeptionelle Integrität (Konsistenz, Homogenität) der Architektur. Sie sind somit ein wichtiger Beitrag zur Erreichung innerer Qualitäten Ihres Systems.

Einige dieser Konzepte lassen sich nicht einzelnen Bausteinen zuordnen (z.B. Security oder Safety). Dies ist der Platz in der Vorlage, den wir für eine kohärente Spezifikation solcher Konzepte vorgesehen haben. Formular

Die Form kann variiert werden:

Konzeptpapiere mit beliebiger Struktur
übergreifende Modellauszüge oder Szenarien unter Verwendung von Notationen der Architektursichten
Beispielimplementierungen, insbesondere für technische Konzepte
Hinweise auf die typische Verwendung von Standard-Frameworks (z.B. Verwendung von Hibernate für Objekt/Relational Mapping)

8.1. <Konzept 1>

<Erklärung>

8.2. <Konzept 2>

<Erklärung>

…​ === <Konzept n>

<Erklärung>

9. Fachliche Struktur und Modelle

10. Architektur- und Entwurfsmuster

11. Unter-der-Haube

12. User Experience

13. Architekturentscheidungen

We use component prefixes when ADRs are closely related to one component (dqanalyzer, dqcockpit, dqedit, dqtranslator, dqlang, dqexec).

13.1. C1: dqcockpit is read-only

Status

Accepted

Context

We need to know whether dqcockpit does (interactively) modify the results to design the interfaces between dqcockpit and other components.

Decision

dqcockpit does not modify the results - at least not in a way that is relevant to other components. dqcockpit still allows to modify the layout / presentation of the results.

Consequences

The amount of external required functionality for dqcockpit is low resulting in a reduced coupling of the component. The drawback is that users have to create or modify a RQA to get new results

Alternatives

Users can modify the RQA results or the RQA in dqcockpit - we do not allow that since dqanalyzer is responsible for defining RQAs and the responsibilities of the components need to be separated.

13.2. C2: dqcockpit polls results

Status

Proposed

Context

The dqcockpit has to obtain the RQA results in some way. We need to know which component is responsible for updating the results in the cockpit.

Decision

The dqcockpit decides when to poll results.

Consequences

This requires a notification mechanism to publish the status of the analysis (more effort) or dqcockpit has to poll frequently (inefficient). However, other components (dqanalyzer) could be notified as well and poll the same results. Furthermore, the status could be interesting for other functionalities as well to keep the user posted on the current progress.

Alternatives

Another component dqexec / dqtranslator could directly send the results to the dqcockpit, although it could not be available. Furthermore, changes to the sender will be necessary if other components are interested in receiving the state / results which increases coupling.

13.3. C3: results for dqcockpit are provided by dqtranslator

Status

Proposed

Context

To model the overall architecture, the dependencies of the dq-components need to be defined. Dqcockpit has to get the results and it must be clear which component is responsible for translating the technical RQA results to the domain RQA results.

Decision

dqtranslator is the component that delivers the domain RQA results directly to dqcockpit (after being requested to do so).

Consequences

dqcockpit never speaks to dqexec so the coupling between these two components is low. However, there is probably more implementation overhead in dqtranslator.

Alternatives

dqexec could send the results directly to dqcockpit and dqcockpit could then use the dqtranslator to map them to the domain level. However, that would create more complex communication between several components leading to lower maintainability.

13.4. A1: dqanalyzer does not necessarily provide functionality to model a domain story

Status

Accepted

Context

The question is whether modeling domain stories is part of dqualizer. If yes, a key decision would be to develop an own modeler (big effort) or use an existing, established one (high dependency on that tool and its development). The second case is particularly relevant since there are not many DST modelers and the WPS modeler is hard to extend.

Decision

dqedit does not need to be able to model domain stories.

Consequences

Modifying domain stories is less convenient for the user since it has to be done in another tool. On the other hand, dqedit is easier to develop and maintain with a weaker dependency on the domain story modeller(s). In theory, dqedit could import different domain story description formats of different modelers.

Alternatives

Dqedit must be integrated in a domain story modeler. Modeling and annotating are usually two quite separate use cases (there is often no reason to change the domain story when defining an RQA). Thus, the usability in this rare use case can be neglected in favor of significantly reducing the implied constraints on the development of dqedit and probably lower usability in the core use cases.

13.5. A2: dqanalyzer kann neben dqcockpit ebenfalls Ergebnisse anzeigen

Status

Proposed

Context

The initial dqanalyzer created by Dominik shows the results of RQA inside of the dqanalyzer. The question is whether we want a clear separation of specifying RQA definitions and investigating the results.

Decision

dqedit can also show (partially) the same or different results but should keep it on a high level

Consequences

Seeing the results in the dqedit makes it easier for users to get an answer to their domain question since they have everything in one place. In particular, users can relate metrics to domain elements. However, additional care is necessary to not develop duplicated functionality in dqedit and dqcockpit.

Alternatives

dqcockpit could be the sole source for the RQA results. However, in Dominik’s evaluation participants explicitly stated that they liked "to have everything in one place".

13.6. A3: dqanalyzer kann Ergebnisse vom dqtranslator abrufen (analog zu dqcockpit)

Status

Proposed

Context

The main component for investigating the RQA results is dqcockpit. Thus, we need to define where dqanalyzer gets the results from, i.e., whether the source is dqcockpit or another component.

Decision

dqedit can obtain results from dqtranslator similarly than dqcockpit

Consequences

dqtranslator is the central source of domain RQA results for the front-end components, keeping its cohesion high.

Alternatives

dqedit could obtain (reduced) results from dqexec or dqcockpit which would probably be more efficient but reduce maintainability. We do not want to maintain several ways of obtaining results.

13.7. A4: RQA Definitionen werden in dqanalyzer persistiert

Status

Proposed

Context

RQA definitions should be persisted, but not every component needs access to them.

Decision

dqanalyzer (internally) persists the RQA definitions.

Consequences

Other components can not get the RQA definitions without contacting dqanalyzer

Alternatives

There could be a global database but dqanalyzer (and other components) would have external dependencies with increased effort for maintaining and accessing the data. However, in theory, there is no need for other components to persist the RQA definitions since dquanalyzer provides them if necessary.

13.8. L1: Schema Versioning is based on and performed by Git(Hub)

Status

Proposed

Context

Schemas for the mapping, RQA definitions, etc. …​ can change and should have a version to be compatible with one another and with the models.

Decision

We use the functionality provided by Git(Hub) that is actually designed for file versioning.

Consequences

The effort for providing versioning functionality is significantly reduced. However, implementation is also restricted to the provided functionality by Git(Hub).

Alternatives

Own implementation, but versioning is not one of our key functionalities and competencies.

13.9. L2: Different dqlang schemas can use different meta models

Status

Proposed

Context

Do the existing dqlang schemas have to be unified? In the future, this would require different dqualizer members have to learn the use of this meta model.

Decision

The dqlang schemas can be defined using different meta models

Consequences

This makes it easier for dqualizer members to use the techniques they are familiar with. Furthermore, the used meta model is (ideally) always the most suitable for the schema. The drawback is potentially low compatibility between the different schemata.

Alternatives

Every dqualizer member uses the same meta model. We do not want to enforce that - everyone should use his/her expertize best.

13.10. ADR Template

13.11. Temp1: A brief and descriptive title for the decision.

Status

What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?

Context

What is the issue that we’re seeing that is motivating this decision?

Decision

What is the decision that we’re proposing and/or doing?

Consequences

What becomes easier or more difficult to do because of this decision?

Alternatives

What are alternative options considered, along with the reasons they were not selected?

13.12. OLD

Dieses Kapitel erläutert wichtige, kostspielige, groß angelegte oder riskante Architekturentscheidungen einschließlich der Begründungen. Mit "Entscheidungen" meinen wir die Auswahl einer Alternative auf der Grundlage bestimmter Kriterien.

Das arc42 Template empfiehlt an dieser Stelle nach eigenem Ermessen zu entscheiden, ob eine Architekturentscheidung hier in diesem zentralen Abschnitt dokumentiert werden sollte oder ob Projektteilnehmer sie besser lokal dokumentieren (z.B. innerhalb der White-Box-Vorlage eines Bausteins). Redundante Texte sind weitestgehend zu vermeiden. Verweisen Sie auf Abschnitt 4, wo Sie bereits die wichtigsten Entscheidungen Ihrer Architektur festgehalten haben.

Motivation: Die Stakeholder des Systems sollen Ihre Entscheidungen nachvollziehen und nachvollziehbar machen können.

In der Form kann

  • eine ADR (Architecture Decision Record) für jede wichtige Entscheidung,

  • Liste oder Tabelle, geordnet nach Wichtigkeit und Konsequenzen oder

  • detaillierter in Form von separaten Abschnitten pro Entscheidung

genutzt werden.

Grundlage hierfür ist der Unterpunkt "ADR" in Miro.

13.13. Entwurfsentscheidung No. 1

Kontext: ContextMap von YML laden für MVP?

Entscheidung:

Status:

Konsequenzen:

13.14. Entwurfsentscheidung No. 2

Kontext: Domain Story in DqDomainModeller bezieht sich immer auf einen Bounded Context

Entscheidung:

Status:

Konsequenzen:

13.15. Entwurfsentscheidung No. 3

Kontext: Use CQRS, e.g. abhängig Microservice dqWorkbench und dqContextMap

Entscheidung:

Status:

Konsequenzen:

13.16. Entwurfsentscheidung No. 4

Kontext: Dqedit adaptiert / transformiert, dass DST File Format auf Dqlang

Entscheidung:

Status:

Konsequenzen:

13.17. Entwurfsentscheidung No. 5

Kontext: Wer triggert dqExec?

Entscheidung:

Status:

Konsequenzen:

13.18. Entwurfsentscheidung No. 6

Kontext: DqMissionControl Backend hat eine Dqlang Published Language, die über die API exponiert wird.

Entscheidung:

Status:

Konsequenzen:

14. Qualitätsanforderungen

Dieses Kapitel enthält alle Qualitätsanforderungen als Qualitätsbaum mit Szenarien. Die wichtigsten wurden bereits in Abschnitt 1.2. beschrieben (Qualitätsziele).

An dieser Stelle können auch Qualitätsanforderungen des dqualizer mit geringerer Priorität festhalten, die bei Nichterfüllung keine hohen Risiken verursachen.

Motivation: Da Qualitätsanforderungen[3] einen großen Einfluss auf Architekturentscheidungen haben werden, sollten Sie für jeden Stakeholder wissen, was für ihn wirklich wichtig, konkret und messbar ist.

14.1. Qualitätsbaum

Inhalt: Der Qualitätsbaum (wie in ATAM - Architecture Tradeoff Analysis Method - definiert) mit Qualitäts-/Bewertungsszenarien als Blätter.

Motivation: Die Baumstruktur mit Prioritäten gibt einen Überblick über eine manchmal große Anzahl von Qualitätsanforderungen.

Der Form nach ist ein Qualitätsbaum eine High-Level-Übersicht über die Qualitätsziele und -anforderungen:

  • Baumartige Verfeinerung des Begriffs "Qualität". Verwendung von "Qualität" oder "Nützlichkeit" als Wurzel

  • Eine Mindmap mit Qualitätskategorien als Hauptästen

In jedem Fall sollte der Baum Links zu den Szenarien des hier folgenden Abschnitts enthalten.

14.2. Qualitätsszenarien

Inhalt: Konkretisierung der (manchmal vagen oder impliziten) Qualitätsanforderungen durch (Qualitäts-)Szenarien. Diese Szenarien beschreiben, was passieren soll, wenn ein Stimulus am System ankommt.

Für Architekten sind zwei Arten von Szenarien wichtig:

  • Nutzungsszenarien (auch Anwendungsszenarien oder Use-Case-Szenarien genannt) beschreiben die Reaktion des Systems zur Laufzeit auf einen bestimmten Stimulus. Dazu gehören auch Szenarien, die die Effizienz oder Leistung des Systems beschreiben. Beispiel: Das System reagiert auf die Anfrage eines Benutzers innerhalb einer Sekunde.

  • Änderungsszenarien beschreiben eine Modifikation des Systems oder seiner unmittelbaren Umgebung. Beispiel: Zusätzliche Funktionalität wird implementiert oder die Anforderungen an ein Qualitätsmerkmal ändern sich.

Die Motivation hierfür lässt sich dabei wie folgt beschreiben: Szenarien machen Qualitätsanforderungen konkret und erlauben es, leichter zu messen oder zu entscheiden, ob sie erfüllt werden.

Insbesondere wenn Sie Ihre Architektur mit Methoden wie ATAM bewerten wollen, müssen Sie Ihre Qualitätsziele (aus Abschnitt 1.2) bis auf eine Ebene von Szenarien präzisieren, die diskutiert und bewertet werden können.

Form: Tabellarisch oder als Freitext.

15. Risiken und technische Schulden

Für den Inhalt empfiehlt das arc42 Template eine nach Priorität geordnete Liste der identifizierten technischen Risiken oder technischen Schulden.

"Risikomanagement ist Projektmanagement für Erwachsene" (Tim Lister, Atlantic Systems Guild.)

Dies sollte Ihre Devise für die systematische Erkennung und Bewertung von Risiken und technischen Schulden in der Architektur sein, die von Managementbeteiligten (z.B. Projektmanagern, Produktverantwortlichen) als Teil der allgemeinen Risikoanalyse und Messplanung benötigt werden.

Form nach arc42: Auflistung der Risiken und/oder technischen Schulden, wahrscheinlich einschließlich vorgeschlagener Maßnahmen zur Minimierung, Abschwächung oder Vermeidung von Risiken oder zur Verringerung technischer Schulden.

Notiz: Evtl. lassen sich techn. Risiken aus dem Projektvorhaben ableiten. Angesprochen wird u.a. das Scheitern durch Komplexität der Aufgabe (hinsichtlich nicht eingehaltener Deadlines).

Bekannte Probleme

Bekannte Probleme Beschreibung Link zu Details

<Text>

<Text>

<Text>

<Text>

<Text>

<Text>

Bekannte Risiken

Bekannte Risiken Beschreibung Link zu Details

<Text>

<Text>

<Text>

<Text>

<Text>

<Text>

Technische Schulden

Technische Schulden Beschreibung Link zu Details

<Text>

<Text>

<Text>

<Text>

<Text>

<Text>

16. Glossar

Begriff Definition

Runtime Quality Analysis (RQA)

We refer to RQA as the general process of analyzing a software system to evaluate its runtime qualities, e.g., performance or resilience. The term does not imply how the RQA is specified (format) or executed.

Runtime Quality Analysis Test (RQA Test)

An RQA test is a concrete specification of an RQA, meaning that it contains all the information to be executed. It can either be described on the domain or technical levels, i.e., it subsumes the terms RQA definition and RQA configuration.

Runtime Quality Analysis Definition (RQA Definition)

The RQA definition is a dqualizer-specific term. The RQA definition is an RQA test described on the domain level in the dqualizer-specific format.

Runtime Quality Analysis Configuration (RQA Configuration)

The RQA configuration is a dqualizer-specific term. The RQA configuration is an RQA test described on the technical level in the dqualizer-specific format. It is the translation of an RQA definition. It can still be abstract and does not have to be tool-specific.

Runtime Quality Analysis Results (RQA Results)

The result of running an RQA, i.e., (technical) metrics and traces collected during monitoring or experiment execution.

Runtime Quality Analysis Domain Results (RQA Domain Results)

These RQA results have been post-processed and translated to the domain-level to answer a question by a domain expert associated with the RQA.

Domain-Architecture-Mapping (DAM)

Describes how DDD elements - e.g., actors, work objects, and activities - are mapped to (technical) architecture elements - e.g., servers and endpoints - and vice versa.

Domain Expert

Persons that are familiar with the business domain that is handled by the software system (under test), e.g., product owners and users,

Technical Expert

Persons that are familiar with the technical details of the software system (under test), e.g., architects and DevOps engineers.

DST File

A file format for Domain Stories exported from the state-of-the-art domain story modeler https://egon.io/.

Stress Testing

Stress testing exercises software at the maximum design load, as well as beyond it, with the goal of determining the behavioral limits, and to test defense mechanisms in critical systems. (vgl. SWEBOK-V3)

Technical debt

The term is understood here as a common metaphor for the possible consequences of poor technical implementation of software. Postponing measures to ensure and increase technical quality (i.e. technical debt) in software projects does not accelerate software development, but slows it down and makes it more difficult.

Begriff 3

<Definition-3>
1. Document: "Domain-centered runtime quality analysis of business-critical application systems"
2. Dokument: "Domänenzentrierte Laufzeitqualitätsanalyse geschäftskritischer Anwendungssysteme"
3. https://docs.arc42.org/section-10/