Software Design vs. Software Architecture [geschlossen]

Könnte jemand den Unterschied zwischen Software-Design und Software-Architektur erklären?

Genauer; Wenn Sie jemandem sagen, er solle Ihnen das „Design“ präsentieren - was würden Sie von ihm erwarten? Gleiches gilt für "Architektur".

Mein derzeitiges Verständnis ist:

• Design: UML-Diagramm / Flussdiagramm / einfache Drahtmodelle (für die Benutzeroberfläche) für ein bestimmtes Modul / einen bestimmten Teil des Systems
• Architektur: Komponentendiagramm (zeigt, wie die verschiedenen Module des Systems miteinander und mit anderen Systemen kommunizieren), welche Sprache verwendet werden soll, Muster ...?

Korrigiere mich, wenn ich falsch liege. Ich habe darauf verwiesen, dass Wikipedia Artikel auf http://en.wikipedia.org/wiki/Software_design und http://en.wikipedia.org/wiki/Software_architecture hat, bin mir aber nicht sicher, ob ich sie richtig verstanden habe.

Du hast ja recht. Die Architektur eines Systems ist sein "Skelett". Es ist die höchste Abstraktionsebene eines Systems. Welche Art von Datenspeicherung ist vorhanden, wie interagieren Module miteinander, welche Wiederherstellungssysteme sind vorhanden. Genau wie bei Entwurfsmustern gibt es Architekturmuster: MVC, 3-Tier-Layered-Design usw.

Beim Software-Design geht es darum, die einzelnen Module / Komponenten zu entwerfen. Was sind die Verantwortlichkeiten, Funktionen des Moduls x? Von Klasse Y? Was kann es und was nicht? Welche Entwurfsmuster können verwendet werden?

Kurz gesagt, bei der Softwarearchitektur geht es mehr um das Design des gesamten Systems, während sich das Softwaredesign auf die Ebene der Module / Komponenten / Klassen konzentriert.

In einigen Beschreibungen des SDLC (Software Development Life Cycle) sind sie austauschbar, aber der Konsens ist, dass sie unterschiedlich sind. Sie sind gleichzeitig: verschiedene (1) Phasen , (2) Verantwortungsbereiche und (3) Entscheidungsebenen .

• Architektur ist das Gesamtbild: die Auswahl von Frameworks, Sprachen, Umfang, Zielen und Methoden auf hoher Ebene ( Rational , Wasserfall , Agilität usw.).
• Design ist das kleinere Bild: der Plan, wie Code organisiert wird; wie die Verträge zwischen verschiedenen Teilen des Systems aussehen werden; die fortlaufende Umsetzung der Methoden und Ziele des Projekts. Die Spezifikationen werden in dieser Phase geschrieben.

Diese beiden Phasen scheinen aus verschiedenen Gründen miteinander zu verschmelzen.

1. Kleinere Projekte haben oft nicht genug Spielraum, um die Planung in Phasen zu unterteilen.
2. Ein Projekt kann Teil eines größeren Projekts sein, und daher sind Teile beider Phasen bereits entschieden. (Es gibt bereits vorhandene Datenbanken, Konventionen, Standards, Protokolle, Frameworks, wiederverwendbaren Code usw.)
3. Neuere Denkweisen über die SDLC (siehe Agile Methoden ) ordnen diesen traditionellen Ansatz etwas neu. Design (in geringerem Maße Architektur) findet im gesamten SDLC statt absichtlich . Es gibt oft mehr Iterationen, bei denen der gesamte Prozess immer wieder abläuft.
4. Die Softwareentwicklung ist ohnehin kompliziert und schwer zu planen, aber Kunden / Manager / Verkäufer erschweren dies normalerweise, indem sie Ziele und Anforderungen im laufenden Betrieb ändern. Design und sogar architektonische Entscheidungen müssen später im Projekt getroffen werden, ob dies der Plan ist oder nicht.

