Wichtigkeit von SW Architektur

[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.