Einstieg in Java EE - Beispielanwendungen

[Fantasma]

Hallo Forum:

Ich versuche gerade mich in Java EE einzuarbeiten und dabei wuerden mir Beispielanwendungen zum Download sehr helfen.

Vielleicht etwas wo man das Zusammenspiel von den drei Tiers gut erkennen kann, welche Aufgabe wie von welchem Tier uebernommen wird etc.

Am meisten wuerden mich Beispiele fuer Logins interessieren, also wie ist der Programmfluss? was wird da wo und wann gemacht? bei Login/User validierungen zum beispiel oder auch bei den EJB Transaktionen wenn ich bei der Ablage in die Datenbank auf verschiedene DAOs zurueckgreifen muss.

Ich hoffe Ihr versteht, was ich meine? Ich hab schon ueber Goolge etwas rumgesucht aber auf kein befriedigendes Ergebniss gekommen.

Ok, ich hoffe auf Eure Hilfe.

Danke schon mal.

Fantasma

 

[Marcinek]

Hallo,

das Netz ist voller Beispiele für EJB krams.

Getting Started with EJB 3.0 and Enterprise Bean Components

EJB Tutorial

Oder man kauft sich entsprechende Bücher. Ein Forum für solch eine Frage ist imho der falsche Platz um zu starten.

Gruß,

Martin

 

[Fantasma]

Hallo Martin:

Danke fuer deine Links. Den Rose India find ich ziemlich gut.

Ich weis, in foren trifft man sich eher fuer konkrete fragen. Ist das der Grund warum du foren nicht
so gut geeignet findest fuer anfaenger? Ich faende es ehrlich gesagt ganz gut wenn man im ein thema
nur mit links, tutorials und buchtipps haette, den man immer weiter ausbauen koennte. ich glaube das wuerde vielen helfen.

Ich hab natuerlich auch Buecher usw. Die Sache ist nur die meisten Beispiele sind sehr isoliert.
Ich suche nach einer Art show case wo man das zusammenspiel der komponenten sieht. Einfach um
Ideen und best practices zu sammeln etc.

Ich hatte einen showcase fuer eine "petshop" application gefunden, aber der link hat leider nicth mehr funktioniert. Vielleicht kann mir da noch jemand weiterhelfen etwas aehnliches zu finden?

Danke Dir, Martin
Fantasma

 

[Fantasma]

PS Was mir zum Beispiel an konkreten Fragen einfaellt waere:

Wenn ich zum Beispiel 2 Entities habe: User und Profil @OneToOne cascade all.
Der User kennt sein Profil aber das Profil braucht nicht den User zu kennen.
Ich habe einen DAO fuer den User, aber brauche ich auch einen fuer das Profil?

Oder wenn ich an verschiedenen Entitaeten gleichzeitig aenderungen durchfuehren will die zusammen eine transaktion ergeben sollen. Ok das mach ich in einer Statless SessionBean bevor ich die einzelnen DAOs aufrufe. In den SessionBeans gibt es ja auch Transaktionen. Aber ich muss das an Hand von beispielen sehen sonst versteh ich es ncith richtig.

Eine frage wo ich noch gar keine ahnung habe ist wenn ich einen login seite habe und ich logge mich mit einem user ein. Als erstes kommt eine Pwd validierung in einer stateless SessionBean die zurueckgibt ob der user existiert und ob das passwort richtig war. Aber wie kann ich dann spaeter in der anwendung auf den current user zurueckgreifen?

Ich weis nicht ob die art meiner zweifel richtig rauskommt? ich brauche einfach Beispiele wo ich sehen kann, wie der programmfluss von jee anwendungen funktioniert. es faellt mir dann einfacher mir ein bild zu machen und es besser anzuwenden.

Fantasma

 

[JanHH]

Hm also dieses ganze DAO-Ding kommt mir eh veraltet vor. Ist wohl aus J2EE-zeiten, JEE6 oder JEE5 mit seam macht das wohl überflüssig.

Ich verwende eigentlich immer eine ziemlich einfache Struktur, die wohl von Seam stammt:

- Entities für die Datenbank/Modellierung der Objekte
- "Action Beans" bzw. session beans für die eigentliche Arbeit, diese sind in der Regel stateful und haben session scope (etwas grob verallgemeinert, aber in der Regel kommt man damit gut aus)
- JSF-Seiten

Mit seam wird das relativ einfach per Annotation konfiguriert, in JEE6 entsprechend (nur halt etwas anders, mit CDI).

Für das Login-Beispiel.. abgesehen davon, dass seam dafür eine eigene Komponente (identity) anbietet, würde ich das dann so machen:

Es gibt eine UserBean für die User in der Datenbank (Name/Passwort/Rollen), und eine stateful session bean (egal ob EJB oder nicht) "loginAction", die die Methode zum validieren der Login-Daten enthält, und (bei erfolgreichem Login) ein UserBean-Objekt.

Auf die LoginAction kann man dann in JSF-Seiten per value expression zugreifen, z.B.

<hutputText value="Sie sind eingeloggt" rendered="#{loginAction.loggedIn}" />
<hutputText value="Ihr Name: #{loginAction.user.name}" rendered="#{loginAction.loggedIn}" />

oder per @Inject in andere Session Beans injizieren.

 

[maki]

Ist wohl aus J2EE-zeiten, JEE6 oder JEE5 mit seam macht das wohl überflüssig.

DAO stammt aus den Zeiten vor JPA, seit dem EM spart man sich die DAOs

 

[TheDarkRose]

Kommt auch immer darauf an wie man DAO definiert

 

[maki]

Sun hatte es früher so definiert: Core J2EE Patterns - Data Access Object

DAO eben...

 

[TheDarkRose]

Ich verwende selbst eigentlich immer noch so eine Art Dao EJB's welche halt mit dem Entity Manager arbeiten und eine Set oder einzelnes Entity zurückgeben. Somit entkopple ich mein EJB's welche sich um die Businesslogik kümmern, von Zugriffen auf den EM und sie brauchen sich auch nicht um die Datenbankstruktur zu kümmern, denn das macht mein "Eao (Entity Access Object nenne ich sie)". Sind aber trotzdem stinknormale Session Beans die in eine andere EJB injiziert wird.

 

[maki]

JPA/EJB3 killed the DAO : Adam Bien's Weblog

Nebenbei, Muster selber erschaffen/benennen widerspricht dem Zweck von Mustern
Hört sich schon nach einem DAO an dass du beschreibst.

 

