Wichtigkeit von SW Architektur

[MrSpock]

In diesem Beitrag hat Holger die Wichtigkeit einer vorhandenen SW Architektur beschrieben. Ich hatte darauf geantwortet und einige weiterführende Fragen gestellt. Da es aber in dem dortigen Thread untergegangen ist, stelle ich die frage hier nochmal.

Zitat:

Zitat von IBExpert (Beitrag 1325919)

...
Das hat auch nichts mit einer Delphi Wohlfühlblase zu tun, wenn du eine Architektur als Backend hast ist, dann ist die Programmiersprache und IDE extrem austauschbar. Ohne Architektur machst du in der nächsten Welt viele Fehler wieder und hast nur den Teufel durch den Belzebub ersetzt.

Hallo Holger, ...

Eine Frage habe ich zur praktischen Anwendung der "Softwarearchitektur". Ich habe mich mit dem Thema Systemarchitektur schon oft auseinandergesetzt und kenne zum Beispiel den amerikanischen Verteidigungsstandard DoDAF zur Definition einer Architektur. Mich würde interessieren, wie ihr die Architektur definiert und nach Delphi bzw. Lazarus umgesetzt habt. Nutzt ihr UML, wenn ja, welches Tool und welche Ansichten. Beschränkt sich die Architektur auf Klassendiagramme oder geht sie darüber hinaus?

Neben dem Vorgehen von Holger, interessiert mich auch, wie andere professionelle Entwickler von Euch vorgehen, um eine SW Architektur zu beschreiben und zu entwickeln.

[AlexII]

Gute Frage, habe mich auch schon gefragt wie das gemacht wird. Da ich immer "ohne Plan" schreibe, und nach einem Jahr nicht mehr weiß, wie das ganze funktioniert.

[jobo]

Vor UML steht m.E. eine Sammlung von Anforderungen, die schon abhängig von der Projektart erhoben werden müssen.
- Kundenprojekt
- eigenes Produkt
- Neuentwicklung / Weiterentwicklung

Dann wäre zu klären, wie heterogen die Einsatzlandschaft ist und Nutzungsart. Jenachdem komme ich hier zu verteilten Systemen, Mehrschicht -, Zweischicht oder Monolith. Mehrschichtsysteme und verteilte laufen meist auf unterschiedlichen Architekturen. Unterschiedliche Architekturen haben unterschiedliche Anforderungen und Aufgaben. Daraus ergeben sich diverse Vorgaben, die das System erfüllen muss.
Diese Vorgaben gehen m.E. in Summe weit über eine funktionale bzw. fachliche Anforderung hinaus, sie betreffen auch Sicherheitsaspekte, Administration, Verfügbarkeit, Ressourcenbedarf, Kosten usw.

Damit kann man modellieren, z.B. in UML, BPMN, ..

Auch wenn es ja in einem solchen Prozess keine Umsetzungsentscheidungen geben soll. In der Realität ist das normal, von Unternehmenspolicies ala "nur MS Produkte mit Wartung / Support", über existierende Partnerschaften und eigene Produktlandschaften bis hin zu Entwickler und Know How Ressourcen bis was weiß ich. Diese Themen werden ebenso gesetzt

[Perlsau]

Unter Software-Architektur verstand ich bislang immer die Gestaltung der grundsätzlichen Arbeitsweise einer zu entwickelnden Anwendung. Dazu gehört erst einmal die Frage nach der Gestaltung der GUI, aber auch andere Fragen, z.B.:

• Wie soll das Ganze am Ende aussehen?
• Soll sich alles in einem Fenster abspielen?
• Arbeite ich mit Frames oder mit TabSheets?
• Lege ich Wert auf intuitive Bedienbarkeit?
• Wie gestalte ich die GUI so, daß sie für den Anwender übersichtlich bleibt?
• Setze ich auf einzubindende Module, die bei Bedarf zusätzlich erworben werden können?
• Setze ich mehr auf Menüsteuerung oder stehen Buttons und Toolbars im Vordergrund?
• Baue ich, um mit mehreren Dokumenten gleichzeitig umgehen zu können, eine MDI-Anwendung oder mache ich das wie bei MS-Word, daß für jedes Dokument die gesamte Anwendung wiederholt referenziert wird?
• Verwende ich kommerzielle Fremdkomponenten oder entwickle ich mir meine eigenen?

