Software hat immer eine Struktur, unabhängig vom Architekturstil. Sind es bei monolithischen Systemen noch Schichten und Module, reden wir bei service- oder nachrichten-orientierten Systemen ganz allgemein von Diensten. Ein Dienst hat öffentliche Schnittstellen und eine Aufgabe. Schichten und Module werden zu Details der Implementierung eines Dienstes. Beim Domain-Driven Design (kurz DDD) nutzen wir den Begriff Module, um Ordnung und Übersichtlichkeit in ein Modell zu bringen. Ein weiterer Treiber für eine Struktur ist die Verwaltung von Code. Wir organisieren Code in Build-Projekten (z.B. mit gradle oder maven) und speichern Versionen davon in einem Code-Repository (z.B. git).

Kurz gesagt, es gibt eine ganze Reihe von Konzepten und Ansätzen, mit der wir eine Software strukturieren können. Ziel ist immer, die Komplexität der Software in den Griff zu bekommen, einen Überblick zu behalten.

Motivation

Mit dem Baustein Domain wollen wir die Struktur der Software beschreiben, weitestgehend unabhängig vom Architekturstil und Programmiersprache. Entwickler nutzen Konzepte der Programmiersprache für Namensräume, um Struktur in den Code zu bringen.

In Java definieren wir mit package einen Namensraum. Ein package ist eine Sammlung von interfaces, classes oder enums. Um Namenskonflikte aufzulösen, wenn es in zwei verschiedenen packages zwei identische Bezeichner gibt, sind sie in einer Hierarchie geordnet.

Java bietet eine weitere Möglichkeit, Code zu einer Einheit zusammenfassen. Die Grundlage bildet eine jar-Datei, die neben class-Dateien und Ressourcen auch Metadaten in Form einer manifest-Datei enthält. Es gibt allerdings auch Probleme bei der Verwendung komplexer classloader-Hierarchien mit war-, ear- und vielen weiteren Varianten von jar-Dateien, die oft als jar hell bezeichnet wird.

In C++ nutzen wir einen namespace, um Code zu einem Namensraum zusammen zu fassen.

In Python schreiben wir Skripte, die Code zu einem Namensraum zusammenfassen. Python nennt sie module. Python kennt auch das Konzept der packages, um ein module weiter zu strukturieren. Um Namenskonflikte aufzulösen, wenn es in zwei verschiedenen packages zwei identische Bezeichner gibt, haben packages eine Hierarchie.

Namensräume müssen wir im Wiki nicht ausführlich dokumentieren. Das wäre redundant. Es gibt außerdem für viele Programmiersprachen ein Werkzeug, das eine von Menschen lesbare Dokumentation aus dem Code erstellen kann. Die Dokumentation kann meist durch spezielle Kommentare im Code angereichert werden. So kann die Struktur von Code für jeden im Projekt sichtbar gemacht werden.

Javadoc ist ein Werkzeug, das aus Java-Code eine Dokumentation erstellt. Als Ausgabeformat unterstützt Javadoc nur HTML, durch doclets können aber weitere Ausgabeformate ergänzt werden.

Doxygen ist ein Werkzeug, das aus Code der Programmiersprachen C++, C, Objective-C, Java, Python, Fortran und IDL eine Dokumentation erstellt. Als Ausgabeformat unterstützt Doxygen z.B. HTML, LaTeX, XML, RTF, PostScript, PDF und Markdown.

CARDS+ bietet eine schöne Möglichkeit, alle für das Verständnis eines Systems notwendigen Bestandteile im Wiki zu erfassen. Mit dem Baustein Service geben wir einem konkreten Dienst einen eindeutigen Namen. Wir nutzen den Baustein Domain, um Dienste zu einer Gruppe in einem Code-Repository zusammenzufassen.

  • Der Name der Domain verwenden wir auch als Bezeichnung für das Code-Repository.
  • In der Beschreibung der Domain erklären wir das Zusammenspiel der Dienste.

Es ist ganz wichtig, dass wir das Wiki als Verzeichnis für Dienste sehen. Es ist eine große Chance, eine konsistentes und nachvollziehbares Schema für Namen durchzusetzen. Das funktioniert natürlich nur, wenn wir die Seiten im Wiki vor dem Start der Entwicklung erstellen und bis zum Abschluss der Implementierung laufend aktualisieren.

Während der Realisierung eines Dienstes treffen Entwickler Entscheidungen, die nur für diese Gruppe von Diensten gilt. Und die dokumentieren wird nicht mit dem Baustein Decision, sondern im Baustein Domain.

Weitere Quellen

Es gibt eine Reihe von Ansätzen, die Software-Architektur quasi als wissenschaftliche Disziplin betrachten, Kernaufgaben des Architekturentwurfs definieren und Vorlagen für die Dokumentation zur Verfügung stellen.

Zuerst erfasst man ein “Architecture Principle”, welches beispielsweise den Einsatz von Schichten erklärt (das “Statement”) mit seinen Randbedingungen (das “Rationale”) und Auswirkungen (die “Implications”).

Das Kapitel 35 mit dem Titel “Architectural Artifacts” zeigt die unzähligen Möglichkeiten für die Darstellung des Systems (“View”) aus einer bestimmten Perspektive (“Viewpoint”) für einen bestimmten Aspekt der Funktionsweise des Systems (“Concern”).

Quelle: TOGAF9 online documentation

In der Bausteinsicht wird die statische Zerlegung des Systems in Bausteine (Module, Komponenten, Subsysteme, Teilsysteme, Klassen, Interfaces, Pakete, Bibliotheken, Frameworks, Schichten, Partitionen, Tiers, Funktionen, Makros, Operationen, Datenstrukturen, …) sowie deren Beziehungen dokumentiert. Abhängig vom Architekturstil nutzen wir den Baustein Domain, um Module, Komponenten oder Schichten zu beschreiben.

Quelle: ARC42 online documentation

Definition

Beschreibung

Der Baustein Domain aggregiert zusammengehörige Dienste, Nachrichtenobjekte, Informationsobjekte und weitere fachlich relevante Elemente zu einem sinnvollen Ganzen.

Der Baustein Domain wird für Entwickler geschrieben.

Die Bausteine Domain und Topic sind unterschiedliche Sichten auf die Anwendung. Ein Topic beschreibt die Struktur der fachlichen Anforderungen während eine Domain die technische Struktur der Anwendung definiert.

Der Baustein Domain realisiert die erste fachliche Ebene des Komponentenschnittes.

Struktur

Abschnitt Beschreibung

Der Abschnitt enthält eine meistens sehr kurze Beschreibung, die im Wesentlichen die Idee des “sinnvollen Ganzen” vermittelt.

Ergänzen kann man den Abschnitt um eine Klassendiagramm zur Darstellung der wichtigsten Fachklassen innerhalb dieser Domain.

Abschnitt Untergeordnete Elemente

Der Abschnitt enthält eine einfache Auflistung aller weiteren Bausteine, die in dieser Domain gebündelt werden, z.B.

  • Baustein Service für Dienste.
  • Baustein Event für Nachrichtenobjekte.
  • Baustein Entity für Informationsobjekte.
  • Baustein Layout für Elemente der Benutzeroberfläche.

Um den Pflegeaufwand für diesen Baustein zu minimieren, wird eine automatische Auflistung der Unterseiten empfohlen.