[TheDarkRose]

Hmm, dein Link funktioniert bei mir in der Firma nicht. Werde mir das daheim anschauen.

Hab das aus diesem Tutorial: An Eclipse / GlassFish / Java EE 6 Tutorial » Programming

 

[ARadauer]

killed the DAO....ok und wie nennt man das wo der EntityManager dann benutzt wird? Direkt im Service Layer? Und was ist, wenn ich komplexerer Abfragen über den EntityManger ausführen will? Dann hab ich gerade sauber meine Business Service Schicht mit meiner Persistenz Schicht vermischt. :-( DAO hat meiner Meinung nach immer noch seine Berechtigung.

 

[mvitz]

Gerade wenn man sich die Kommentare noch dazu durchliest, kommt raus, dass es in erster Linie um die typischen 5 CRUD (2xR) Methoden geht. Wenn man nur diese braucht, stimme ich dem Artikel durchaus zu, dadurch spart man sich eine Schicht die praktisch keine Logik hat und macht seine Applikation einfacher. Sobald jedoch weitere (vor allem komplexere) Read-Methoden gebraucht werden und diese unter Umständen auch noch von weiteren Stellen, würde ich dazu übergehen eine DAO-Schicht einzuziehen.

 

[TheDarkRose]

Sozusagen vereinfacht JPA die DAO Schicht. Man kann einfach auf die Low Level Kommunikation mit JDBC verzichten und arbeitet mit dem Entitiy Manager.

 

[ARadauer]

Ja genau. Bei simplen Sachen so sehr, dass die Zugriffe zu einem Einzeiler werden und man somit auf das DAO verzichten kann

 

[TheDarkRose]

Jein. Die alten CRUD-Methoden gibt es nicht mehr. Aber trotzdem noch so Sachen wie getByEmail, etc. Welche halt ein spezifische Suche anstoßen. Außer du willst unbedingt deine Datenzugriffsschicht (auch wenn es nur der Entitiymanager ist) in deiner Serviceschicht vermischen? Finde das eher unschön. Vorallem, lässt sich die Serviceschicht nicht wieder verwenden, wenn man diese nicht trennt. Eh schon zuviel, das die Serviceschicht die Entityklassen kennt.

 

[Fantasma]

Hallo:
Danke fuer die vielen Antworten. ich weis das sehr zu schaetzen.

@JanHH: Was die DAOs betrifft nehme ich das eher so wie DarkRose. Ich hab den gesamten Zugriff auf den EntityManager und den PersistanceContext in eine extra Stateless Sessionbean gekapselt. Vielleicht ist das eher geschmackssache aber ich mag es lieber änderungen an der Persistance an genau einer Stelle machen zu muessen und ausserdem habe ich die Zustaendigkeiten deutlicher getrennt.

Was du mit "ActionBean" meinst ist das eine BackingBean mit @ManagedBean wo du die "UserEntityBean" (@Entity) injizierst? Hab ich das so richtig verstanden? Was ich bisher habe ist ein Teil der Login Logic.

Das habe ich in einer Stateless Session Bean gemacht(ich weis nicht ob Dich/Euch mein quellcode interessiert, aber mich interessiert Eure Meinung dazu ;-)):

package com.logica.userLogin;

import java.util.Date;

import javax.ejb.EJB;
import javax.ejb.Stateless;

import com.entity.Usuario;
import com.entity.UsuarioLoginInfo;
import com.entityDAO.UsuarioDAO;
import com.logica.Excepciones.*;
import com.util.entity.PreAlta;
import com.util.entityDAO.PreAltaDAO;

@Stateless
public class ValidarLoginImpl implements ValidarLogin {
	
	@EJB
	private UsuarioDAO usuario;
	private Usuario tmpUsuario;
	
	@EJB PreAltaDAO prealta;
	private PreAlta tmpPreAlta;

	@Override
	public Usuario confirmarLogin(String login, String pwd) throws UsuarioExcepcion {
		tmpUsuario = usuario.buscarUsuario(login);	
		
		if (tmpUsuario == null){
			throw new UsuarioNoExisteExcepcion();
		}
		if (tmpUsuario.getPwd().equals(pwd)){
			tmpUsuario.getUsuarioLoginInfo().incrementarErroresLogin();
			throw new UsuarioPwdExcepcion();
		}
		
		tmpUsuario.getUsuarioLoginInfo().resetearErroresLogin();
		tmpUsuario.getUsuarioLoginInfo().setUltimoLoginFecha(new Date());
		return tmpUsuario;
	}
	
	public void cambiarPwd (int idUsuario, String viejoPwd, String nuevoPwd)throws UsuarioExcepcion{
		
		tmpUsuario = usuario.buscarUsuario(idUsuario);
		
		if (tmpUsuario.getPwd().equals(viejoPwd)){
			tmpUsuario.setPwd(nuevoPwd);
		}
		else{
			throw new UsuarioPwdExcepcion();
		}
		
	}

	@Override
	public Usuario primerLogin(String login, String pwd) throws UsuarioExcepcion {
		tmpPreAlta = prealta.buscarPreAlta(login);
		
		if (tmpPreAlta.getPwd().equals(pwd)){
			tmpUsuario = new Usuario();
			tmpUsuario.setLogin(tmpPreAlta.getLogin());
			tmpUsuario.setNombre(tmpPreAlta.getNombre());
			tmpUsuario.setApellido(tmpPreAlta.getApellido());
			
			UsuarioLoginInfo loginf = new UsuarioLoginInfo();
			loginf.setErroresLogin(0);
			loginf.setUltimoLoginFecha(new Date());
			tmpUsuario.setUsuarioLoginInfo(loginf);
			
			prealta.borrarPreAlta(tmpPreAlta);
			return tmpUsuario;			
		}
		
		else{
			throw new UsuarioPwdExcepcion();
		}
		
	}
	
	
}

Der input soll dann von einer BackingBean kommen(@ManagedBean session scoped) und die Methoden nehmen jeweils Passwort und Login entgegen und geben den User zurueck(oder eine Exception). In der BackingBean wird es dann eine User-Instanz geben. Die ist ja dann ueber die ganze Session hin vorhanden, sehe ich das richtig??

