Die wichtigsten Aussagen habe ich zusammengefasst im folgenden:
Wozu benötugt man eine gute Architektur? Es ist einfach ein Programm zu schreiben, das etwas bestimmtes tut, selbst Schulkinder schreiben Programme. Aber schwierig ist es ein Programm zu schreiben, was auch in Zukunft erweiterbar und felxibel ist, ohne große Kosten und Aufwand zu verursachen. Deswegen bracht es von Anfang an gute Architektur.
Die Evolution der Programmiersprachen besteht darin, dem Programmierer weniger Möglichkeiten zu geben, schlechten Code zu schreiben.
Man sollte nicht in die Falle tappen: Wir programmieren schnell das Projekt zu Ende um schnell am Markt zu sein und später räumen wir den Code auf. Das wird nie passieren.
Das User Interface (UI), die Datenbank und die Business Rules sollten unabhängig von einander über Interfaces mit einander verbunden und austauschbar sein (Plugin Architektur). Dies ermöglicht ein
- unabhängiges Deployment der 3 Komponenten und
- unabhängige Entwicklung in verschiedenen Teams
Funktionale Programmierung löst das Problem von Deadlocks und Multi-Threading Problematiken, da keine richtigen Variablen vorhanden sind.
Principles
Seperate the code that different actors depend on.
Actors sind verschieden Breieche einer Software, z.B. Buchhaltung und User-Management.
Protect higher level components from changes in lower-level components.
Depending on something that carries baggage that you don’t need can cause you troubles that you didn’t expect.
Add functionality without making changes to the interfaces.
Avoid depending on volatile concretions…use of stable abstract interfaces.
Keine Verweise auf veränderbare Klasse, verwende Interfaces statt dessen.
Leite nicht von sich ändernden Klassen ab. Sich ändernde Klassen sind solche, die sich während der Enticklung ändern können. Basisklassen eines Frameworks gehören nicht dazu.
Überschreibe keine Methoden in einer Vererbung. Anstelle dessen sollte die Funktion abstrakt gesetzt werden und mehrmals implementiert werden.
Niemals sollte der Name von etwas konkretem oder veränderlichem im Code auftauchen.
Gather together those things that change at the same time and for the same reasons. Seperate those things that change at different times or for different reasons.
Common Reusable Principle
Don’t force users of a component to depend on things they don’t need.
Ein guter Architekt
A good architect maximizes the number of decisions not made.
Business Rules
Die Business Rules Klassen einer Apllikation sollten keinerlei Abhängigkeiten enthalten zu Frameworks, Datenbanken sondern nur Daten erhalten und Daten zurückgeben über Interfaces.
Frameworks
Frameworks sind wichtig und praktisch. Framworks sollten nicht die Ordnerstruktur des Projektes vorgeben. Wenn man ein Projekt öffnet, sollte man nicht sehen, dass es eine Symfony Applikation ist, sondern dass es sich um eine Healthcare Applkation handelt. Die Business Logik und die die Entität Klassen sollten keine Verweise of Framework Klassen beinhalten und auch die Unit-Tests dazu sollten keine Framrwork Klassen als Abhängigkeiten benötigen. Wenn man Webapllikationen baut, sollte dies in der Ordnerstruktur nciht erkennbar sein. Es ist ein Implementierungsdetail, ob die Applikation eine Web- oder Konsolenapplikation ist und es kann vorkommen, dass dieses Details ich verändert.
The Dependency Rule
Objekte dürfen nicht in eine höhere Ebene direkt miteinander in Abhängigkeit gebracht werden.
Die Rangfolge dabei ist die folgende (von unten nach oben):
Entitäten -> Use Cases -> Controllers / Presenters / Gateways -> Datenbank, UI, Web
Abhängigkeiten von einer oberen zu einer unteren Ebenen sind mittels Interfaces aufzulösen.
Entitäten
Entitäten enthalten die kritischen Business Rules, die sich nur sehr selten ändern werden. Entitäten können in vielen Applikationen innerhalb des Unternehmens verwendet werden. Entitäten können Datenstrukturen und Funktionen enthalten. Bei einer Flugsuche wären das z.B.: Ort, Flüge, Passagiere, Fluggesellschaften.
Ein Flug wird von einer Fluggesellschaften betrieben.
Ein Flug geht von einem Ort zu einem anderen an einem bestimmten Zeitpunkt usw.
Use Cases
Use Cases sind Anwendungsspezifisch und steuern den Fluss der Daten zu und aus den Entitäten heraus.
Änderungen in diesem Layer haben keine Auswirkungen auf die Entitäten.
Interface Adapters
Der MVC Layer gehören: Presenters, View und Controllers. Hier werden die Daten gemappt zwischen den Entitäten und z.B.: der Datenbank oder HTML-Formularen.