Selbst wenn die Phasen oder Verantwortungsbereiche miteinander verschmelzen und überall stattfinden, ist es immer gut zu wissen, auf welcher Ebene Entscheidungen getroffen werden. (Wir könnten ewig so weitermachen. Ich versuche, eine Zusammenfassung zu erstellen.) Ich werde mit folgendem Schluss kommen: Auch wenn es so aussieht, als ob Ihr Projekt keine formale Architektur- oder Entwurfsphase / AOR / Dokumentation hat, passiert es, ob es jemand ist bewusst tun oder nicht. Wenn sich niemand für Architektur entscheidet, passiert ein Standard, der wahrscheinlich schlecht ist. Das Gleiche gilt für das Design. Diese Konzepte sind fast wichtiger, wenn es keine formalen Stufen gibt, die sie repräsentieren.

Architektur ist strategisch, während Design taktisch ist.

Die Architektur umfasst die Frameworks, Tools, Programmierparadigmen, komponentenbasierten Software-Engineering-Standards und Prinzipien auf hoher Ebene.

Während Design eine Aktivität ist, die sich mit lokalen Einschränkungen wie Entwurfsmustern, Programmiersprachen und Refactorings befasst.

Ich fand dies, als ich selbst nach einer einfachen Unterscheidung zwischen Architektur und Design suchte;
Was halten Sie von dieser Sichtweise:

• Architektur ist "was" wir bauen;
• Design ist "wie" wir bauen;

1. Architektur bedeutet die konzeptionelle Struktur und logische Organisation eines Computers oder eines computergestützten Systems.

   Design bedeutet einen Plan oder eine Zeichnung, die erstellt wurde, um das Aussehen und die Funktion oder Funktionsweise eines Systems oder eines Objekts zu zeigen, bevor es erstellt wird.

2. Wenn Sie eine Komponente „architektonisieren“, definieren Sie, wie sie sich im größeren System verhält.

   Wenn Sie dieselbe Komponente „entwerfen“, definieren Sie, wie sie sich intern verhält.

Alle Architektur ist Design, aber NICHT alles Design ist Architektur.

WhatTeil ist das Design, das Howist die konkrete Umsetzung und der Schnittpunkt von Whatund Howist Architektur.

Bild zur Unterscheidung von Architektur und Design :

Es gibt auch Entwurfsentscheidungen, die architektonisch nicht bedeutsam sind, dh nicht zum Architekturzweig des Entwurfs gehören. Zum Beispiel die internen Entwurfsentscheidungen einiger Komponenten, wie die Auswahl des Algorithmus, die Auswahl der Datenstruktur usw.

Jede Entwurfsentscheidung, die außerhalb ihrer Komponentengrenze nicht sichtbar ist, ist der interne Entwurf einer Komponente und nicht architektonisch. Dies sind die Entwurfsentscheidungen, die ein Systemarchitekt nach Ermessen des Moduldesigners oder des Implementierungsteams treffen würde, solange sein Entwurf nicht die durch die Architektur auf Systemebene auferlegten architektonischen Einschränkungen verletzt.

Der Link, der eine gute Analogie gibt

Ich würde sagen, Sie haben Recht, in meinen eigenen Worten;

Architektur ist die Zuordnung von Systemanforderungen zu Systemelementen. Vier Aussagen zu einer Architektur:

1. Es kann nicht funktionale Anforderungen wie Sprache oder Muster einführen.
2. Es definiert die Interaktion zwischen Komponenten, Schnittstellen, Timing usw.
3. Es soll keine neue Funktionalität einführen,
4. Es ordnet die (entworfenen) Funktionen, die das System ausführen soll, Elementen zu.

Architektur ist ein wesentlicher technischer Schritt wenn eine Komplexität des Systems unterteilt wird.

Beispiel: Denken Sie an Ihr Haus. Sie benötigen keinen Architekten für Ihre Küche (nur ein Element), aber das gesamte Gebäude benötigt einige Interaktionsdefinitionen wie Türen und ein Dach .