Eine andere Frage: Wenn ich diesen User in der BackingBean habe, die ja session scoped ist, und ich in der Logic kontakte zwischen zwei Usern knüpfen will. Ich mache da also eine StatlesBean fuer die kontakte und übergebe dieser dann den Loginnamen des zu kontaktierenden users, richtig? und wenn es diesen user gibt (und er mit noch ein paar mehr bedingungen erfuellt) dann kann ich diesen zweiten user als Rückabewert der kontaktknuepfbean programmieren und ihn dann in die kontaktliste des Users aus der Sessoin fuegen, richtig? Sorry fuer meine teilweise dummen Fragen aber mir fehlt etwas die Vorstellung fuer die Sessions glaube ich.

Danke nochmals
Fantasma

 

[JanHH]

Interessant an Deinem Quellcode ist auf jeden Fall die Sprache ;-).

Ansonsten hab ich den Eindruck, dass Du es Dir komplizierter machst als notwendig. Die ActionBean ist in etwa sowas wie eine backing bean, aber so ganz passt der Vergleich nicht, weil backing bean ja mehr oder weniger fest zu einer JSF-Seite gehört. Man kann es sich vielleicht so vorstellen: Zu jeder Entity gibt es eine entsprechende Action, die für alle Aktionen, die mit dieser Entity so passereen, zuständig ist. Passt auch nicht 100%ig, aber so einigermassen.

Wenn es also eine User-Entity gibt, könnte man sich eine UserAction denken, die dafür zuständig ist, neue User anzulegen, Listen aller User aus der Datenbank zu lesen, User zu editieren usw. Man kann natürlich die Login-Validierung in eine stateless ejb tun, aber warum sollte man? Ich würde eine Stateful Session Bean "LoginAction" schreiben, die eine User-Entity als Member hat, auf deren Properties (name/passwort) man direkt per JSf zugreifen kann, die die Login-Action ausführt, und Informationen darüber liefern kann, ob das Login erfolgreich war, wie der User heisst, welche Rollen/Rechte er hat etc. Diese LoginAction ist natürlich im Session Scope, kann daher sowohl direkt per JSF referenziert werden (z.B. bestimmte Teile einer Seite nur anzeigen wenn login erfolgreich) als auch mit @Inject in andere Beans injiziert werden. Und ich wüsste auch nicht was dagegen spricht, in diese Klasse auch die Zugriffe auf die Datenbank/Entity Manager zu tun. Eine weitere DAO-Klasse kommt mir da eher übertrieben vor.

Wenn man die Persistenz bzw. konkret die Querys aus den Action-Beans auslagen will, würde ich dann eher @NamedQueries bei den Entities nehmen.

 

[Fantasma]

Hi Jahn:

ja.. die Sprache ist so eine Art Spanglish

Diese ActionBean waere dann @ManagedBean und session scoped, habe ich das richtig verstanden? Oder wie ist das dann mit der stateful? die wird ja ncith mit ManagedBean gekennzeichnet. Ich komme gerade etwas durcheinander. Wie kann ich von einer JSF seite auf eine @Stateful bean zurueckgreifen? Geht das auch mit #{beanName.property} ?

Wie sieht es mit den ressourcen aus? Statefull beans verbrauchen einiges und Session scoped ManagedBeans auch. Macht das einen bedeutenden Unterschied?

Der Ansatz mit den ActionBeans gefaellt mir, er ist finde ein wenig naeher am OOP gedanken dran als die Sache mit den BackingBeans die erinner mich eher an das prozeduale programmieren. In den Entities habe ich ja auch keine einzige methode definiert bis auf setter und getter. Das ist schon ein umdenken finde ich.

Fantasma

 

[TheDarkRose]

Eine Stafull Session Bean injectest du in deine ManagedBean, und dort kannst du dann diverse Getter/Setter Methoden oder andere Methoden designen, die mit deiner SFSB arbeiten.

 

[maki]

Der Ansatz mit den ActionBeans gefaellt mir, er ist finde ein wenig naeher am OOP gedanken dran als die Sache mit den BackingBeans die erinner mich eher an das prozeduale programmieren. In den Entities habe ich ja auch keine einzige methode definiert bis auf setter und getter. Das ist schon ein umdenken finde ich.

Solange deine Entities nur JavaBeans ohne Logik sind und du die fachliche Logik nur in EJBs (SLSB/SFSB) hast (oder schlimmer noch, in der UI), ist da immer sehr Prozedural.

 

[TheDarkRose]

Ähm, was soll denn daran schlimm sein, wenn sich die fachliche Logik rein in den EJB's befindet? Dafür sind sie doch da?

 

[maki]

Ähm, was soll denn daran schlimm sein, wenn sich die fachliche Logik rein in den EJB's befindet? Dafür sind sie doch da?

"Schlimm" nicht, aber eben nicht wirklich OO sondern prozedural, denn dadurch werden die Daten (in "dummen" Datencontainern, JavaBeans) wieder von der Logik (EJBs) getrennt.

J2EE hat das jahrelang so propagiert, mit JEE 5/6 hätte man die Wahl, aber wenn man (detached) Entities direkt in die UI gibt, verkommen die auch wieder zu dummen Datencontainern.

Wenn man jetzt die fachliche Logik in JSF ManagedBean, ist man sogar noch einen Schritt weiter zurück, da hat man nämlich die fachliche Logik prozedural in die GUI eingebaut, sollte aber zumindest in der Businesstier sein.

Wirklich "Schlimm" ist daran auch nix, oft reicht das, aber man sollte halt schon wissen womit man es da zu tun hat, und fachliche Logik nur in SFSB/SLSB EJBs oder ManagedBeans zu haben ist eben prozedural, darüber sollte man sich im klaren sein.

 

[TheDarkRose]

Okay, jetzt bin ich mehr verwirrt als vorher. Ich versteh's noch immer nicht so ganz. IMHO muss man ja die ganze Businesslogik in die EJB's packen, wenn man nicht nur per JSF WebApp darauf zugreifen will, sondern auch per JNDI in einem Remote Client. Da muss ich ja auf die strikte Trennung der Tiers achten.

aber wenn ich jetzt eine reine JSF WebApp programmiere, dann lass ich doch die EJB's überhaupt außen vor, oder?

 

[maki]

Wollte dich nicht verwirren, sondern nur auf Fantasmas Frage bez. prozeduraler Programmierung und der Entities die nur Getter & Setter haben.

Wie gesagt, wenn man die ganze Businesslogik in die SLSB/SFSB EJBs packt, ist es prozedural, genauso wenn man die ganze Businesslogik in die ManagedBeans packt, nur das in letzterem Falle dann die Logik komplett in der UI Schicht steckt -> kein Schichtenkonzept.
Wenn man JSF Apps ohne EJBs programmiert ist das auch nicht viel anders, könnte ja Spring nehmen und damit Schichten realisieren, aber wieder: Wenn die Businesslogik in einem Manager/Service/etc. steckt und die Entites nur dumme JavaBeans ohne Businesslogik sind, ist es auch prozedural