Das könnte man sicher noch um etliche Punkte ergänzen. Zur Software-Architektur gehört meiner Einschätzung nach aber auch die Frage, wie ich "intern" vorgehe:

• Habe ich überhaupt einen Plan oder programmiere ich eher "wild drauflos"?
• Arbeite ich direkt mit der Datenbank oder verwende ich Klassen (Objekte), um die Daten bereitzustellen und zu bearbeiten?
• Wie flexibel soll meine Anwendung hinsichtlich ihrer Verwendbarkeit sein? Z.B. bei Datenbank-Anwendungen mit Firebird: Wie gestalte ich die Anwendung so, daß sie wahlweise als StandAlone (Embedded-DB), als Serverversion mit lokalem oder Remote-Server einsetzbar ist?
• Welche Bereiche eines Projekts lagere ich in DLLs aus, so daß sie von anderen Projekten wieder verwendet werden können?
• Wie organisiere ich Units, um auch nach Jahren nahezu sofort den Überblick zu erhalten?
• Halte ich mich strikt an die Objektorientierung oder weiche ich bei Bedarf davon ab?
• Baue ich meine Anwendung modular auf und halte die Zuständigkeiten übersichtlich?

Derzeit präferiere ich die Arbeit mit Frames, die jeweils ein Modul darstellen und alle von einem Default-Frame abstammen, der bereits wichtige Methoden und Deklarationen enthält, die zur Verwaltung der Frames benötigt werden. Damit hab ich inzwischen mehrere Projekte absolviert, so daß ich diese Architektur mehr oder weniger verinnerlichen konnte. Damit habe ich nun eine Grund-Architektur für Projekte mit Frames, die als Vorlage für weitere Projekte dienen. Das verstehe ich unter Software-Architektur: Eine bestimmte Vorgehensweise, ein bestimmtes Konzept, bestimmte strikte Regeln, die eingehalten werden müssen und durch all das eine konkrete Linie, entlang der ein Projekt entwickelt wird.

[mkinzler]

Wobei das was Du "intern" nennst eigentlich das Wichtigere ist! Bzw. ein Teil davon, und vor Allem das, was Du vergessen hast.

Die UI ist in diesem Kontext unwichtig, bzw. gehört nur bedingt zur Architektur.

Zitat:

Habe ich überhaupt einen Plan oder programmiere ich eher "wild drauflos"?

Wild drauf los Programmieren verträgt sich nicht mit "Architektur", welche imho einen Plan bedingt.

• Einzelplatz;Client/Server;verteilt
• Fat/Thin Client
• ...

Zitat:

Arbeite ich direkt mit der Datenbank oder verwende ich Klassen (Objekte), um die Daten bereitzustellen und zu bearbeiten

Wenn man hierunter Bridgepattern o.ä versteht, könnte man das unter die Architektur stecken, sonst ist das ein Implementierungsdetail.

[Perlsau]

Zitat:

Zitat von mkinzler (Beitrag 1326254)

Wobei das was Du "intern" nennst eigentlich das Wichtigere ist! Bzw. ein Teil davon, und vor Allem das, was Du vergessen hast.

Nein, ich habe nichts vergessen, sondern lediglich beschrieben, was ich bislang unter Software-Architektur verstanden habe. Vergessen würde ja ein Wissen voraussetzen, das beim Wiedergeben übersehen wurde. Das ist hier nicht der Fall, denn ich weiß nicht mehr als das, was ich hier genannt habe. Auch möchte ich mich mit meinen Beitrag nicht unnötig wichtig machen, sondern habe lediglich auf die Frage von Albert geantwortet:

Zitat:

Zitat von MrSpock (Beitrag 1326229)

Neben dem Vorgehen von Holger, interessiert mich auch, wie andere professionelle Entwickler von Euch vorgehen, um eine SW Architektur zu beschreiben und zu entwickeln.

Natürlich könntest du jetzt entgegnen, ich sei kein professioneller Entwickler und gehöre daher nicht wirklich zur Zielgruppe. Diese Einschätzung bleibt dir überlassen ... Mich interessiert dieses Thema jedoch sehr, weshalb ich meine Definition des Begriffs hier darzustellen versucht habe.

Zitat:

Zitat von mkinzler (Beitrag 1326254)

Die UI ist in diesem Kontext unwichtig, bzw. gehört nur bedingt zur Architektur.