Design ist eine informative Darstellung der (vorgeschlagenen) Implementierung der Funktion. Es soll Feedback einholen und mit Stakeholdern diskutieren. Dies ist möglicherweise eine gute Praxis, aber kein wesentlicher technischer Schritt .

Es wäre schön, das Küchendesign zu sehen, bevor die Küche installiert wird, aber es ist nicht wesentlich für die Kochanforderung :

Wenn ich darüber nachdenke, können Sie sagen:

• Architektur ist für eine Öffentlichkeit / Ingenieure auf einer detaillierteren Abstraktionsebene
• Design ist für die Öffentlichkeit auf einer weniger detaillierten Abstraktionsebene gedacht

Meine Erinnerung:

• Wir können das Design ändern, ohne jemanden zu fragen
• Wenn wir die Architektur ändern, müssen wir sie jemandem (Team, Kunde, Stakeholder, ...) mitteilen.

Ich denke, wir sollten die folgende Regel verwenden, um zu bestimmen, wann wir über Design vs. Architektur sprechen: Wenn die Elemente eines von Ihnen erstellten Softwarebildes eins zu eins einer syntaktischen Konstruktion in einer Programmiersprache zugeordnet werden können, dann ist Design, wenn nicht Architektur.

Wenn Sie beispielsweise ein Klassendiagramm oder ein Sequenzdiagramm sehen, können Sie eine Klasse und ihre Beziehungen mithilfe der syntaktischen Konstruktion der Klasse einer objektorientierten Programmiersprache zuordnen. Das ist eindeutig Design. Darüber hinaus könnte dies dazu führen, dass diese Diskussion einen Bezug zu der Programmiersprache hat, die Sie zum Implementieren eines Softwaresystems verwenden. Wenn Sie Java verwenden, gilt das vorherige Beispiel, da Java eine objektorientierte Programmiersprache ist. Wenn Sie ein Diagramm erstellen, das Pakete und ihre Abhängigkeiten zeigt, ist dies auch Design. Sie können das Element (in diesem Fall ein Paket) einer syntaktischen Java-Konstruktion zuordnen.

Angenommen, Ihre Java-Anwendung ist in Module unterteilt, und jedes Modul besteht aus einer Reihe von Paketen (dargestellt als JAR-Datei-Bereitstellungseinheit). Anschließend wird ein Diagramm mit Modulen und ihren Abhängigkeiten angezeigt, dh Architektur. In Java gibt es keine Möglichkeit (zumindest nicht bis Java 7), ein Modul (eine Reihe von Paketen) einer syntaktischen Konstruktion zuzuordnen. Möglicherweise stellen Sie auch fest, dass dieses Diagramm einen höheren Abstraktionsgrad Ihres Softwaremodells darstellt. Jedes Diagramm über (grobkörniger als) einem Paketdiagramm stellt eine Architekturansicht dar, wenn es in der Programmiersprache Java entwickelt wird. Wenn Sie dagegen in Modula-2 entwickeln, repräsentiert ein Moduldiagramm ein Design.