Martin Fowler nennt das übrigens "Transactionscript", kein Drama, nix schlimmes, aber eben nicht wirklich OO.

 

[Gast2]

DAO stammt aus den Zeiten vor JPA, seit dem EM spart man sich die DAOs

Könnte doch durch aus noch interessant sein, wenn man mehrere Datenquellen z.B. XML, Datenbank hat. Dann hat man verschiedene Implementierungen des DAO's oder? Sonst müsste man ja den Service anpacken?!?!

Ohne DAO

public class MyService{

    @Inject
    private EntityManager em;


}

Mit DAO

public class MyService{

    @Inject
    private MyDAO myDAO;


}

public interface MyDAO {

   MyEntity getMyEntity();

}

public class JpaDAO implements MyDAO {

    @Inject
    private EntityManager em;

}

Was eventuell erst später dazukommt

public class XmlDAO implements MyDAO {

//lade aus xml
}

Bei Variante ohne DAO müsste man jetzt den Code anpacken, bei Variante mit DAO kann weitere Implmentierungen bereitstellen und die gegebenfalls noch konfigurieren, oder sehe ich da was falsch?

 

[maki]

Wenn wir von JPA und dem EM sprechen, dann sprechen wir ausschliesslich über RDBMS als DBs, denn nur dafür ist JPA gedacht/geeignet, wer einen Standard will der mehr als nur RDBMS kann sollte sich mal JDO ansehen.

Klar kann man DAOs noch verwenden wenn man möchte, worauf Adam Bien (und damit JEE) hinaus wollte war, dass sie nicht mehr zwingend nötig sind (zumindest in einfachen Fällen, die aber anscheinend die Mehrheit darstellen ) und von Adam Bien schon "ausgemustert" wurden. Wobei ich nicht unbedingt hinter jeder seiner Aussagen stehe, ist ja schliesslich kein Martin Fowler
Finde da andere Sichtweisen (DDD zB.) viel Interessanter/aufschlussreicher.

Persönlich sehe ich DAOs auch als überholt an, ich nehme lieber Repositories
Ist meist zu 100% identischer Code zu einem DAO, wird aber anders verwendet in DDD, nämlich nicht nur von Services, sondern auch von Entites direkt zB.

 

[Gast2]

Persönlich sehe ich DAOs auch als überholt an, ich nehme lieber Repositories
Ist meist zu 100% identischer Code zu einem DAO, wird aber anders verwendet in DDD, nämlich nicht nur von Services, sondern auch von Entites direkt zB.

Was ist daran der Vorteil wenn die Entity ein Repo verwendet? Dachte Entites sollten so wenig wie möglich Abhänigkeiten und Logik haben?

 

[maki]

Was ist daran der Vorteil wenn die Entity ein Repo verwendet? Dachte Entites sollten so wenig wie möglich Abhänigkeiten und Logik haben?

"Entities sollten so wenig wie möglich Abhänigkeiten und Logik haben"

Interessante Aussage, jedes Objekt sollte so wenig Abhängigkeiten wie nötig haben, immer, da sind wir uns einig.

Der zweite Teil des Satzes beschreibt aber eindeutig prozedurale Programme, keine OO Programme.

Wenn Entities keine Logik haben und nur JavaBeans sind, sind es dann richtige Objekte?
Oder nur "dumme" Datenstrukturen die eine Pseudo OO Schnittstelle mit Gettern & Settern bieten aber dafür keine Kapselung?

Beispiel für fehlende Kapselung:

public class Person {
    
    private Date birthdate;
    private String firstname;
    private String lastname;
    private Integer id;
    private List<Project> projects;

    public Person() {
    }

    public void Date getBirthdate() {
        return this.birthdate;
    }

    public List<Project> getProjects() {
        return this.projects;
    }

/* Getter & Setter für alle(!) anderen Membervariablen */
}

Ja, hast richtig gelesen, keine Kapselung, kein richtiges Objekt, nur eine dumme Datenstruktur.

Frage: Wenn ich jetzt die Getter & Setter weglasse und alle Attribute public mache, was habe ich dann verloren?
Antwort: Die Konformität zur JavaBeans Spek. ist nicht mehr gegeben, aber ansonsten fehlt mir nix, denn die JavaBean Spek. beschreibt keine Objekte im Sinne der OO, sondern Schnittstellen für dumme Datenstrukturen.

Da es nur Datenstrukturen sind, sind auch die üblichen Regeln der OO nicht unbedingt anwendbar bzw. sinnvoll.

Wo kommt die Logik dann hin wenn nicht in die Objekte?
Richtig, die Logik wird ausgelagert, Logik wird von Daten getrennt, in Services etc. pp.

Man erinnere sich an die Grundlagen der OOP, Daten & zugehörige Logik gehören zusammen und nicht getrennt, Information Hiding, Kapselung, etc. pp.
Dumme Entites und Services mit der zugehörigen Logik sind nicht OO, sondern Prozedural.

Nur um eines klarzustellen: Ist nicht weiter "schlimm", aber es ist halt nicht OO, darüber sollte man sich schon klar sein.

Google mal nach "anemic domain model"

Der Vorteil wenn man die Logik in die Entity packt?
Nun, so ziemlich alle Vorteile die einem die OO bietet

 

[Gast2]

Was würdest du denn in die Klasse Person an Logik packen???
Ich an das Pojo eventuell noch JPA Annotation machen und kleiner Berechungen/Validierungen z.B. ist Geburtstag gültig, Gehaltberechnung usw.
Aber sobald irgendwas mit Datenbankzugriff und Transaktionshandling kommt, würde ich das in einen Service machen und nicht in die Entity.

 

[maki]

Was würdest du denn in die Klasse Person an Logik packen???

Alles was fachlich eben zur Person gehört und dort am besten reinpasst

Ich an das Pojo eventuell noch JPA Annotation machen und kleiner Berechungen/Validierungen z.B. ist Geburtstag gültig, Gehaltberechnung usw.

Frage: Sind POJOs "richtige" Objekte im Sinne der OO?
Wenn JavaBeans POJOs sind, dann nicht...

Aber sobald irgendwas mit Datenbankzugriff und Transaktionshandling kommt, würde ich das in einen Service machen und nicht in die Entity.