Das konnte ich der Definition bei Wikipedia nicht entnehmen, denn dort steht:

Eine Definition von Helmut Balzert beschreibt den Begriff als „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“. Die Architekturkomponenten bilden eine Zerlegung des Gesamtsystems, was bedeutet, dass jedes Softwareelement genau einer Architekturkomponente zugeordnet ist.
Paul Clements beschreibt Softwarearchitektur als „Strukturen eines Softwaresystems: Softwareteile, die Beziehungen zwischen diesen und die Eigenschaften der Softwareteile und ihrer Beziehungen“.
Die Softwarearchitektur ist Teil des Softwareentwurfs (siehe SWEBOK), innerhalb dessen sie als Grobgliederung der Komponenten entsteht. Während der Softwareentwurf sich auch auf lokale Aspekte innerhalb des architektonischen Rahmens der Software bezieht und deshalb sehr detailliert sein kann, ist die Softwarearchitektur eine globale Eigenschaft des Gesamtsystems.

Dennoch danke ich dir für deine Korrketur, denn nun muß ich in Betracht ziehen, daß die visuelle Gestaltung der Anwendung nicht Teil der Software-Architektur ist – falls deine Aussage zutrifft, was ich derzeit nicht wirklich beurteilen kann.

Zitat:

Zitat von mkinzler (Beitrag 1326254)

Zitat:

Habe ich überhaupt einen Plan oder programmiere ich eher "wild drauflos"?

Wild drauf los Programmieren verträgt sich nicht mit "Architektur", welche imho einen Plan bedingt.

Ganz ohne Plan kann niemand eine Anwendung programmieren. Anfänger – und dabei gehe ich auch von mir aus, denn ich war ja schließlich auch einmal Anfänger – haben meist nur einen groben Plan, was die Software können soll und wie sie das erreichen. Zudem ergibt sich auch aus einer mehr oder weniger planlos entwickelten Software eine Architektur. Die Architektur ist ja kein Qualitätsmerkmal, sondern eine Beschreibung der Zusammenhänge der verwendeten Komponenten. Da stellt sich natürlich die Frage, ab welcher "Auflösung" ein Plan als Software-Architektur verstanden werden kann. Muß eine Software-Architektur so viel umfassen bzw. so detailliert sein, daß man sie schriftlich festhalten muß?

Zitat:

Zitat von mkinzler (Beitrag 1326254)

Zitat:

Arbeite ich direkt mit der Datenbank oder verwende ich Klassen (Objekte), um die Daten bereitzustellen und zu bearbeiten

Wenn man hierunter Bridgepattern o.ä versteht, könnte man das unter die Architektur stecken, sonst ist das ein Implementierungsdetail.

Was sonst sollte man darunter verstehen? Bridgepattern bedeutet doch die Schicht zwischen Anzeige/Verarbeitung und Datenbank. Ich denke, daß hier eher die Art & Weise, wie ich die Klassen entwickle, zum Implementierungsteil gehört, die Entscheidung jedoch, ob ich die Daten über Klassen, also Objekte bereitstelle, zur Software-Architektur.

[DeddyH]

Mit den Komponenten sind die Teile (oder meinetwegen auch die beteiligten Module) der Software gemeint, das hat mit Delphi-Komponenten nichts zu tun.

[mm1256]

Hallo,

was mich bisher besonders irritiert ist diese Aussage aus dem anderen Thread:

Zitat:

Zitat von IBExpert (Beitrag 1325919)

Viele setzen zwar eine Pseudosoftwarearchitektur auf Basis von Delphi Klassen ein, die ist aber oft schon in jede 2. Zeile mit TDataset verheiratet, so das die auf anderen Plattformen so gar nicht mehr implementierbar sind.

Das hat auch nichts mit einer Delphi Wohlfühlblase zu tun, wenn du eine Architektur als Backend hast ist, dann ist die Programmiersprache und IDE extrem austauschbar. Ohne Architektur machst du in der nächsten Welt viele Fehler wieder und hast nur den Teufel durch den Belzebub ersetzt.

Architektur als Backend...wieso sind dann Programmiersprache und IDE "extrem austauschbar"? Also konkret: Welche Architektur-Merkmale oder -Eigenschaften müssen erfüllt sein, um diesen Austausch so "extrem" realisieren zu können? Das würde mich "extrem" interessieren.