(Ein Fragment von http://www.copypasteisforword.com/notes/software-architecture-vs-software-design )

Persönlich mag ich dieses:

"Der Designer befasst sich mit dem, was passiert, wenn ein Benutzer einen Knopf drückt, und der Architekt befasst sich mit dem, was passiert, wenn zehntausend Benutzer einen Knopf drücken."

SCEA for Java ™ EE-Studienhandbuch von Mark Cade und Humphrey Sheil

Ich stimme vielen Erklärungen zu; Im Wesentlichen erkennen wir den Unterschied zwischen dem architektonischen Design und dem detaillierten Design der Softwaresysteme.

Während das Ziel des Designers darin besteht, die Spezifikationen so präzise und konkret zu gestalten, wie es für die Entwicklung erforderlich ist; Der Architekt zielt im Wesentlichen darauf ab, die Struktur und das globale Verhalten des Systems so genau zu spezifizieren, wie es für den detaillierten Entwurf erforderlich ist.

Ein guter Architekt wird Hyperspezifikationen verhindern - die Architektur darf nicht übermäßig spezifiziert werden, sondern nur genug, um die (architektonischen) Entscheidungen nur für die Aspekte zu treffen, die die teuersten Risiken darstellen, und um effektiv einen Rahmen ("Gemeinsamkeit") bereitzustellen, innerhalb dessen die Es kann an einem detaillierten Design gearbeitet werden, dh an der Variabilität der lokalen Funktionalität.

In der Tat folgt der Architekturprozess oder Lebenszyklus nur diesem Thema - eine angemessene Abstraktionsebene, um die Struktur für die (architektonisch) signifikanten Geschäftsanforderungen zu skizzieren und mehr Details der Entwurfsphase für konkretere Ergebnisse zu überlassen.

Architektur ist Design, aber nicht alles Design ist Architektur. Streng genommen wäre es daher sinnvoller, zwischen architektonischem und nicht-architektonischem Design zu unterscheiden . Und was ist der Unterschied? Es hängt davon ab, ob! Jeder Softwarearchitekt kann eine andere Antwort haben (ymmv!). Wir entwickeln unsere Heuristiken, um eine Antwort zu finden, z. B. "Klassendiagramme sind Architektur und Sequenzdiagramme sind Design". Weitere Informationen finden Sie im DSA-Buch .

Es ist üblich zu sagen, dass Architektur auf einer höheren Abstraktionsebene liegt als Design, oder Architektur ist logisch und Design ist physisch. Aber dieser Begriff, obwohl allgemein akzeptiert, ist in der Praxis nutzlos. Wo ziehen Sie die Grenze zwischen hoher oder niedriger Abstraktion, zwischen logischer und physischer? Es hängt davon ab, ob!

Mein Vorschlag lautet also:

• Erstellen Sie ein einzelnes Designdokument.
• Benennen Sie dieses Designdokument so, wie Sie es möchten, oder besser so, wie es die Leser gewohnt sind. Beispiele: "Software-Architektur", "Software-Design-Spezifikation".
• Teilen Sie dieses Dokument in Ansichten auf und denken Sie daran, dass Sie eine Ansicht als Verfeinerung einer anderen Ansicht erstellen können.
• Machen Sie die Ansichten im Dokument navigierbar, indem Sie Querverweise oder Hyperlinks hinzufügen
• Dann haben Sie übergeordnete Ansichten mit einem breiten, aber flachen Überblick über das Design und Ansichten, die näher an der Implementierung liegen und enge, aber tiefere Designdetails zeigen.
• Vielleicht möchten Sie sich ein Beispiel für ein Architekturdokument mit mehreren Ansichten ansehen ( hier ).

Abgesehen davon ... ist eine relevantere Frage, die wir stellen müssen: Wie viel Design ist genug? Das heißt, wann sollte ich aufhören, das Design zu beschreiben (in Diagrammen oder Prosa) und mit der Codierung fortfahren?

Ja, das klingt für mich richtig. Das Design ist das, was Sie tun werden, und Architektur ist die Art und Weise, wie die Teile des Designs miteinander verbunden werden. Es könnte sprachunabhängig sein, würde aber normalerweise die zu verwendenden Technologien angeben, z. B. LAMP v Windows, Web Service v RPC.

Die Softwarearchitektur eines Programms oder Computersystems ist die Struktur oder Strukturen des Systems, die Softwarekomponenten, die von außen sichtbaren Eigenschaften dieser Komponenten und die Beziehungen zwischen ihnen umfassen.

(aus Wikipedia, http://en.wikipedia.org/wiki/Software_architecture )

Software-Design ist ein Prozess zur Problemlösung und Planung einer Softwarelösung. Nachdem der Zweck und die Spezifikationen der Software festgelegt wurden, entwerfen oder beschäftigen Softwareentwickler Designer, um einen Plan für eine Lösung zu entwickeln. Es enthält Probleme bei der Implementierung von Komponenten und Algorithmen auf niedriger Ebene sowie die Architekturansicht.

(aus Wikipedia, http://en.wikipedia.org/wiki/Software_design )

Hätte ich nicht besser sagen können :)

Ich betrachte Architektur wie Patrick Karcher - das große Ganze. Sie können beispielsweise die Architektur eines Gebäudes bereitstellen, die strukturelle Unterstützung, die Fenster, Ein- und Ausgänge, die Wasserableitung usw. anzeigen. Sie haben jedoch die Grundrisse, Kabinenpositionen usw. nicht "entworfen".

Während Sie das Gebäude entworfen haben, haben Sie nicht das Layout jedes Büros entworfen. Ich denke, dasselbe gilt für Software.

Sie können das Entwerfen des Layouts jedoch als "Architektur des Layouts" anzeigen ...

Gute Frage ... Obwohl die Linie zwischen ihnen kaum eine helle, scharfe Linie ist, umfasst Architektur, wenn Sie beide Begriffe verwenden, eher technische oder strukturelle Entscheidungen darüber, wie etwas gebaut oder konstruiert werden soll, insbesondere solche Entscheidungen, die schwierig sein werden ( oder schwieriger) zu ändern, sobald sie implementiert sind, während Design diejenigen Entscheidungen umfasst, die entweder später leicht zu ändern sind (wie Methodennamen, Organisationsstruktur der Klassendatei, Entwurfsmuster, ob ein Singleton oder eine statische Klasse zur Lösung eines bestimmten Problems verwendet werden soll) usw.) und / oder solche, die das Erscheinungsbild oder die ästhetischen Aspekte eines Systems oder einer Anwendung beeinflussen (Benutzeroberfläche, Benutzerfreundlichkeit, Erscheinungsbild usw.)

Software - Architektur ist „mit Fragen besorgt ... über die Algorithmen und Datenstrukturen der Berechnung.

Bei Architektur geht es speziell nicht um… Details von Implementierungen (z. B. Algorithmen und Datenstrukturen). Architekturdesign umfasst eine umfangreichere Sammlung von Abstraktionen als dies normalerweise bei OOD der Fall ist “(objektorientiertes Design).

Design befasst sich mit der Modularisierung und den detaillierten Schnittstellen der Designelemente, ihren Algorithmen und Verfahren sowie den Datentypen, die zur Unterstützung der Architektur und zur Erfüllung der Anforderungen erforderlich sind.

"Architektur" wird oft nur als Synonym für "Design" verwendet (manchmal mit dem Adjektiv "High-Level"). Und viele Menschen verwenden den Begriff „Architekturmuster“ als Synonym für „Designmuster“.

Schauen Sie sich diesen Link an.

Definieren der Begriffe Architektur, Design und Implementierung

Architektur:
Strukturentwurfsarbeiten auf höheren Abstraktionsebenen, die technisch signifikante Anforderungen an das System realisieren. Die Architektur legt den Grundstein für die weitere Gestaltung.

Design:
Die Kunst, das, was die Architektur nicht tut, durch einen iterativen Prozess auf jeder Abstraktionsebene auszufüllen.

Ich mochte dieses Papier wirklich als Faustregel für die Trennung von Architektur und Design:

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

Es heißt die Intension / Locality-Hypothese. Aussagen über die Art der Software, die nicht lokal und intensiv sind, sind architektonisch. Lokale und intensive Aussagen sind Design.

... vor langer Zeit an einem weit entfernten Ort machten sich Philosophen Sorgen um die Unterscheidung zwischen dem einen und den vielen. In der Architektur geht es um Beziehungen, die viele erfordern. Architektur hat Komponenten. Beim Design geht es um Inhalte, die den einen erfordern. Design hat Eigenschaften, Qualitäten, Eigenschaften. Wir denken normalerweise, dass Design innerhalb der Architektur liegt. Dualistisches Denken gibt die Vielen als ursprünglich. Architektur gehört aber auch zum Design. Es ist alles, wie wir uns entscheiden, das zu sehen, was vor uns liegt - das eine oder die vielen.

Ziemlich subjektiv, aber meine Meinung:

Die Architektur Das Gesamtdesign des Systems, einschließlich Interaktionen mit anderen Systemen, Hardwareanforderungen, Gesamtkomponenten-Design und Datenfluss.

Design Die Organisation und der Ablauf einer Komponente im Gesamtsystem. Dies würde auch die API der Komponente für die Interaktion mit anderen Komponenten einschließen.

Die Softwarearchitektur wird am besten auf Systemebene verwendet, wenn Sie das Geschäft und die Funktionen, die durch höhere Architekturebenen identifiziert werden, in Anwendungen projizieren müssen.

In Ihrem Unternehmen geht es beispielsweise um "Gewinn und Verlust" für Händler, und Ihre Hauptfunktionen umfassen "Portfolio-Bewertung" und "Risikoberechnung".

Aber wenn ein Software-Architekt seine Lösung detailliert beschreibt, wird er Folgendes feststellen:

"Portfolio-Bewertung" kann nicht nur eine Anwendung sein. Es muss in überschaubaren Projekten wie:

• GUI
• Startprogramm
• Dispatcher
• ...

(Da die damit verbundenen Vorgänge so umfangreich sind, müssen sie auf mehrere Computer aufgeteilt werden, während sie jederzeit über eine gemeinsame Benutzeroberfläche überwacht werden.)

Ein Software-Design untersucht die verschiedenen Anwendungen, ihre technische Beziehung und ihre internen Unterkomponenten.
Es werden die Spezifikationen erstellt, die für die letzte Architekturschicht (die "Technische Architektur") erforderlich sind (in Bezug auf technische Rahmenbedingungen oder transversale Komponenten) und für den Beginn der Projektteams (stärker auf die Implementierung der Geschäftsfunktionen ausgerichtet ) ihre jeweiligen Projekte.

Wenn jemand ein Schiff baut, sind Motor, Rumpf, Stromkreise usw. seine "architektonischen Elemente". Der Motorenbau wird für ihn "Konstruktionsarbeit" sein.

Wenn er dann den Aufbau des Motors an ein anderes Team delegiert, wird eine "Motorarchitektur" erstellt ...

Also - es kommt auf die Ebene der Abstraktion oder des Details an. Die Architektur einer Person könnte das Design einer anderen Person sein!

Architektur sind "die Entwurfsentscheidungen, die schwer zu ändern sind".

Nachdem ich mit TDD gearbeitet habe, was praktisch bedeutet, dass sich Ihr Design ständig ändert, hatte ich oft Probleme mit dieser Frage. Die obige Definition wurde aus Patterns of Enterprise Application Architecture extrahiert von Martin Fowler

Dies bedeutet, dass die Architektur von der Sprache, dem Framework und der Domäne Ihres Systems abhängt. Wenn Sie in 5 Minuten nur eine Schnittstelle aus Ihrer Java-Klasse extrahieren können, ist dies keine Entscheidung mehr für die Architektur.

Cliff Notes Version:

Design: Implementierung einer Lösung basierend auf den Spezifikationen des gewünschten Produkts.

Architektur: Die Grundlage / Tools / Infrastruktur / Komponenten, die Ihr Design unterstützen.

Dies ist eine ziemlich breite Frage, die viele Antworten hervorrufen wird.

Architektur ist die resultierende Sammlung von Entwurfsmustern zum Aufbau eines Systems.

Ich denke, Design ist die Kreativität, die verwendet wird, um all dies zusammenzustellen?

Software-Design hat eine längere Geschichte, während der Begriff Software-Architektur kaum 20 Jahre alt ist. Daher leidet es gerade unter wachsenden Schmerzen.

Akademiker neigen dazu, Architektur als Teil des größeren Bereichs des Software-Designs zu betrachten. Obwohl zunehmend anerkannt wird, dass Arch ein eigenes Feld ist.

Praktiker neigen dazu, Arch als Entwurfsentscheidungen auf hoher Ebene zu betrachten, die strategisch sind und deren Rückgängigmachung in einem Projekt kostspielig sein kann.

Die genaue Linie zwischen Arch und Design hängt von der Software-Domäne ab. Beispielsweise gewinnt im Bereich der Webanwendungen die Schichtarchitektur derzeit am meisten an Beliebtheit (Biz-Logikschicht, Datenzugriffsschicht usw.). Die untergeordneten Teile dieses Bogens werden als Entwurf betrachtet (Klassendiagramme, Methodensignaturen usw.). ) Dies würde in den Bereichen eingebettete Systeme, Betriebssysteme, Compiler usw. unterschiedlich definiert.