Du sprichst von Infrastuktur, nicht von fachlicher Logik.
Db Zugriff kapselt man in DDD in Repositories, Transaktionen werden in "Application Services" verwaltet.

 

[Gast2]

Du sprichst von Infrastuktur, nicht von fachlicher Logik.
Db Zugriff kapselt man in DDD in Repositories, Transaktionen werden in "Application Services" verwaltet.

Ok dann bin ich deiner Meinung und hab mich oben falsch ausgedrückt. Die fachliche Logik (die bestimmt jeder anders definiert) würde ich auch an die Person packen. Aber ob ich irgendwelche Abhänigkeiten von Services,DAO's, Repositories in die Person machen würde, wohl eher nicht.
Auch wenn ich jetzt nicht weiß wie genau bei dir ein Repo aussieht und was der Unterschied zu einem DAO ist.

 

[maki]

Ok dann bin ich deiner Meinung und hab mich oben falsch ausgedrückt. Die fachliche Logik (die bestimmt jeder anders definiert) würde ich auch an die Person packen.

Die fachliche Logik kann nicht jeder anders definieren, das einheitliche Verständnis und Model der Problemdomäne ist die Grundlage für DDD.

Aber ob ich irgendwelche Abhänigkeiten von Services,DAO's, Repositories in die Person machen würde, wohl eher nicht.

Das ist eben DDD, da ist es richtig dass man Entitäten "schlau" macht und diese aktive Aufgaben übernehmen, dazu nutzen sie eben u.a. Repositories, DomainServices, Factories etc. pp. direkt.
Ist halt ein sehr "Objektorientierter" Weg einen Problembereich darzustellen.

Auch wenn ich jetzt nicht weiß wie genau bei dir ein Repo aussieht und was der Unterschied zu einem DAO ist.

Wie gesagt, der Code kann zu 100% gleich mit einem DAO sein, es wird aber anders verwendet

Das Problem mit DAOs ist, dass sie zur IntegrationTier gehören, und es mit dem klassischen Schichtenmodell eben unvereinbar ist, dass eine Entity direkt mit der IntegrationTier kommuniziert.

Das "klassische Schichtenmodell" ist ja immer an Infrastruktur orientiert und meist Prozedural aufgebaut, nicht OO und nicht an der Problemdomäne, die Schichten sind nach Infrastruktur getrennt (sind übrigens immer 4 Schichten im Schichtenmodell): UI, Business, Integration und Persistenz

DDD sieht das anders, das geht eher in die Richtung Zwiebelmodell, der Kern ist dabei das Modell der Problemdomäne, dafür braucht man unbedingt schlaue Objekte, seien es Entities oder Valuebjects (Entities wird von DDD eigens definiert, hat nicht notwendigerweise etwas mit @Entity zu tun).
D.h. aber auch, dass ich meine Objekte nicht einfach in die UI serialisieren darf, dafür nimmt man dumme Datencontainer, DTOs eben.

Nur mal als kleines Beispiel (widerspricht meinem vorherigen Beispiel):
Project *<->* Person

Bidirektionale M:N ist nicht so dolle (redundante Daten, komplex, fehlerträchtig) und wenig aussagekräftig... also wird verfeinert:
Project ->* Assignment -> Person

Project hat eine Methode die assign heisst und eine Person und einen Zeitraum entgegen nimmt, erstellt ein neues Assignment daraus und fügt es dem Set assignments hinzu.
Project bietet u.a. auch Methoden, um alle Assignments oder eben alle zugewiesenen Personen zurückzugeben.

Person hat eine Methode die getAssignedProjects heisst und die zugewiesenen Projekte zurückgibt.
Person hat aber keine Collection welche die Projekte hält (wäre ja redundant), das wäre ja wieder eine bidi. M:N Beziehung, stattdessen nutzt Person das ProjectRepository um nach den zugewiesenen Projekten zu suchen.

DDD ist nicht so komplex, aber definitiv nicht in ein paar Posts zu erklären

 

[Gast2]

DDD ist nicht so komplex, aber definitiv nicht in ein paar Posts zu erklären

Ich habe mich bis jetzt zu wenig mit DDD beschäftigt , aber ist mal einen andere Sichtweise und bestimmt Interessant. Aber ich sehe jetzt auf Anhieb keinen Vorteil seine Entitäten/Models so aufzublasen und soviele Abhänigkeiten reinzumachen. Was genau ist der Vorteil vor allem auf Bezug der Wiederverwendbarkeit.

 

[maki]

Ich habe mich bis jetzt zu wenig mit DDD beschäftigt , aber ist mal einen andere Sichtweise und bestimmt Interessant. Aber ich sehe jetzt auf Anhieb keinen Vorteil seine Entitäten/Models so aufzublasen und soviele Abhänigkeiten reinzumachen. Was genau ist der Vorteil vor allem auf Bezug der Wiederverwendbarkeit.

Natürlich kannst du keine Vorteile erkennen ohne dich damit richtig auseinandergesetzt zu haben

Wie gesagt, die Vorteile sind eben die Vorteile der OO, die Nachteile von prozeduralem Code werden vermieden.
Wiederverwendbarkeit, Vermeidung von Redundanz, Kapselung, Information Hiding, konzeptionelle Zusammengehörigkeit von Verhalten und Daten, die Möglichkeit ein aussagekräftiges Domänenmodell zu erstellen das auch das Verhalten beinhaltet, etc. pp.

All das geht eben nicht wirklich gut wenn man Prozedural entwickelt, deswegen kamen die OO Sprachen ja erst auf

 

[Gast2]

All das geht eben nicht wirklich gut wenn man Prozedural entwickelt, deswegen kamen die OO Sprachen ja erst auf

Irgendwie verstehen wir uns glaub falsch^^...

Warum ist dann solche Architektur soweit verbreitet?

z.B. https://github.com/matzew/modern-ee-app20

View-->Service (Logik + Transaktionhandling)-->DAO/JPA-->Pojo mit Persistenz

 

[maki]

Irgendwie verstehen wir uns glaub falsch^^...

Warum ist dann solche Architektur soweit verbreitet?

z.B. https://github.com/matzew/modern-ee-app20

View-->Service (Logik + Transaktionhandling)-->DAO/JPA-->Pojo mit Persistenz

Weil zB. J2EE das prozedurale Design stark gefördert hatte, und offensichtlich JEE 5/6 das heute immer noch tut: "Bloss keine Logik in Entitäten"
Das ist genau das Gegenteil der OO Lehre.

