CARDS+

Tag: Entscheidung

Entwicklungsprozess mit CARDS+ verifizieren

Die Organisation muss Steuerungsmaßnahmen für den Entwicklungsprozess anwenden, um sicherzustellen, dass Verifizierungstätigkeiten durchgeführt werden, um sicherzustellen, dass die Entwicklungsergebnisse die in den Entwicklungseingaben enthaltenen Anforderungen erfüllen.
ISO 9001, Kapitel 8.3

Continue reading

Was beschreibt der Baustein Spec?

Agile Software-Entwicklung hat uns von einigen Zwängen der phasen-orientierten Prozesse befreit.

  • Wir müssen nicht mehr alles zu Beginn des Projektes wissen. Wir dürfen miteinander und voneinander lernen.
  • Wir haben keine getrennten Teams für Analyse, Entwicklung und Test. Wir lieben selbstorganisierte cross-funktionale Teams.
  • Niemand muss in einer Software-Fabrik arbeiten. Wir reden miteinander und entwickeln das unserer Meinung beste Produkt.

Trotzdem gibt es in agilen Prozessen den Bedarf für Anforderungsanalyse, Stakeholder-, Architektur- und Lizenzmanagent, auf jeden Fall in großen Unternehmen. Eine agile Projektorganisation bewegt sich immer in einem Spannungsfeld zwischen Selbstorganisation der Entwickler, verbunden mit der vollständigen Kontrolle über die Implementierung ihrer Komponenten, und der Einschränkung der Vielfalt der Lösung aufgrund übergreifender Ziele, internationaler Normen oder unternehmensweiter Vorgaben. Immer kontrovers!

Continue reading

Was beschreibt der Baustein Domain?

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.

Continue reading

Was beschreibt der Baustein Entity?

Unabhängig vom Architekturstil gibt es in jedem System Fachklassen bzw. ganz allgemein Informationsobjekte. Diese Objekte sind Datenspeicher (“etwas, das existiert”) oder repräsentieren einen aktuellen Zustand im System. Ein Informationsobjekt ist häufig mit einer Identität verbunden. Jede Software hat zum Ziel, Probleme innerhalb eines Fachgebiets – der Domäne – für ihre Nutzer zu lösen. Beim Domain-Driven Design (kurz DDD) geht es nicht nur um die technische Umsetzung, sondern auch um unsere Denkweise beim Entwurf des Systems. DDD zusammen mit CARDS+ eröffnet weitere Optionen. Informationsobjekte (Entity und Aggregate) aus dem DDD sind eine ideale Ergänzung zum entsprechenden Begriff im Glossar. Das ist immens wichtig für die Bildung eines gemeinsamen Vokabulars im Projekt. Die gemeinsame Sprache ist ein wichtiges Ziel von CARDS+ und DDD.

Spannend ist noch die Frage, ob wir bei der Implementierung des Domänenmodells die Begriffe ins Englische (der lingua franca der Entwickler) übersetzen sollen. Meine persönliche Empfehlung ist, keinen Begriff der Domäne zu übersetzen. Eine Übersetzung ins Englische widerspricht der Idee, dass Entwickler und Domänenexperten die selbe Sprache sprechen.

Continue reading

Was beschreibt der Baustein Event?

Das reaktive Manifest ist der Versuch, die Werte für einen Architekturstil zu definieren, der das Ziel verfolgt, robuste, fehlertolerante und gut skalierbare Systeme zu schaffen. Nachrichten-orientierte Kommunikation zwischen den Diensten ist ein weiteres wichtiges Ziel dieses Architekturstils. Viele dieser Ziele erreichen wir durch die Nutzung moderner Technologien für die Nachrichtenverteilung, z.B. Kafka oder RabbitMQ, und Nachrichtenverarbeitung, z.B. Storm oder Flink.

Nachrichten sind ein wesentlicher Bestandteil der Schnittstelle solcher Dienste. Wie bei jeder anderen Schnittstelle machen wir uns vor der Entwicklung Gedanken, wie wir sie gestalten, technisch und fachlich. Bei Nachrichten legen wir fest, welche Eigenschaften so eine Nachricht hat. Nachrichten nutzen wir, um einen aktuellen Zustand oder eine Veränderung eines Zustandes zu melden. Nachrichten werden gruppiert (z.B. nach Ort oder Zeit), können zu größeren Nachrichten aggregiert oder in viele kleine Nachrichten zerlegt werden. Manche Nachrichten haben eine Gültigkeit und werden verworfen, wenn sie veraltet sind.

Continue reading

Was beschreibt der Baustein Service?

Lange Zeit haben wir große monolithische Systeme gebaut. Auch wenn der Ruf dieses Architekturstils nicht mehr der Beste ist, funktionieren manche diese Systeme doch seit vielen Jahren und erfüllen ihre Aufgabe zur vollen Zufriedenheit der Nutzer. Mit der Idee eines Microservice hat sich ein neuer Ansatz durchgesetzt. Dieser Architekturstil wird oft als Nachfolger der service-orientierten Architektur (kurz SOA) bezeichnet. Beide Architekturstile führen zu verteilten Systemen. Ein System aus vielen verschiedenen Microservices zusammenzustellen eröffnet vor allem hinsichtlich Robustheit und Skalierbar völlig neue Optionen. Microservices haben den großen Vorteil, dass es mit Technologien wie Spring Boot, Ratpack oder Dropwizard möglich ist, leichtgewichtige Lösungen zu bauen. Im reaktiven Manifest wird ein nachrichten-orientierter Architekturstil definiert, der ideal zu den Technologien aus dem Apache-Universum passt. Verteilte Verarbeitung von Datenströmen quasi in Echtzeit ist mit Storm, Spark oder Flink in Verbindung mit Kafka realisierbar.

Unabhängig vom Architekturstil besteht jedes System aus Diensten. Ein Microservice ist ein ein Dienst. In einem nachrichten-orientierten System mit Storm ist eine Topologie ein Dienst. Aber auch in monolithischen Systemen lassen sich Dienste identifizieren und realisieren.

Continue reading

Der “last responsible moment” ist der richtige Zeitpunkt für eine Entscheidung. Er ist so spät wie möglich, aber so früh wie nötig.

Continue reading

Was beschreibt der Baustein Decision?

In unserer schnelllebigen Zeit, wo technische Lösungen in kurzer Zeit entstehen und nach wenigen Jahren durch noch bessere Lösungen ersetzt werden, ist es besonders wichtig, die Gründe für die Wahl einer Technologie zu kennen. Streaming-Technologien wie Storm oder Spark bekommen gerade Konkurrenz durch das aufstrebende Flink. Auch im Bereich der No-Sql-Datenbanken gibt es mit HBase, Cassandra, Redis, PostgreSQL, MongoDB und CouchDB eine Vielzahl von Optionen. Und wer kann heute schon sagen, ob nicht auch die Konzepte des “machine learning” nicht bald zum Standardbaukasten einer modernen cloud-basierten Software-Architektur gehören.

Continue reading

Der Prozess des Architekturentwurfs umfasst eine Folge strategischer Entscheidungen, während der Gegenstand schlicht das Ergebnis dieses Prozesses darstellt.
Michael Stal

Copyright © 2018 Impressum Datenschutz

Zum Anfang ↑