Architektur ist ein hohes, abstraktes und logisches Design, während Software-Design ein detailliertes und physisches Design auf niedriger Ebene ist.

Siehe auch: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Ich mag Roy Thomas Fieldings Definition und Erklärung der Softwarearchitektur in seinem Artikel: Architekturstile und das Design netzwerkbasierter Softwarearchitekturen

Eine Softwarearchitektur ist eine Abstraktion der Laufzeitelemente eines Softwaresystems während einer bestimmten Phase seines Betriebs. Ein System kann aus vielen Abstraktionsebenen und vielen Betriebsphasen mit jeweils einer eigenen Softwarearchitektur bestehen.

Er betont "Laufzeitelemente" und "Abstraktionsebenen".

Es gibt keine endgültige Antwort darauf, da "Softwarearchitektur" und "Softwaredesign" eine Reihe von Definitionen haben und es auch keine kanonische Definition gibt.

Eine gute Denkweise ist die Aussage von Len Bass, Paul Clements und Rick Kazman, dass "jede Architektur Design ist, aber nicht alles Design Architektur" [Software Architecture in Practice]. Ich bin mir nicht sicher, ob ich damit einverstanden bin (weil Architektur andere Aktivitäten umfassen kann), aber es erfasst die Essenz, dass Architektur eine Entwurfsaktivität ist, die sich mit der kritischen Teilmenge des Entwurfs befasst.