[Perlsau]

Zitat:

Zitat von DeddyH (Beitrag 1326262)

Mit den Komponenten sind die Teile (oder meinetwegen auch die beteiligten Module) der Software gemeint, das hat mit Delphi-Komponenten nichts zu tun.

Das habe ich auch nicht vermutet, daß sich der Komponentenbegriff auf Delphi-Komponenten bezöge, denn schließlich ist die Software-Architektur nicht auf eine Programmiersprache begrenzt. Nun müßte man aus meiner Sicht erst einmal definieren, was denn Teile oder Module im Zusammenhang mit Software-Architektur sind, denn auch hier darf man wohl nicht davon ausgehen, daß sie mit implementierten Modulen gleichzusetzen wären. Wikipedia meint dazu:

Ein Modul ist eine abgeschlossene funktionale Einheit einer Software, bestehend aus einer Folge von Verarbeitungsschritten und Datenstrukturen. Inhalt eines Moduls ist häufig eine wiederkehrende Berechnung oder Bearbeitung von Daten, die mehrfach durchgeführt werden muss. Das Modul führt eine Reihe von Verarbeitungsschritten durch, liefert bei der Rückkehr an das aufrufende Programm Daten als Ergebnis zurück.

Dann wäre jede Funktion im Programm ein Modul? Oder zusammengehörende Methoden z.B. einer Klasse wären ein Modul? Was ich damit sagen will: Es ist schwer, solche abstrakten Modelle wie die Software-Architektur zu verstehen, wenn die in der Erläuterung verwendeten Begriffe nicht eindeutig definiert sind. Wenn ich versuche, mir das alles mit Wikipedia zu erschließen, begegnet mir eine zunehmende Anzahl solcher Begriffe, die ich wiederum nachschlagen muß und die dann zu noch mehr unbekannten bzw. undefinierten Begriffen führen. Immerhin finde ich in der Erklärung des Modulbegriffs nun wieder einen Bezug zur Software-Architektur:

Ein Aspekt der Softwarearchitektur ist die Herstellung von Unterprogrammen zur Verwendung in mehreren Computerprogrammen/-Anwendungen. Bestimmte technische oder betriebliche Funktionen (zum Beispiel eine Prüfziffernberechnung) können so beispielsweise unternehmensweit einheitlich genutzt werden.

Natürlich weiß ich nicht, inwieweit Wikipedia-Artikel von kompetenten IT-Fachleuten geschrieben wurden und ob sie dem aktuellen Stand entsprechen, aber ich gehe einmal davon aus, daß dem zumindest im wissenschaftlich-technischen Bereich so ist. Die Beschreibung der aktuellen Bedeutung von Software-Architektur sieht demnach so aus:

Die Beschreibung einer Softwarearchitektur enthält Informationen über die Struktur („Komponentisierung“) eines Software-Systems, aber auch Informationen über die Kommunikation zwischen Komponenten, sowie deren Abbildung auf Hardware- oder Software-Ressourcen (Verteilung und Deployment). Dabei kann eine Softwarearchitektur unterschiedliche Ausprägungen haben:

• So kann in einer Funktionsarchitektur (oder auch fachliche Architektur) die Gliederung des Systems in Funktionen oder Features dargestellt werden.
• In der Komponentenarchitektur wird der Grobentwurf des Systems in einzelne Komponenten festgehalten.
• Dieser Grobentwurf lässt sich im Feinentwurf feingranularer darstellen. Hierbei handelt es sich beispielsweise um Klassenhierarchien, Modularchitekturen oder programmiersprachenspezifischen Quelltext. Die Übergänge zwischen Feinentwürfen sind teilweise fließend.

Festzuhalten ist, dass es nicht die eine Softwarearchitektur eines System gibt. Es müssen je nach Fragestellung und Interessenspunkt unterschiedliche Sichten hinzugezogen werden. Ein Beispiel hierfür ist das 4+1 Sichtenmodell (schon wieder so ein Begriff).

[mjustin]

Zitat:

Zitat von mm1256 (Beitrag 1326266)

Architektur als Backend...wieso sind dann Programmiersprache und IDE "extrem austauschbar"? Also konkret: Welche Architektur-Merkmale oder -Eigenschaften müssen erfüllt sein, um diesen Austausch so "extrem" realisieren zu können? Das würde mich "extrem" interessieren.

