洋葱架构：核心与域答案

【问题标题】：Onion Architecture: Core vs Domain洋葱架构：核心与域
【发布时间】：2015-09-28 01:49:50
【问题描述】：

我研究Onion Architecture 已经有一段时间了，我分析了几个示例VS 的解决方案，仍然无法理解Onion Architecture 中Core 和Domain 之间的区别。

在this 解决方案核心（项目）位于域（解决方案文件夹）内。
Here 没有核心，只有域
在 Jeffrey Palermo 的 CodeCampServer 示例应用程序中，Core 中有 Domain。所以，基本上看起来Core 是由Domain 和Services 组成的。
在this xDriven项目中Core分为Core.Application和Core.Domain

我完全糊涂了。你能解释一下，在这种架构中Core 和Domain 之间的实际区别是什么？

例如，我有这门课。简单的棋盘游戏，例如井字游戏。它绝对是无处不在的语言，所以我应该在域内的Entities 文件夹中创建它吗？以及 Core 中的域本身？

public class Game
{
    public GameState State { get; set; }
    public Board Board { get; set; }
    public IEnumerable<Player> Players { get; set; }

    public bool Move(int playerId, int field)
    {
        //Check if Player's move will finish game. If yes, return true
        return false;
    }
}

【问题讨论】：

标签： c# .net domain-driven-design onion-architecture

【解决方案1】：

在我看来，只要你遵循Onion Architecture 的指导方针，项目的实际命名并不那么重要。它更多是关于构建您的项目以轻松使用它并对其进行推理。

拥有位于中心的独立对象模型很重要。然后围绕该模型构建应用程序。

我完全糊涂了。你能解释一下，在这种架构中，Core 和 Domain 之间的实际区别是什么？

您可以将Core 视为您应该独立的架构中心模型的各个方面的聚合。在那个Post about Onion Architecture 中有Application Core，它包含Domain Model、Domain Services 和Application Services。这取决于您在Core 中拥有的项目。也许你的情况不需要介绍Application Services。

总之，构建您和其他人易于推理的解决方案。让您的解决方案中的结构成为其他使用该项目的人的指南。我的意思是，如果有人必须在项目中实现新功能，解决方案应该指导他应该把例如Domain Entities 等放在哪里。我最后的想法是，比结构化（命名）项目最重要的是继续专注于坚持Onion Architecture as described here 的四个原则

【讨论】：

【解决方案2】：

为了总结 Arkadiusz K 的观点，即核心是一个重载术语，在 DDD 语音中，核心域也可以用于与（支持/通用）子域相反。也就是说，您有一个或几个关键领域是您的核心业务，而其他领域则是辅助性的，可以外包或购买作为现成的解决方案。

解决方案空间中的域和子域的对应关系是有界上下文，这些可以在代码中表示为命名空间。这可能是某些示例的作者所想的。

【讨论】：