了解领域驱动设计答案

【问题标题】：Understanding Domain Driven Design了解领域驱动设计
【发布时间】：2011-03-02 12:12:08
【问题描述】：

我已经尝试了解 DDD 几个星期了。它非常混乱。我不明白我是如何组织我的项目的。我有很多关于 UnitOfWork、Repository、Associations 的问题，而且不胜枚举......

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

Album and Tracks

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

我应该将 Tracks 公开为 Album 上的 IList/IEnumerabe 属性吗？如果是这样我如何添加专辑？或者我应该公开一个 ReadOnlyCollection 的曲目并公开一个 AddTrack 方法？
如何加载专辑曲目 [假设延迟加载]？ getter 是否应该检查 null，然后在需要时使用存储库来加载曲目？
我们如何组织程序集。就像每个程序集有什么？ Model.dll - 它只有域实体吗？存储库在哪里？接口和实现。我可以在 Model.dll 中定义 IAlbumRepository 吗？ Infrastructure.dll：这应该有什么？
工作单元在哪里定义？存储库和工作单元如何通信？还是应该？例如。如果我需要向专辑中添加多个曲目，是否应该再次将其定义为专辑上的 AddTrack 或者是否应该在存储库中有一个方法？不管方法在哪里，这里如何实现工作单元？
UI 应该使用 Infrastructure..dll 还是应该有 ServiceLayer？

我的问题有意义吗？

问候

【问题讨论】：

重要的是要记住，DDD 主要是关于无处不在的语言，一种使用客户和程序员都能理解的术语与客户交流的方式。程序的设计是次要的，尽管很重要。阅读 Eric Evans 关于 DDD 的书可能是值得的。
只是想提一下，使用程序集来组织代码是我的一个小烦恼，这就是命名空间的用途。程序集适用于您需要在多个项目之间共享代码，但又不想将所有内容都纳入其中的情况。通过将架构层拆分为单独的 dll，您所做的只是更长的编译时间和更长的应用程序加载时间。
InfoQ 提供了关于 DDD 的入门读物，这是 Eric Evans 的书：infoq.com/minibooks/domain-driven-design-quickly
您可能会从查看示例应用程序中受益 - stackoverflow.com/questions/540130/…

标签： dns repository domain-driven-design repository-pattern

【解决方案1】：

问题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 使用。

将曲目添加和删除到专辑的编写方法。在这些方法中，您可以添加额外的逻辑。

【讨论】：