Луковая архитектура: Core vs Domain

Question

Я изучаю Onion Architecture довольно давно, я проанализировал несколько примеров VS-решений и до сих пор не могу понять разницу между Core и Domain в Onion Architecture.

• В решении this Ядро (проект) находится внутри домена (папки решений).
• Here нет ядра, только домен
• В CodeCampServer образце приложения Джеффри Палермо, есть домен внутри Core. Таким образом, в основном это выглядит как 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; 
    } 
} 

Answer 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, как described here

Answer 2

для того, чтобы добавить до точки ARKADIUSZ K, что ядро ​​перегруженной термин, в DDD речь ядра домена также может быть использован, в отличии от (Вспомогательного/Generic) субдомена. То есть у вас есть один или несколько важных доменов, которые являются основным бизнесом и другими доменами, которые являются вспомогательными и могут быть переданы на аутсорсинг или куплены как готовые решения.

Соответствие доменов и поддоменов в пространстве решений ограничено Контексты, и они могут быть выражены как пространства имен в коде.Возможно, это и было тем, что имели в виду авторы некоторых примеров.