OO "denke" hat es immer noch schwer heutzutage, man erinnere sich an die Grundregeln des OOD, dann merkt man den Unterschied zu dem was heute als "normal" gehandelt wird.
Das JCP ist übrigens nicht für ihre Innovationen beliebt (EJB1.x-2.x ), sondern in den letzten Jahren dafür dass sie sich genug "inspirationen" von der Konkurenz abgeschaut haben.

Heute wären "objektorientiertere" Systeme jederzeit mit JEE 5/6 möglich, dafür muss man natürlich auf ein paar "dreckige" Tricks verzichten.

Nebenbei, JavaBeans sind wirklich keine POJOs, schon per definition

 

[Gast2]

Weil zB. J2EE das prozedurale Design stark gefördert hatte, und offensichtlich JEE 5/6 das heute immer noch tut: "Bloss keine Logik in Entitäten"
Das ist genau das Gegenteil der OO Lehre.

Es muss ja einen guten Grund haben, warum neue Software dann immer noch so Designed wird und nicht anders.

Also ich finde Logik Sachen auf Entity Ebene gut. Aber weiß nicht ob es sinvoll ist dort Services/DAO's oder anderen Abhängigkeiten reinzumachen.

 

[Fantasma]

Angeblich nicht nur von Java, was ich gehoert habe ist das konzept mit den BackingBeans sehr stark an .Net angelehnt.

Mir gefaellt die Trennung zwischen daten und Logik nicht so besonders. Und ich manchen faellen ist es nicht einfach nur geschmacksache denke ich (in anderen wieder schon). Scheissen ist eine Methode vom Schaf und kein "dienst" das ein schaf in anspruch nehmen kann ;-)

@ Maki: zu deinem Beispiel mit projekt und person. warum das nicht mit einem controler machen? was waeren da die nachteile deiner meinung nach? im proyect wuerde dann logic zb zur budgetberechung und der benoetigten stunden sein und in der person zum beispiel berechungen, ob diese noch freie arbeitsstunden etc hat.

Ich hab zwischenrin mit meinem Kursleiter gesprochen und er draengt doch sehr auf diesen ehr prozedualen ansatz so das ich das dann so machen werde, der ablauf ist mir auch aus den posts weiter oben klarar geworden die action beans werde ich eher extra davon etwas unter die lupe nehmen.

Eine frage vill noch, in die Entitys kann ich da gar keine logik reinstecken? das war mir noch ncith so ganz klar. kann der entitymanager dann noch was anfangen mit diesen dingern?

Danke schonmal
Fantasma

 

[Fantasma]

PS.: ich hab zum beispiel eine statless session bean loginvalidieren die nimmt login namen und pwd entgegen und gibt den user zurueck. der wird dann in einer session scoped managed bean als sessionuser genommen. fuer mich sind da auch sehr viele abhaengigkeiten drinnen evtl sogar noch mehr als wenn ich die loginvalidieren als methode vom user implementieren wuerde. (etwa controler holt user mit loginname xyz aus der DB und fuehrt die user.loginOK methode aus).

Fantasma

 

[Fantasma]

Wenn Entities keine Logik haben und nur JavaBeans sind, sind es dann richtige Objekte?

Eben.. mich erinnert das an die struckt von C (ohne plus plus)

Fantasma

 

[JanHH]

Ich würd jetzt auch nicht sagen, dass JEE-Anwendung besonders "un-OO" sind.. wenn man sie sauber machen, folgen sie exakt dem MVC-Schema, und das ist schon OO, oder? Es handelt sich bei Webanwendungen um eine spezielle Variante von Software, die einer bestimmten Struktur folgt. Finde ich soweit ok.

Ich denke, es hängt auch hier viel vom konkreten Design ab. Man kann sicherlich Login in die Entities tun, aber nur solche, die auch direkt inhaltlich mit der Entity zu tun hat (ein Kollege meinte mal, "Komfortfunktionen sind ok"). Eine Model- bzw. Document-Schicht, die halt nur die Daten des Dokuments/Modells enthält und keine Logikfunktionen ausser solchen, die wirklich direkt mit dem Dokument zu tun haben finde ich absolut ok vom Design her.

 

[FArt]

Single responsibility principle - Wikipedia, the free encyclopedia

 

[Gast2]

Ich finde den Ansatz von maki durchaus interessant, weil ich meinen Entity intutiv auch immer fachliche Logik hinzufüge wie z.B. beim Mitarbeiter gehalt berechnungen oder ähnliches.
Aber wo ich mir noch nicht so ganz im klaren bin ob ich das Model/Entity etc. so aufblasen würde, dass ich da irgendwelche Dienste oder Repos rein machen(injecten?) würde. Das birgt doch die Gefahr, dass das Model nicht weiter verwendet werden kann, da die (ganze?!?) Logik in den Entity verankert ist.
Ich kenne Anwendungen da sind die Datenstrukturen gleich die BusinessLogik aber unterschiedlich. Da stelle ich mir es schwer vor mit der Wiederverwendung.

Nur nochmal ob dich richtig verstehe maki du würdest auch "Dienste" in die Entity/Models mit reinmachen (injecten?)? Falls ja das würde doch für die Wiederverwendung bedeuten, dass das Entity/Model nicht ohne diesen "Dienst" wiederverwendbar ist oder?

PS: Wenn du ein kleines Beispiel-Projekt daheim hast (oder im Netz), wo diesen Weg aufzeigt hätte ich interesse das mir mal anzuschauen, vielleicht macht es dann **klick**.

Nehmen wir mal an so ein Architekturaufbau ist wirklich besser (kann ich nicht beurteilen):
Würden es doch viel mehr Projekte einsetzen oder?

 

[FArt]

Wie so oft, wenn etwas einfacher wird, machen sich viele auch nicht die Arbeit eine Architektur sauber zu durchdenken.
Schließlich ist ein Bean schnell irgenwo injiziert.

Zu meinem obigen Link dann noch diesen hier: Law of Demeter - Wikipedia, the free encyclopedia

 

[Gast2]

Wie so oft, wenn etwas einfacher wird, machen sich viele auch nicht die Arbeit eine Architektur sauber zu durchdenken.
Schließlich ist ein Bean schnell irgenwo injiziert.

War das auf meinen Post bezogen?
Ich denke bei einem großer Software ist es auch nicht so leicht, einfach mal die ganze Architektur umzubauen. Aber bei neuer Software ist es was andereres, da geht es und es könnte einen neueren(besseren) Weg gehen.

 

