洋葱架构：核心与域名

Question

I study Onion Architecture for quite sometime now, I've analysed few sample VS's solutions and still can't understand the difference between Core and Domain in Onion Architecture .

• In this solution Core (project) is inside Domain (solution folder).
• Here there is no Core, only Domain
• In Jeffrey Palermo's CodeCampServer sample app, there is Domain inside Core. So, basically it looks like Core is made of Domain and Services .
• In this xDriven project Core is divided into Core.Application and Core.Domain

I'm totally confused. Can you explain me, what's the actual difference between Core and Domain in such architecture?

I have for example this class. Simple board game, like tic-tac-toe. It's definitely ubiquitous language, so should I create it in Entities folder inside Domain? And domain itself in 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;
    }
}

Answer 1

In my opinion, as long as you follow guidelines from Onion Architecture the actual naming of projects is not that important. It's more about structuring your project to easily work with it and reason about it.

It's important to have independent object model that is in center. And you build your application around that model.

I'm totally confused. Can you explain me, what's the actual difference between Core and Domain in such architecture?

You can think about Core as a aggregation of every aspect of you architecture center model that should be independent. In that Post about Onion Architecture there is Application Core and it contains Domain Model , Domain Services and Application Services . It depends on your project what you have in Core . Maybe in your case there is no need to introduce Application Services .

So to wrap up, structure your solution that it is easy for you and others to reason about. Let the structure in your solution be guideline for others working with that project. By that I mean, if someone must implement new feature in project, the solution should guides him where he should put for example Domain Entities and etc. And my last thought, the most important thing than structuring (naming) projects is to keep focus on adhering to four tenets of Onion Architecture as described here

Answer 2

To add up to Arkadiusz K's point that Core is an overloaded term, in DDD speech Core Domain can also be used as opposed to (Supporting/Generic) Subdomain. That is, you have one or a few crucial domains that are your core business and other domains that are ancillary and could be outsourced or bought as off-the-shelf solutions.

Domains and subdomains correspondence in the solution space is Bounded Contexts, and these can be expressed as namespaces in code. That might have been what the authors of some of the examples had in mind.