"Architektur als Backend" ist nicht besonders selbsterklärend :) Ich verstehe es so, dass man im Backend eine sprachunabhängige Schnittstelle bereitstellt, mit der "das" Frontend (es können aber auch mehr als eins sein, z.B. ein mobiler Client, eine Web-Anwendung...) kommuniziert.

Diese sprachunabhängige Schnittstelle kann alle möglichen Ausprägungen haben - es kann eine simple Request/Response Web Service Schnittstelle sein (JSON über HTTP), oder ein Mix aus Kommunikationsmodellen (Broadcast, Publish/Subscribe ...).

"Extrem" einfach ist der Austausch, wenn die Schnittstelle nur Techniken und Protokolle verwendet die von allen gewünschten Entwicklungsumgebungen oder Sprachen weitgehend unterstützt werden. Ein Beispiel ist SOAP: wenn alle Werkzeuge in der Lage sind, eine WSDL-Datei (Web Service Definition) zu verstehen und daraus client- oder serverseitigen Sourcecode zu erzeugen, kann man SOAP einsetzen. Wenn man dann den Server austauschen will, kann man dies tun ohne an den Clients Änderungen vornehmen zu müssen.

[jobo]

Zitat:

Zitat von mm1256 (Beitrag 1326266)

Architektur als Backend...wieso sind dann Programmiersprache und IDE "extrem austauschbar"? Also konkret: Welche Architektur-Merkmale oder -Eigenschaften müssen erfüllt sein, um diesen Austausch so "extrem" realisieren zu können? Das würde mich "extrem" interessieren.

Ich vermute, dass eine "klassische" 3 Schicht Architektur gemeint ist. Also Datenschicht, (Business)Logik und die (austauschbare) Darsstellungs-/Anwenderschicht, realisierbar über Interfaces für Daten, Befehle, also Rest, SOAP usw..
Total beliebig ist es natürlich nicht, sondern man geht davon aus, dass backend seitig die Services oder Daten konform zu gewissen Standards bereitgestellt werden. Letztlich definiert sich genau der Nutzen der "Austauschbarkeit" und damit Unabhängigkeit und Flexibilität an den verwendeten Interfaces, die Anzahl der Schichten bzw. das konkrete Produkt ist dann eben egal. Zumindest in der Theorie, in der Praxis eben dann, wenn beide Seiten des Interfaces dieses auch vollständig und fehlerfrei bedienen.

Interface Beispiel IMAP, es interssiert niemanden, welcher Provider, welche Software serverseitig läuft und es interessiert genausowenig, welcher Client, welches ClientOS, .. die Daten abfragt, solange beide IMAP sprechen.

P.S: hab die Antwort von mjustin übersehen.

[Sir Rufo]

Sehr unterhaltsam und lesenswert dazu ist
http://blog.cleancoder.com/uncle-bob...hitecture.html

[mm1256]

Hallo,

vielen Dank euch Beiden für die Antworten. Dass damit die 3-Schicht-Architektur gemeint sein könnte, hab ich mir auch schon gedacht, war mir allerdings nicht sicher. Denn, daraus die "extreme" Austauschbarkeit der IDE bzw. der Programiersprache abzuleiten, halte ich persönlich für etwas gewagt.

Eine 3-Schicht-Architektur ist wohl nicht extenzielle Grundvoraussetzung für irgend ein popeliges Kleinprojekt. Wenn es folglich um größere Projekte geht, dann wird der Austausch der IDE bzw. der Programmiersprache - egal ob beim Front- oder Backend - schon eine echte Herausforderung, an welcher sich wahrscheinlich schon einige SW-Hersteller etwas "verhoben" haben.

EDIT: @SirRufo Jetzt hab ich etwas mehr Ahnung davon, warum Manager so viel Gutes tun

[mjustin]

Zitat:

Zitat von mm1256 (Beitrag 1326279)

Wenn es folglich um größere Projekte geht, dann wird der Austausch der IDE bzw. der Programmiersprache - egal ob beim Front- oder Backend - schon eine echte Herausforderung, an welcher sich wahrscheinlich schon einige SW-Hersteller etwas "verhoben" haben.