[maki]

Es muss ja einen guten Grund haben, warum neue Software dann immer noch so Designed wird und nicht anders.

Also ich finde Logik Sachen auf Entity Ebene gut. Aber weiß nicht ob es sinvoll ist dort Services/DAO's oder anderen Abhängigkeiten reinzumachen.

Warum wird bei Spring Roo das ActiveRecord Pattern (CRUD Methoden in der Entity selber) verwendet? (Finde ich persönlich schrecklich)
Es gibt viele verschiedene Wege zum Ziel zu kommen...

Weder Sun/Oracle not MS haben es sich zum Ziel gemacht eine "reine OO Lehre" zu propagieren, man muss ja nicht katholischer sein als der Papst, man sollte es halt wissen imho.

Wenn deine Entites schlau sind, dann brauchen sie eben Repos, Factories etc. pp., also Dinge, die sonst in Services gebraucht würden.
Es ist nix anderes als eine "Verlagerung" der Abhängigkeiten, (Application-)Services werden sehr "dünn", rufen nur noch Domänenobjekte auf, diese machen den Rest.

Angeblich nicht nur von Java, was ich gehoert habe ist das konzept mit den BackingBeans sehr stark an .Net angelehnt.

Mir gefaellt die Trennung zwischen daten und Logik nicht so besonders. Und ich manchen faellen ist es nicht einfach nur geschmacksache denke ich (in anderen wieder schon). Scheissen ist eine Methode vom Schaf und kein "dienst" das ein schaf in anspruch nehmen kann ;-)

@ Maki: zu deinem Beispiel mit projekt und person. warum das nicht mit einem controler machen? was waeren da die nachteile deiner meinung nach? im proyect wuerde dann logic zb zur budgetberechung und der benoetigten stunden sein und in der person zum beispiel berechungen, ob diese noch freie arbeitsstunden etc hat.

Ich hab zwischenrin mit meinem Kursleiter gesprochen und er draengt doch sehr auf diesen ehr prozedualen ansatz so das ich das dann so machen werde, der ablauf ist mir auch aus den posts weiter oben klarar geworden die action beans werde ich eher extra davon etwas unter die lupe nehmen.

Eine frage vill noch, in die Entitys kann ich da gar keine logik reinstecken? das war mir noch ncith so ganz klar. kann der entitymanager dann noch was anfangen mit diesen dingern?

PS.: ich hab zum beispiel eine statless session bean loginvalidieren die nimmt login namen und pwd entgegen und gibt den user zurueck. der wird dann in einer session scoped managed bean als sessionuser genommen. fuer mich sind da auch sehr viele abhaengigkeiten drinnen evtl sogar noch mehr als wenn ich die loginvalidieren als methode vom user implementieren wuerde. (etwa controler holt user mit loginname xyz aus der DB und fuehrt die user.loginOK methode aus).

Der Controller gehört doch zur UI, oder?
Klar kann man das auch machen, aber das ist dann kein Schichtenmodell.

Dein Kursleiter hat übrigens recht, "das macht man so in JEE", wenn du JEE lernen willst, kannst du anfangs ruhig den empfohlenen Pfad gehen und später, wenn du vertrauter damit bist, andere Wege einschlagen.

Ich würd jetzt auch nicht sagen, dass JEE-Anwendung besonders "un-OO" sind.. wenn man sie sauber machen, folgen sie exakt dem MVC-Schema, und das ist schon OO, oder? Es handelt sich bei Webanwendungen um eine spezielle Variante von Software, die einer bestimmten Struktur folgt. Finde ich soweit ok.

Ich denke, es hängt auch hier viel vom konkreten Design ab. Man kann sicherlich Login in die Entities tun, aber nur solche, die auch direkt inhaltlich mit der Entity zu tun hat (ein Kollege meinte mal, "Komfortfunktionen sind ok"). Eine Model- bzw. Document-Schicht, die halt nur die Daten des Dokuments/Modells enthält und keine Logikfunktionen ausser solchen, die wirklich direkt mit dem Dokument zu tun haben finde ich absolut ok vom Design her.

Ich hab doch jetzt lange genug erklärt was an diesem Ansatz prozedural ist, oder gibt es da noch unklarheiten?
Login hat meist nix mit der Domäne zu tun und gehört daher meist nicht ins Domänenmodell.

Ich finde den Ansatz von maki durchaus interessant, weil ich meinen Entity intutiv auch immer fachliche Logik hinzufüge wie z.B. beim Mitarbeiter gehalt berechnungen oder ähnliches.
Aber wo ich mir noch nicht so ganz im klaren bin ob ich das Model/Entity etc. so aufblasen würde, dass ich da irgendwelche Dienste oder Repos rein machen(injecten?) würde. Das birgt doch die Gefahr, dass das Model nicht weiter verwendet werden kann, da die (ganze?!?) Logik in den Entity verankert ist.
Ich kenne Anwendungen da sind die Datenstrukturen gleich die BusinessLogik aber unterschiedlich. Da stelle ich mir es schwer vor mit der Wiederverwendung.

Nur nochmal ob dich richtig verstehe maki du würdest auch "Dienste" in die Entity/Models mit reinmachen (injecten?)? Falls ja das würde doch für die Wiederverwendung bedeuten, dass das Entity/Model nicht ohne diesen "Dienst" wiederverwendbar ist oder?

PS: Wenn du ein kleines Beispiel-Projekt daheim hast (oder im Netz), wo diesen Weg aufzeigt hätte ich interesse das mir mal anzuschauen, vielleicht macht es dann **klick**.

Nehmen wir mal an so ein Architekturaufbau ist wirklich besser (kann ich nicht beurteilen):
Würden es doch viel mehr Projekte einsetzen oder?

Wieso sollte das Modell nicht weiter verwendet werden können?
Bitte nicht vergessen, das DDD 2 Arten von Diensten kennt: DomainServices (für Dinge die in keine Entity passen) und ApplicationServices,letzteres ist sowas wie eine (Remote) SessionBean.
Domänobjekte kennen nur andere DomänenObjekte (Repositories, Factories, DomänServices, etc. pp.).

Bücher & Beispiele gibt es schon einige, die Grundlagen sind nicht so komplex (Entities, ValueObjects, Aggregates, Repositories, Factories, DomainServices, ApplicationServices, Specifications, etc.), die Komplexität kommt durch die eigene Domäne, es geht nicht um den konkreten Aufbau der Entities, sondern um das Zusammenspiel der "Bausteine".
Genau das ist auch der empfohlene Einsatzzweck für DDD: komplexe Problemdomänen

