Martin Lantzsch
Software Entwickler
20. Januar 2014

Domain Driven Design mit PHP umsetzen

20. Januar 2014 - Geschrieben von Martin - Keine Kommentare

In der Planungsphase meiner Anwendungsplattform für Geschäftsprozesse habe ich festgestellt, dass es relativ wenig Leute gibt, die sauberes DDD mit PHP umsetzen. Wobei wir gar nicht mal zu solch „ausgefallenen“ Sprachen greifen müssen. Selbst die Paradebeispiele in Java aus Lehrbüchern sind oftmals unsauber umgesetzt.

Beim DDD sollte man eigentlich auf jegliche Abhängigkeiten zwischen Framework + Bibliotheken und der eigentlichen Domain Logik (Entities, Value Objects, Repository Interfaces, etc.) verzichten. Es sollte in keiner Domain Klasse eine Referenz beispielsweise zu einem Validator aus einem Framework enthalten sein. Zumindest meiner Auffassung nach halte ich das für unschön, da der Code so nicht mehr sauber portierbar und wiederverwendbar ist.

Was nun PHP auch im Speziellen angeht wollte ich anmerken – Doctrine Entities sind keine Domain Entities. Schließlich haben diese einen Verweis auf das ORM und obendrein sind die Entities direkt mit Implementierungsdetails verbunden. Dementsprechend gehören Doctrine Entities in die Infrastruktur.

Bei Residata handhaben wir es so, dass Doctrine unsere Domain Entities über ein vordefiniertes, auf jeden Entiy übertragbares Schema in der Infrastruktur Schicht mappt. Die Domain Entities wiederrum sind einfache PHP Klassen ohne Referenzen, lediglich mit einem PHPDoc Kommentar versehen um die Datentypen kenntlich zu machen.

Das Repostiory wird als Interface definiert und ebenso von Doctrine oder jeder anderen gegen die Schnittstellen der Plattform implementierten Persistenzschicht automatisch „befüllt“. Ausgefallene Abfragen die nicht automatisch bereitgestellt werden kann man in einem AbstractRepository oder einem Service über einen extra Builder bauen, der auch von der Persistenzschicht in eine Abfragesprache übersetzt wird.

Wie genau das alles nun in Code ausseht, das werde ich in den kommenden Tagen hier veröffentlichen. Ob die ganze Plattform unter einer Open Source Lizenz veröffentlich wird weiß ich allerdings noch nicht.

26. Oktober 2013

C# WPF AbstractWindow

26. Oktober 2013 - Geschrieben von Martin - Keine Kommentare

Normalerweise erbt die Klasse eines neu erzeugten Fensters (in diesem Fall MainWindow) direkt von System.Windows.Window. Bei meiner Anwendung wollte ich allerdings, dass das Hauptfenster von meiner Klasse ResiWriter.UI.AbstractWindow erbt.

namespace ResiWriter.UI
{
    public abstract class AbstractWindow : System.Windows.Window
    {
 
    }
}

In der MainWindow.xaml.cs Klasse habe ich dann wie gewohnt von der AbstractWindow geerbt:

namespace ResiWriter
{
    public partial class MainWindow : UI.AbstractWindow
    {
        public MainWindow()
        {
            InitializeComponent();
        }
    }
}

Durch den Umstand, dass MainWindow eine partial Klasse ist, muss nun auch der zweite zugehörige Klassenteil vom AbstractWindow erben. Problematisch an der Sache ist jedoch, dass der zweite Teil der Klasse beim kompilieren aus dem XAML erzeugt wird. Dementsprechend muss dieses XAML angepasst werden um dem Compiler mitzuteilen von welcher Klasse geerbt werden soll.

<src:AbstractWindow x:Class="ResiWriter.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:src="clr-namespace:ResiWriter.UI"
        Title="ResiWriter" Height="480" Width="800">
        <Grid></Grid>
</src:AbstractWindow>

Wichtig ist hier, dass der Knoten Window durch src:AbstractWindow getauscht wird. Damit der Compiler auch weiß aus welchem Namespace AbstractWindow stammt wird zusätzlich das Attribut src eingefügt: xmlns:src=“clr-namespace:ResiWriter.UI“

8. Januar 2013

Umzug der resi:DATA Infrastruktur

8. Januar 2013 - Geschrieben von Martin - 4 Kommentare

Da seit dem letzten Post über die Infrastruktur einiges an Webspaces und Servern dazu gekommen ist, muss nun alles mal neu formiert werden.

Aktuell arbeite ich mit 2 Webspaces für Webseiten und Mail Hosting, einen Webspace für Backups, zwei Linux vServer für Webapplikationen, Webservices und Git Repositories und einen Windows vServer für ein C# Projekt, dass eine Serverapplikation und einen Team Foundation Server erfordert.

Das ganze soll im nächsten halben Jahr auf zwei vServer und einen Webspace zusammengezogen werden. Hierzu werden zwei Webspaces gekündigt und alle Domains auf einen großen Webspace Umgezogen, der auch gleichzeitig die Mail Struktur beherbergen soll (dann muss ich keine Mail Server mehr administrieren, was sehr entspannend ist :)). Die Linux vServer werden aus dem Momentanen Dienste Mix gelöst und einer wird für Lighttpd + PHP und der andere für MySQL, NodeJS und Git zuständig sein. Der Windows Server verschwindet ganz, da die Applikation mitsamt des Team Foundation Servers in ein Cloud Hosting migriert wird.

Im nächsten Schritt, der nicht so Zeitkritisch ist, werden alle Webseiten und Applikationen die derzeitig noch auf PHP Basis laufen auf NodeJS umgezogen. Ist dieser Schritt abgeschlossen wird vServer Nr 1. als dedizierter MySQL Server und vServer 2. als dedizierter NodeJS Server eingesetzt.

Soweit das vorhaben. Nun muss erst einmal eine Bestandsaufnahme bezüglich Domains, Apps, etc. gemacht werden. Anschließend heißt es Verträge kündigen, neue Server mieten, etc.