Großer Vorteil für weitgehend 'entkoppelte' Systemarchitekturen, deren Bausteine man dann leicht auf neue Programmiersprachen oder 'umfangreich renovierte' Programmversionen umstellen kann.
Wenn man es richtig angeht, kann man mit den Bausteinen dieser Architekturen dann auch Lastverteilung auf beliebig viele Server leichter umsetzen als mit monolithischen Lösungen.
Ich habe dazu vor längerer Zeit diese Präsentation gefunden, die das Thema locker angeht:
Dopplr: It's made of messages - Matt Biddulph
Ein lesenswertes Buch das darin empfohlen wird ist "Enterprise Integration Patterns"

[IBExpert]

Moin,

bin im Moment ein wenig dicht mit Arbeit, melde mich aber zu dem Thema noch, um meine Sicht der Dinge zu schildern und was ich generell mit Architektur meine

[HeZa]

Zitat:

Zitat von Sir Rufo (Beitrag 1326278)

Sehr unterhaltsam und lesenswert dazu ist
http://blog.cleancoder.com/uncle-bob...hitecture.html

Danke für die Info, das kannte ich noch nicht. Dieses fiktive Interview zeigt ganz gut welche Kräfte sich dem Software Architektur Gedanken in den Weg stellen.

Zitat:

But that means that you're going to have lots of interfaces, and lots of little implementation classes ...

Freie Übersetzung:
Aber das bedeutet ja, dass es ganz viele Schnittstelle (ala IPrintService = interface) gibt, die dann auch noch von ganz vielen kleinen Klassen implementiert werden müssen ...

Da habe ich schon viele Programmier kennengelernt, die von der objektorientiert Entwicklung überzeugt sind und dann sagen, "ach nee nicht noch ne Schnittstelle/Klasse, dass können wir doch auch gleich hier in dieser Methode lösen ..." oder was auch gerne kommt, "aber dann sehe ich gar nicht was passiert, dann muss ich mir jedes mal erst die eigentliche Implementierung suchen ...".

Wenn man sich dem Thema Software Architektur nähern will, dann schießt man meiner Meinung nach mit Begriffen wie MVC, 3-Schichten-Architektur, Micro-Services über das Ziel hinaus. Das sind vorgedachte Architektur Patterns, die im schlimmsten Fall einem Missbrauch nicht standhalten.

Ich gestehe ich lerne auch immer noch. Zur Zeit lese ich (passend zum Link) mal wieder "Clean Code" von Robert C. Martin. Da ich täglich mit Delphi Leagcy-Systemen arbeite deren Entwicklung teilweise mit Delphi3 begonnen wurde, brauch ich manchmal eine kleine Erinnerung um die "hohen" Ziele nicht aus den Augen zu verlieren. :-)

Als ich das Buch zum ersten Mal gelesen habe, haben mir Aussagen wie:

• eine Klasse/Methode sollte nur eine Aufgabe haben
• für eine Klasse/Methode sollte es nur einen Grund geben sie ändern zu müssen

ganz schön "Angst" gemacht haben. Da schaut man sich dann seine eigenen Klassen/Methoden an und zählt mal wieviele Aufgeben die so haben: 5, 10? Dann überschlägt man wieviele Gründe es für Änderungen wohl geben könnte. 20, 50?

Zum Glück ist das schon eine Weile her, aber ich habe ja noch meine Leagacy-Projekte. Vor ein paar Monaten fand man da noch, sagen wir mal 10 Klassen mit mindestens einer Methode, die 30 Parameter hatten, meistens waren es die gleichen, in der gleichen Reihenfolge, aber natürlich nicht immer. Mein Highlight 30 Parameter, 50 locale Variablen, 1000 Zeilen Code.

Zum Glück sind die Dinge die einem helfen können bereits seit langem niedergeschrieben. Lesen und die Kraft finden die Ideen und Vorschläge umzusetzen muss man dann allerdings schon selbst. Leider hatte ich nie einen Kollegen, wie im fiktiven Interview, der weiß wovon er spricht.

[Dejan Vu]

Zitat:

Zitat von HeZa (Beitrag 1326332)

Wenn man sich dem Thema Software Architektur nähern will, dann schießt man meiner Meinung nach mit Begriffen wie MVC, 3-Schichten-Architektur, Micro-Services über das Ziel hinaus. Das sind vorgedachte Architektur Patterns, die im schlimmsten Fall einem Missbrauch nicht standhalten.