Meine leicht flippige Definition (auf der Seite mit den SEI-Definitionen) ) lautet, dass es sich um eine Reihe von Entscheidungen handelt, die bei falscher Entscheidung dazu führen, dass Ihr Projekt abgebrochen wird.

Ein nützlicher Versuch, Architektur, Design und Implementierung als Konzepte zu trennen, wurde vor einigen Jahren von Amnon Eden und Rick Kazman in einem Forschungsbericht mit dem Titel "Architektur, Design, Implementierung" unternommen, der hier zu finden ist: http: //www.sei.cmu .edu / library / assets / ICSE03-1.pdf . Ihre Sprache ist ziemlich abstrakt, aber vereinfacht gesagt sagen sie, dass Architektur Design ist, das in vielen Kontexten verwendet werden kann und systemweit angewendet werden soll. Design ist (err) Design, das in vielen Kontexten verwendet werden kann, aber in einem bestimmten Teil angewendet wird des Systems und Implementierung ist ein kontextspezifisches Design, das in diesem Kontext angewendet wird.

Eine Architekturentscheidung könnte also eine Entscheidung sein, das System über Messaging anstelle von RPC zu integrieren (es ist also ein allgemeines Prinzip, das an vielen Stellen angewendet werden kann und auf das gesamte System angewendet werden soll). Eine Entwurfsentscheidung könnte darin bestehen, einen Master zu verwenden / Slave-Thread-Struktur im Eingabeanforderungsbehandlungsmodul des Systems (ein allgemeines Prinzip, das überall verwendet werden kann, in diesem Fall jedoch nur in einem Modul verwendet wird) und schließlich könnte eine Implementierungsentscheidung darin bestehen, die Sicherheitsverantwortung vom Anforderungsrouter zu verschieben an den Request Handler im Request Manager-Modul (eine Entscheidung, die nur für diesen Kontext relevant ist und in diesem Kontext verwendet wird).

Ich hoffe das hilft!