了解领域驱动设计

我一直试图了解DDD几个星期了。它非常混乱。我不明白我如何组织我的项目。我有很多关于UnitOfWork，Repository，Associations的问题，并且这个列表继续...了解领域驱动设计

让我们举一个简单的例子。

Album and Tracks 

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

我应该暴露曲目作为专辑一的IList/IEnumerabe财产？如果那我该如何添加一张专辑？或者我应该公开一个ReadOnlyCollection的轨道并公开一个AddTrack方法？
如何加载专辑曲目[假设延迟加载]？应该吸气剂检查为空，然后使用存储库加载轨道，如果需要的话？
我们如何组织组件。像每个组件有什么？ Model.dll - 它只有域实体吗？存储库在哪里？接口和实现两者。我可以在Model.dll中定义IAlbumRepository吗？ Infrastructure.dll：这有什么用？
定义的工作单元在哪里？知识库和工作单元如何沟通？或者他们应该？例如。如果我需要将多首曲目添加到专辑中，应该再次将其定义为专辑的AddTrack或应该在存储库中有一个方法？无论方法在哪里，我如何在这里实现工作单元？
UI应该使用Infrastructure.dll还是应该有ServiceLayer？

我的问题有道理吗？

问候

来源

2010-06-11 Nihilist

重要的是要记住，DDD主要是关于无处不在的语言，一种使用客户和程序员都可以理解的术语与客户进行交流的方式。该计划的设计是次要的，但重要的考虑因素。拿起Eric Evans关于DDD的书可能是值得的。 – 2010-06-11 05:14:34

只是想提及，它是我的宠物使用程序集来组织代码，这是命名空间的用途。程序集适用于需要在多个项目之间共享代码的情况，但不一定要将所有内容都纳入其中。通过将archetecture图层拆分为单独的dll，您所做的全部工作都是编译时间更长，应用程序加载时间更长。 – 2010-06-11 05:14:42

InfoQ提供了一本关于DDD的入门书，它是Eric Evans书中的一部分：http：//www.infoq.com/minibooks/domain-driven-design-quickly – APC 2010-06-11 05:52:47

问题1，我建议的结构是这样的：

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 
{ 

}

写公共IEnumerable的属性轨道允许只读访问和周期。

受保护的属性包含轨道，可以由ORM使用。

写入方法添加和删除曲目专辑。在这些方法中，您可以添加其他逻辑。

来源

2011-12-22 17:41:30

了解领域驱动设计

回答

相关问题