Das würde ich nicht so sehen: Die Standardpattern erleichtern dem Architekten doch die Arbeit. Ich vergleiche Softwareentwicklung immer mit dem Haus/Städtebau. Für eine Hundehütte und einen Geräteschuppen brauche ich keinen Architekten (jedoch Grundlagen der Statik, zumindest beim Schuppen), aber bei einem Bungalow sieht das schon anders aus. Der Architekt arbeitet mit bekannten Mustern, Baumaterialien, Normen etc. und entwirft damit den Bauplan, den Bauarbeiter (=Entwickler), idealerweise angeleitet durch Vorarbeiter (Lead) umsetzen.
Ein Bauarbeiter, der ein bekanntes Pattern (Fachwerk, Klinker) im Bauplan sieht, kann hier seine Fähigkeiten anwenden und weiter verbessern. Würde jeder Architekt sein eigenes Süppchen kochen, würde auch jedes Mal Mumpitz herauskommen. Genauso verhält es sich mit der Softwarearchitektur.
Für den Städtebau (=Enterprise/Systemarchitektur) benötige ich ganz andere Pattern (Infrastruktur, Straßen- und Verkehrsplanung etc.) Aber immer sollten Standards und bekannte Techniken verwendet werden.
Nur bei neuen Anforderungen sollten auch neue Wege gegangen werden.

Ebenso, wie der Profi-Bauarbeiter die richtigen Techniken draufhaben muss, sollte der Programmierer die SOLID-Prinzipien verinnerlicht haben. Natürlich wird man DI in einem kleinen Tool nicht verwenden, ebenso wenig, wie man für eine Hundehütte oder den Gartenpavillion die neuesten Erkenntnisse der Spannbetonbauweise anwendet.

[HeZa]

Zitat:

Zitat von Dejan Vu (Beitrag 1326362)

Ebenso, wie der Profi-Bauarbeiter die richtigen Techniken draufhaben muss, sollte der Programmierer die SOLID-Prinzipien verinnerlicht haben. Natürlich wird man DI in einem kleinen Tool nicht verwenden, ebenso wenig, wie man für eine Hundehütte oder den Gartenpavillion die neuesten Erkenntnisse der Spannbetonbauweise anwendet.

Mein reden. Bevor man sich mit MVC etc. befasst, sollte man z.B. die SOLID-Prinzipien verstanden haben, allein schon um die Motivation hinter MVC zu verstehen. Denn wie oft ist es schon passiert, dass sich jemand mit MVC befasst "hey MVC, da schwören ja alle darauf, muss ich mal ausprobieren" um dann einen Tag später zu sagen, "boah, MVC was ein Mist, hier ne Klasse schreiben, da ein Interface implementieren, da hau ich doch lieber meine DataSource aufs Formular und mein Grid und bin fertig".

Und manchmal muss man auch erst jahrelang schmerzhafte Erfahrungen machen um die Motivation für die "aufwendigere" Technik nachvollziehen zu können.

[Sir Rufo]

Es nützen einem aber weder die buntesten Bilder, die griffigsten Buttons, die schnellste Internet-Anbindung noch die performanteste Datenbank wenn die Anwendung falsch arbeitet.

MVC, MVVM, GUI, RDBMS, JSON, SOAP, HTTP, ......... kann man am Anfang getrost komplett vergessen.

Viel wichtiger ist es eben zunächst festzulegen, was soll wann wie passieren und wann darf es nicht passieren:

• Darf Benutzer A die Zahlung freigeben
• Darf diese Rechnung gelöscht werden
• Darf dieser Artikel verkauft werden
• Darf dieser Benutzer sich überhaupt anmelden
• Darf dieser Änderung vorgenommen werden
• ... usw. ...

Genau das sollte auch das Kernthema im Kundengespräch sein. Mit MVVM und Konsorten, weiß der idR eh nichts anzufangen (gut hört sich eben wichtig an).

Wenn diese Regeln dann definiert wurden, dann kann man den Rest der Anwendung (GUI, DAL) darum bauen.

Denn ob diese Anwendung nachher auf einem Webserver läuft oder nativ ist oder auf einem Mobile Device, diese Regeln müssen eingehalten werden, weil sonst die Anwendung ja nicht mehr das macht, was die eigentlich soll.

Im Prinzip liegen gewisse Dinge eh schon fest (es wird mit Delphi programmiert, als Framework nehmen wir FMX und der Kunde hat schon einen XY-Datenbank-Server den man benutzen kann, bzw. er bekommt einen weitern DB-Server denn mit der Wartung kennt er sich schon aus).

