DDD-principer
Anders Asplund
Fick en fråga av Annica som kan kokas ner till följande:
En entitet kan idag leva utan ett id när den skapas. Detta blir ett
problem i befintlig lösning om man t.ex. vill stoppa in nyskapade
entiteter i ett set för att sedan batcha in dem i db.
En entitet skall egentligen inte få leva utan ett id utan skall få ett
när den föds.
Om man vill följa DDD:s principer så skall entitet inte få leva utan
ett id utan skall tilldelas ett när den "föds". Om man inte har något
naturligt id (t.ex. PersonNummer för Person) utan man vill generera
något så kan UUID vara ett alternativ här.
Alternativt så kan man släppa lite på tyglarna så skulle en delegering
till super i equals vara en alternativ lösning.
Några åsikter om principfasta vi skall vara i dao-fwk?
//Anders
Annica Sunnman
Niklas Gustavsson
> Om man vill följa DDD:s principer så skall entitet inte få leva utan
> ett id utan skall tilldelas ett när den "föds". Om man inte har något
> naturligt id (t.ex. PersonNummer för Person) utan man vill generera
> något så kan UUID vara ett alternativ här.
Detta bör väl vara grundprincipen och bör förklaras tydligare i
Javadocen. Skulle AbstractEntity kanske implementera getId() och ta
ett ID i sin constructor? Dvs, nåt i stil med:
Index: src/main/java/se/vgregion/dao/domain/patterns/entity/AbstractEntity.java
===================================================================
--- src/main/java/se/vgregion/dao/domain/patterns/entity/AbstractEntity.java (revision
70)
+++ src/main/java/se/vgregion/dao/domain/patterns/entity/AbstractEntity.java (working
copy)
@@ -18,14 +18,24 @@
* @author Anders Asplund - <a
href="http://www.callistaenterprise.se">Callista Enterprise</a>
*
*/
-public abstract class AbstractEntity<T extends Entity<T, ID>, ID>
implements Entity<T, ID> {
+public abstract class AbstractEntity<ID> implements Entity<ID> {
private static final long serialVersionUID = 1L;
+ private ID id;
+
+ public AbstractEntity(ID id) {
+ this.id = id;
+ }
+
+ public ID getId() {
+ return id;
+ }
+
På så sätt så tvingar vi användare av APIet att tänka till kring IDt.
Från egen erfarenhet kan jag även säga att det är väldigt lätt att
blanda ihop ID och PK, tror även detta bör förklaras i Javadocen (JPAs
@Id hjälper ju inte heller precis...).
> Alternativt så kan man släppa lite på tyglarna så skulle en delegering
> till super i equals vara en alternativ lösning.
Ser i så fall hellre att man tar bort final från equals() och hashCode().
/niklas
Annica Sunnman
returnerar true for id = null på båda objekten?
I så fall hoppas jag på Niklas sista förslag om inget av de övriga
lösningarna som jag föreslog i issuen är bra nog för DDD...
/Annica
Anders Asplund
> Javadocen.
> Skulle AbstractEntity kanske implementera getId() och ta
> ett ID i sin constructor?
Funderade på något liknande men kan tycka att en implementation blir ganska otydlig om vad som är dess id:
public class Person extends AbstractEntity<PersonalNumber> {
public Person(PersonalNumber pn) {
super(pn);
}
}
men det kanske inte är skäl nog...?
...och vill man generera sitt id på så skulle följande implementation kunna exemplifiera det så här:
public class TestEntity extends AbstractEntity<UUID> {
private TestEntity(UUID id) {
super(id);
}
public static TestEntity newInstance() {
return new TestEntity(UUID.randomUUID());
}
}
> Men ni tycker alltså att implementationen av equals är bra, där equals
> returnerar true for id = null på båda objekten?
Detta borde tämligen bara bli ett problem om man låter databasen generera entitetens id genom att likställa PK och ID. I princip tycker jag inte man borde göra detta, dock förstår jag att det är väldigt smidigt.
>
> Ser i så fall hellre att man tar bort final från equals() och hashCode().
Håller inte med. Per definition(och enl. javadoc) så identifieras en entitet av sitt id, detta kan inte garanteras om man släpper på equals.
En av tankarna från början med ramverket var att få hjälp med boilerplate för ddd-driven design på datalagret. Jag kanske är lite fundamentatlistisk men för mig är vikitgt att hålla på dessa principer då jag tror att det i slutändan resulterar i bättre kod.
//Anders
Anders Asplund
http://groups.google.com/group/dddsverige/browse_thread/thread/5b79e00f1d88557e
//Anders