Understanding Domain Driven Design

Question

I have been trying to understand DDD for few weeks now. Its very confusing. I don't understand how I organize my projects. I have lot of questions on UnitOfWork, Repository, Associations and the list goes on...

Lets take a simple example.

Album and Tracks

Album: AlbumId, Name, ListOf Tracks
Tracks: TrackId, Name

Should i expose Tracks as a IList/IEnumerabe property on Album ? If that how do i add an album ? OR should i expose a ReadOnlyCollection of Tracks and expose a AddTrack method?
How do I load Tracks for Album [assuming lazy loading]? should the getter check for null and then use a repository to load the tracks if need be?
How do we organize the assemblies. Like what does each assembly have? Model.dll - does it only have the domain entities? Where do the repositories go? Interfaces and implementations both. Can i define IAlbumRepository in Model.dll? Infrastructure.dll : what should this have?
Where is unit of work defined? How do repository and unit of work communicate? Or should they? For example. If I need to add multiple tracks to album, again should this be defined as AddTrack on Album OR should there a method in the repository? Regardless of where the method is, how do I implement unit of work here?
Should the UI use Infrastructure..dll or should there be ServiceLayer?

Do my questions make sense?

Regards

It's important to remember that DDD is primarily about the ubiquitous language, a way to communicate with the customer using terminology that both the customer and the programmer can understand. The design of the program is a secondary, although important consideration. It might be worthwhile to pick up Eric Evans' book on DDD. — Robert Harvey, Jun 11 '10 at 05:14
just wanted to mention, its a pet peeve of mine to use assemblies to organize code, that is what namespaces are for. assemblies are for when you need to share code between multiple projects, but don't nessicarily want to bring everything in. all you are doing by splitting out archetecture layers into seperate dlls is longer compile times, and longer app load times. — Matt Briggs, Jun 11 '10 at 05:14
InfoQ offers a primer on DDD which is a filleting of Eric Evans's book: http://www.infoq.com/minibooks/domain-driven-design-quickly — APC, Jun 11 '10 at 05:52
You might benefit from checking out sample applications - http://stackoverflow.com/questions/540130/good-domain-driven-design-samples — Arnis Lapsa, Jul 01 '10 at 12:20

score 0 · Answer 1 · edited Aug 29 '14 at 10:49

Question 1, I suggest a structure like this:

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
{

}

Write a public IEnumerable property for tracks to allow readonly access and for cycles.

The protected property holds tracks and can be used by the ORM.

Write methods to Add and Remove tracks to album. In these methods you can put additional logic.

Understanding Domain Driven Design

1 Answers1