Ich habe versucht, meine DAL von meiner Business-Schicht zu trennen, und dabei habe ich beschlossen, jeden ActiveRecord-Ansatz zu meiden und einen DataMapper-Ansatz zu verfolgen. Mit anderen Worten, meine Domänenobjekte würden nicht darauf achten, dass sie selbst bestehen bleiben. Dabei scheine ich auf das Anti-Pattern "Anemic Domain Model" einzuwirken. Zum Beispiel ist eine der Entitäten in meinem Programm eine Organisation.
Eine Organisation wird in etwa folgendermaßen dargestellt:
%Vor%Im Grunde macht diese Organisation nichts anderes als für einige Daten als "Tasche" (wie Martin Fowler sagt) zu handeln. In der PHP-Welt ist es nichts weiter als eine verherrlichte Anordnung. Es ist kein Verhalten damit verbunden.
Und Verhalten im Programm, ich habe in der "Service Level" -Klasse wie ein OrganizationService, die meist als Vermittler zwischen diesen Objekten und der DAL dient gehalten.
Abgesehen von potenziellen Skalierungsproblemen mit PHP (ich habe noch andere Gründe, warum ich darauf beharre, meine Daten in diesen Objekten zu "verpacken"), ist dieser Ansatz völlig ausgeschaltet?
Wie gehen Sie in diesen Situationen mit Ihren Domänenmodellen um? Vielleicht ist eine Organisation überhaupt nicht Teil meiner Domäne?
Nun, am Anfang scheint es so zu sein, aber wenn Sie Ihren Code mehr umgestalten, werden Sie zu einem Verhalten für Ihre Organisationsklasse kommen ...
Ein Beispiel, an das ich jetzt denken könnte, ist, wenn Sie Leute (Mitarbeiter) haben, möchten Sie sie vielleicht mit Organisation verbinden. Sie könnten also eine Methode AssociateEmployee(User employee) haben, die ihren Platz in Ihrer Organisationsklasse finden könnte.
Oder Sie ändern den Standort des Unternehmens, anstatt Parameter wie Adresse, Stadt, Bundesland in drei Schritten festzulegen, fügen Sie ChangeLocation(Street, City, State) method ..
Gehen Sie Schritt für Schritt, wenn Sie auf einen Code in Ihrer BL / Service-Schicht stoßen, der scheinbar in die Domain gehört, und verschieben Sie sie in die Domain. Wenn Sie Fowler lesen, werden Sie es sehr bald bekommen, wenn Sie es in Ihrem Code sehen.
Es könnte jetzt nur anämisch sein?
Zum Beispiel habe ich einmal eine Meeting- / Konferenz-Registrierungsseite entwickelt. Es begann mit nur einem Treffen.
Es gab immer noch einen Meeting-Kurs und nur eine Instanz, aber im nächsten Jahr haben wir die Konferenz abgehalten, sie wurde erweitert und neue Immobilien wurden hinzugefügt (um zwei aufeinanderfolgende Meetings abzuhalten), also war es einfach nicht vollständig entwickelt, noch, als wir dann Gruppen hinzugefügt, die mehrere Sitzungen enthalten könnten.
Ich denke also, es ist wichtig, daran zu denken, dass sich Domains im Laufe der Zeit ändern und Ihr Modell möglicherweise refaktoriert wird. Selbst wenn Sie vielleicht denken, dass es blutarm ist, ist es vielleicht etwas zu zukunftsorientiert (wie Ihre Unternehmensklasse) wird anfangen, einige Einstellungen, Regeln oder Vorlieben oder etwas zu bekommen).
Wenn Sie nicht viele Geschäftsregeln haben oder die Domäne nicht so komplex ist, könnte es sein, dass diese DDD für Sie zu viel Aufwand bedeutet. DDD ist eine ausgezeichnete Lösung für große, komplizierte Domänen, aber es ist eine Menge Aufwand und Komplexität, wenn Sie nur Daten in, Daten out machen. DDD ist schwieriger zu gestalten und fügt Komplexität hinzu, so dass die Komplexität der Problemdomäne dies rechtfertigen sollte.
Das wäre alles, was ich zu Zappan und Epitka hinzufügen würde.
Deine Entität ist nicht blutarm, weil du eine Reponibilität nimmst, die nicht von Anfang an da sein sollte. Persistente und holende Entitäten sind die Verantwortlichkeit von Repositories. Wirklich sollte Ihr Verhalten in Ihren Entitäten nicht in einer Service-Schicht sein. Aber zu erklären, was wohin geht, ist weit mehr als nur eine einfache Antwort. DDD von Eric Evans ist ein guter Ausgangspunkt.
Tags und Links php domain-driven-design domain-model