Hier noch ein paar Links:
Fowler über das "Anemic Domain Model" (oder warum JEE meist prozedural ist): AnemicDomainModel

Wiki Artikel über das "Anemic Domain Model" (und wieder, JEE ist prozedural): Anemic Domain Model - Wikipedia, the free encyclopedia

Wiki Artikel zu DDD: Domain-Driven Design ? Wikipedia

Kann Evans Buch über DDD nur empfehlen, selbst wenn man kein DDD einsetzt, sind einige sehr gute Modelierungstechniken drinn imho (Seiteneffekte vermeiden durch immutable ValueObjects, etc. pp.).

 

[Gast2]

Danke erstmal für die ausführliche Antwort.
Hab grad wenig Zeit zum Lesen, darum nett dass du auf meine Ahnungslosigkeit so ausführlich antwortest, dann bekommt man wenigstens mal einen 1. Eindruck zum Thema. =)

Es gibt viele verschiedene Wege zum Ziel zu kommen...

Das stimmt, darum ist so eine Diskussion auch immer wieder interessant um sich von neuen/anderen Ideen berieseln zu lassen, um sich selber weiterzuentwicklen =).

Wenn deine Entites schlau sind, dann brauchen sie eben Repos, Factories etc. pp., also Dinge, die sonst in Services gebraucht würden.
Es ist nix anderes als eine "Verlagerung" der Abhängigkeiten, (Application-)Services werden sehr "dünn", rufen nur noch Domänenobjekte auf, diese machen den Rest.

Okay wie du gesagt hast, hat man dann quasi die Schichten verlagert.

Wieso sollte das Modell nicht weiter verwendet werden können?
Bitte nicht vergessen, das DDD 2 Arten von Diensten kennt: DomainServices (für Dinge die in keine Entity passen) und ApplicationServices,letzteres ist sowas wie eine (Remote) SessionBean.
Domänobjekte kennen nur andere DomänenObjekte (Repositories, Factories, DomänServices, etc. pp.).

Ja ich muss zugeben mir fehlen noch die Begrifflichkeiten der Fachwörter und auch die Trennung zwischen den Services, die in die Entity kommen und die nicht reinkommen würden. Ich versuch das gerade an deinem Beispiel Person/Mitarbeiter durchzugehen.
Stell mir das grad so vor:
Abteilung kann mehrere Mitarbeiter haben.
Mitarbeiter hat eine Methode berechneGehalt und die Abteilung eine Methode berechneKosten oder wären das ApplicationServices?

Hast du DDD schon in einem Projekt eingesetzt bzw. gesehen oder beschäftigst du dich "nur" privat damit?
Würdest du persönlich eine neue (JEE) Software darauf aufbauen?

 

[FArt]

War das auf meinen Post bezogen?
Ich denke bei einem großer Software ist es auch nicht so leicht, einfach mal die ganze Architektur umzubauen. Aber bei neuer Software ist es was andereres, da geht es und es könnte einen neueren(besseren) Weg gehen.

Nein, war auf mehrere Posts bezogen.

Wenn die Softwarearchitektur in einem Projekt über lange Zeit nicht besonders beachtet wurde muss man natürlich bedenken, ob der Umstand die Wartung negativ beeinflußt oder nicht. Denn regelmäßig refaktorieren kann man eigentlich in jedem Zustand immer mal wieder durchführen. Auch größere Refaktorierungsarbeiten (mit entsprechender QS Phase danach).
Die weichen Kosten einer schlechten oder nicht vorhandenen Architktur werden gegenüber den harten Kosten einer Konsolidierung oft falsch eingeschätzt, meist zu Ungunsten der Konsolidierung.

Bei neuen Projekten aber gibt es sicher keine sinnvollen Alternativen, zumindest wird es schwer, diese zu verargumentieren.

 

[maki]

Okay wie du gesagt hast, hat man dann quasi die Schichten verlagert.

Nein, die Schichten haben sich nciht verlagert, in JEE terminologie wäre dass die Businessschicht.
Die Abhängigkeiten und Logik sind jetzt nicht mehr komplett in den ApplicationServices, sondern im Domänenmodell, und letzteres ist kein reines Datenmodell mehr sondern hat auch verhalten.

Ja ich muss zugeben mir fehlen noch die Begrifflichkeiten der Fachwörter und auch die Trennung zwischen den Services, die in die Entity kommen und die nicht reinkommen würden. Ich versuch das gerade an deinem Beispiel Person/Mitarbeiter durchzugehen.
Stell mir das grad so vor:
Abteilung kann mehrere Mitarbeiter haben.
Mitarbeiter hat eine Methode berechneGehalt und die Abteilung eine Methode berechneKosten oder wären das ApplicationServices?

Wie gesagt, lies dir mal das Buch an/durch, ist zuviel für ein paar Posts in einem Internetforum
Wo das Mitarbeitergehalt berechnet wird kommt auf die Domäne an, kann Person sein, kann ein DomänenService sein.
Beispiele für ein komplexes Domänenmodell sind eben auch komplex, an einfachen Beispielen erkennt man nicht richtig wozu das gut ist.

Im Moment setzte ich DDD "nach dem Buch" nur privat in "Spielfragmenten" & Testprojekten ein, aber zwischen Entities und immutable ValueObjects zu unterscheiden kann man überall nutzen und davon profitieren, gleiches gilt für andere Abstraktionen aus DDD. Geplant ist ein kleines Testprojekt: GWT, Guice/Gin, EclipseLink (oder besser gleich JDO?)
Aber wie das so ist im richtigen leben kommt eben immer etwas dazwischen.. ist in Arbeit
Finde im Moment nicht so viel Zeit für GWT wie ich gerne hätte, müsste noch eine Lösung für DTOs finden, etc. pp.

Die Kunden wollen meist eh nur "einfache" CRUD Anwendungen, dazu kommt dass es Voraussetzungen gibt um DDD einsetzen zu können, eine der wichtigsten: Man braucht einen Domänenexperten (jemand, der jede fachliche Frage beantworten, keinen "Proxy"/Flaschenhals der jemanden anders fragen muss ), und den bekommt man in der Praxis recht selten.
Dann braucht man auch Kollegen die da mitmachen wollen.. ist schwierig, die meisten kennen eben nur den "standard" JEE Weg.