Wichtigkeit von SW Architektur

[Sir Rufo]

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

[HeZa]

Zitat von Sir Rufo:

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 von HeZa:

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 von Dejan Vu:

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 von 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,....).

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.