[sh17]

Und wenn man diese Regeln dann in Delphi oder was auch immer so programmiert, dass man kaum oder keine Abhängigkeiten zu LIBs oder RTLs erzeugt, dann ist es relativ einfach, das ganze in eine andere Sprache zu portieren. Weil die Grundsätze sind ja in den meisten Sprachen die selben (Schleifen, Objekte,....).

[Sir Rufo]

Zitat:

Zitat von sh17 (Beitrag 1326394)

Und wenn man diese Regeln dann in Delphi oder was auch immer so programmiert, dass man kaum oder keine Abhängigkeiten zu LIBs oder RTLs erzeugt, dann ist es relativ einfach, das ganze in eine andere Sprache zu portieren. Weil die Grundsätze sind ja in den meisten Sprachen die selben (Schleifen, Objekte,....).

Da in diesen Regeln Logik verbaut ist wird man dort keine Abhängigkeiten finden sondern nur andere Sprachkonstrukte, die das Gleiche bewirken.

Die Kommunikation mit der konkreten Aussenwelt erfolgt (wo es dann wieder Abhängigkeiten von Framework xy gibt) über Interfaces die dann auch austauschbar sind (zum Testen, zum Umstellen).

Das Beispiel von Uncle Bob zeigt doch sehr schön diese Abstraktion der Abhängigkeiten (um eben nicht abhängig zu sein).

Hier mal so ein Beispiel in Delphi

Delphi-Quellcode:

unit Domain.BusinessRules.ChangeUserPassword;

interface

uses
  Domain.BusinessRules.Core,
  Domain.Exceptions;

type
  IChangeUserPasswordRuleGateway = interface( IBusinessRuleGateway )
    function GetUserById( const aUserid: TUserId ): TUser;
    procedure SaveUser( aUser: TUser );
  end;

  TChangeUserPassword = class( TBusinessRule<IChangeUserPasswordRuleGateway> )
  public
    procedure Execute( const aUserid: TUserId; const NewPassword: string );
  end;

implementation

{ TChangeUserPassword }

procedure TChangeUserPassword.Execute(
  const aUserid    : TUserId;
  const NewPassword: string );
var
  lUser: TUser;
begin
  if not Authority.IsAuthenticated
  then
    TDomainException.ThrowNotLoggedIn; // Nicht angemeldet

  if not Authority.CurrentUserId.Equals( aUserid ) and not Authority.HasRole( 'admin' )
  then
    TDomainException.ThrowNotAllowed; // Keine Berechtigung

  Gateway.StartTransaction( );
  try

    lUser := Gateway.GetUserById( aUserid );
    try
      if not Assigned( lUser )
      then
        TDomainException.ThrowNotFound; // Unbekannter Benutzer

      lUser.Password := NewPassword;
      Gateway.SaveUser( lUser );
    finally
      lUser.Free;
    end;

    Gateway.EndTransaction( );
  except
    Gateway.RollbackTransaction( );
  end;
end;

end.

Delphi-Quellcode:

unit Domain.BusinessRules.Core;

interface

type
  IAuthorityContext = interface
    function GetIsAuthenticated: Boolean;
    property IsAuthenticated: Boolean read GetIsAuthenticated;
    function GetCurrentUserId: TUserId;
    property CurrentUserId: TUserId read GetCurrentUserId;
    function HasRole( const aRole: string ): Boolean;
  end;

  IBusinessRuleGateway = interface
    procedure StartTransaction( );
    procedure EndTransaction( );
    procedure RollbackTransaction( );
  end;

  TBusinessRule<TGateway: IBusinessRuleGateway> = class abstract
  private
    FGateway  : TGateway;
    FAuthority: IAuthorityContext;
  protected
    property Authority: IAuthorityContext read FAuthority;
    property Gateway  : IChangeUserPasswordRuleGateway read FGateway;
  public
    constructor Create( const AGateway: TGateway; const AAuthority: IAuthorityContext );
  end;
implementation

{ TBusinessRule<TGateway> }

constructor TBusinessRule<TGateway>.Create(
  const AGateway  : TGateway;
  const AAuthority: IAuthorityContext );
begin
  inherited Create;
  FAuthority := AAuthority;
  FGateway   := AGateway;
end;

end.