Paketnamenskonventionen für Domänenobjektmodelle
-
01-07-2019 - |
Frage
Was sind einige gute Paket Namenskonventionen für domänenspezifische Objektmodelle. Zum Beispiel, sagen, Sie haben eine Person.java POJO, würden Sie es ausdrückte in ein mydomain.model oder mydomain.entity oder mydomain.om (Objektmodell) Paket. Die Idee ist es, die MVC-Modell-Objekte aus dem Domain-Objektmodell zu trennen. Unsere MVC-basierte Anwendung hat ein Modell Paket, das Verhalten enthält, jedoch unter Verwendung dieses Paket zu unserem Domain-Objektmodell scheint unangemessen und potenziell verwirrend enthalten.
Lösung
Ich benutze „com.mycompany.domain“ persönlich, aber das ist vielleicht nicht die beste Antwort sein.
Andere Tipps
Vielleicht möchten Sie Ihre Pakete vertikal statt horizontal um separate Funktionalität zu organisieren.
Eg.
com.foobar.accounting.model.*
com.foobar.accounting.view.*
com.foobar.invoicing.model.*
com.foobar.invoicing.view.*
kann besser sein als
com.foobar.model.accounting.*
com.foobar.model.invoicing.*
com.foobar.view.accounting.*
com.foobar.view.invoicing.*
Der Paketname Sie wählen, ist irrelevant. Modell vs. Domain vs. vo vs. foobar ist alles in Ordnung nur so lange, wie Ihr Team alle auf der gleichen Seite. Ich bin damit einverstanden, dass dieses Paket nur POJO Domain-Objekte ohne wesentliche Business-Logik enthalten sollte.
Nicht nur das, vorsichtig sein, in der Namenskonvention Ihrer Namensräume. Ich habe Fälle gesehen, wo Namensraum-Name, wo in verschiedenen Baugruppen dupliziert. Sprechen Sie über die Verwirrung.