2010-06-11 8 views
1

J'ai essayé de comprendre DDD depuis quelques semaines maintenant. C'est très déroutant. Je ne comprends pas comment j'organise mes projets. J'ai beaucoup de questions sur UnitOfWork, Repository, Associations et la liste continue ...Comprendre la conception guidée par domaine

Prenons un exemple simple.

Album and Tracks 

Album: AlbumId, Name, ListOf Tracks 
Tracks: TrackId, Name 
  1. Si j'expose pistes comme propriété IList/IEnumerabe sur l'album? Si c'est comme ça, comment ajouter un album? OU dois-je exposer une ReadOnlyCollection de pistes et exposer une méthode AddTrack? Comment charger les pistes pour l'album [en supposant un chargement paresseux]? Le getter doit-il vérifier null et utiliser un référentiel pour charger les pistes si besoin?

  2. Comment organisons-nous les assemblages. Comme quoi chaque assemblée a-t-elle? Model.dll - at-il seulement les entités de domaine? Où vont les dépôts? Interfaces et implémentations à la fois. Puis-je définir IAlbumRepository dans Model.dll? Infrastructure.dll: qu'est-ce que cela devrait avoir?

  3. Où l'unité de travail est-elle définie? Comment le référentiel et l'unité de travail communiquent-ils? Ou devraient-ils? Par exemple. Si j'ai besoin d'ajouter plusieurs pistes à l'album, cela devrait-il être défini comme AddTrack sur l'album OU devrait-il y avoir une méthode dans le dépôt? Quelle que soit la méthode utilisée, comment puis-je implémenter l'unité de travail ici?

  4. L'interface utilisateur doit-elle utiliser Infrastructure..dll ou ServiceLayer?

Mes questions ont-elles un sens?

Cordialement

+1

Il est important de se rappeler que DDD est avant tout un langage omniprésent, un moyen de communiquer avec le client en utilisant une terminologie que le client et le programmeur peuvent comprendre. La conception du programme est une considération secondaire, quoique importante. Il pourrait être utile de prendre le livre d'Eric Evans sur DDD. –

+1

Je voulais juste mentionner, c'est une bête noire à moi d'utiliser des assemblys pour organiser le code, c'est ce que sont les espaces de noms. Les assemblages sont pour quand vous avez besoin de partager du code entre plusieurs projets, mais ne veulent pas nessicarily tout ramener. Tout ce que vous faites en séparant les couches d'archétecture en dll séparés est des temps de compilation plus longs et des temps de chargement plus longs. –

+1

InfoQ propose une introduction à DDD, qui est un découpage du livre d'Eric Evans: http://www.infoq.com/minibooks/domain-driven-design-quickly – APC

Répondre

0

Question 1, je suggère une structure comme ceci:

public class Album 
{ 
    public int AlbumId { get; set; } 

    /// <summary> 
    /// Readonly, foreach, public 
    /// </summary> 
    public IEnumerable<Track> Tracks 
    { 
     get { return TrackList; } 
    } 

    /// <summary> 
    /// Protected for repository/ORM 
    /// </summary> 
    protected IList<Track> TrackList { get; set; } 

    public void AddTrack(Track track) 
    { 
     //Here you can put additional logic 
     TrackList.Add(track); 
    } 

    public void RemoveTrack(Track track) 
    { 
     //Here you can put additional logic 
     TrackList.Remove(track); 
    } 
} 
public class Track 
{ 

} 

Ecrire un bien public IEnumerable pistes pour permettre l'accès en lecture seule et pour les cycles.

La propriété protégée contient des pistes et peut être utilisée par l'ORM.

Écrire des méthodes pour ajouter et supprimer des pistes à un album. Dans ces méthodes, vous pouvez mettre une logique supplémentaire.

Questions connexes