CODEWITHSUNDEEP
c#.netarchitecturedomain-driven-design
Antwan Reno
Antwan Reno

Reputation: 123

Domain Services vs Entity Methods in Domain Model

I know the difference between domain and application services. But can't really see the difference between methods in domain entities and domain services:/

I have a game, that has State, Players etc.. It also has methods like AddPlayer, MoveLeft, Jump. Where these methods goes? Should I create naked KOGame with only properties and then KOGameServices with functionality?

Uncle Bob in his article here wrote "An entity can be an object with methods, or it can be a set of data structures and functions."

I don't even want to mention that methods like Move or Jump will have to be also in App Services, in KOGameAPI - cause those methods are needed by UI (through interfaces of course).

Here is my class:

public class KOGame
{
    public GameState State { get; set; }
    public IList<Player> Players { get; set; }
    public int PlayersCount;

    public KOGame()
    {
        State = GameState.New;
        PlayersCount = 2;
        Players = new List<Player>();
    }

    public void AddPlayer(Player player)
    {
    }

    public bool MoveRight(int id)
    {
        return false;
    }

    public bool MoveLeft(int id)
    {
        return false;
    }

    public bool Jump(int id)
    {
        return false;
    }
}

So, wrap up my question: What methods goes to Domain Services and what methods goes to Domain Entities? Having for example Class1 class, when should I create Class1Services class?

EDIT: Just a quick explanation why I choose DDD: I want to create cross platform app and I want to have single layer common for every platform. I choose C#, cause with help of Xamarin I can easily implement single domain model and even services for every platform. I just got stuck at deciding what methods should go to Services and what as a part of entities in Domain Model

Upvotes: 10

Views: 3599

Answers (2)

theDmi
theDmi

Reputation: 18034

If a method logically belongs to an entity, put it there. If there isn't any entity where the method would make sense, put it in a (stateless!) domain service.

For example, a method to move a player should be on the player entity - it feels natural to have it there, because it modifies that specific player.

On the other hand, a method to e.g. calculate the score difference of two players could be implemented as a domain service.

Upvotes: 8

jlvaquero
jlvaquero

Reputation: 8785

If, to acomplish a use case, you need, at domain level, coordinate 2 or more aggregates you put the coordination logic in domain services calling aggregate methods. If just one aggregate is needed then no domain service is involved. Just call aggregate method from app service.

Upvotes: 11

Related Questions