Domänenmodelle

Das Domänenmodell ist das Herzstück vieler Softwaresysteme.
Die gängigen Kernabstraktionen sind:
- Entität
- Datentyp
- Enumeration
- Attribut
- Referenzen

Komischerweise werden Domänenmodelle in den seltesten Fällen wirklich mit diesen Mitteln beschrieben. In EJB 3.0 werden sie z.B. in Java mit Klassen, Feldern, Methoden und all den anderen Konzepten beschrieben:

@Entity
@Name("user")
@Table(name="users")                                                                    
public class User implements Serializable {
  private static final long serialVersionUID = 1881413500711441951L;
 
  private String username;                                                             
  private String password;
  private String name;

  public User(String name, String password, String username) {
     this.name = name;
     this.password = password;
     this.username = username;
  }

  public User() {}                                                                     

  public String getPassword() {
     return password;
  }

  public void setPassword(String password) {
     this.password = password;
  }

  @NotNull
  public String getName() {
     return name;
  }

  public void setName(String name) {
     this.name = name;
  }

  public String getUsername() {
     return username;
  }

  public void setUsername(String username) {
     this.username = username;
  }

}

Bei Ruby on Rails werden Domänenmodelle mit einer Mischung aus DDL (aus dem SQL Standard) und Ruby definiert :

CREATE TABLE 'users' (
  'username' varchar(20),
  'password' varchar(20),
  'name' varchar(20) NOT NULL
)

class User < ActiveRecord::Base

end

Das ist schon ein bischen kompakter, sind aber leider zwei Artefakte.
Ausserdem müssen z.B. Beziehungen zwischen zwei Domänenobjekten in der Ruby Klasse beschrieben werden. Der Foreignkey constraint aber zusätzlich in der Datenbank hinterlegt werden (über DDL). Eine Verletzung des DRY-Prinzips.

Warum aber unbedingt irgendeine Sprache wiederverwenden? Wir können doch eine eigene definieren. Wie wärs z.B. so:

entity User {
  String username;                                                          
  String password;
  notNull String name;
}

Daraus lässt sich z.B. die obige EJB3.0 Entity ableiten. Besser noch: Ich generiere mir eine Javaklasse, die alle möglichen "Features" enthält, die für (meine) Domänenobjekte interessant sind.
Um nur einige zu nennen (getter und setter sind klar):
- gemanagete Referenzen
- Observer pattern
- containment Referenzen
- Treewalker / Visitor
- spezieller Reflectionlayer (der die Konzepte Entity, Attribute, Reference,... kennt)

Gute Idee? Hier geht's lang -> http://www.openarchitectureware.org