CODEWITHSUNDEEP
c#design-patternsdomain-driven-design
Rohan West
Rohan West

Reputation: 9298

Communicating between domain objects

I am trying to find a pattern that can be used to communicate between domain objects.

I want to commit changes to the domain objects if conditions in both objects are satisfied.

This is what I have come up with so far. In the example the domain objects capture the state of a task. DoSomeWork is invoked on t1, if some condition is met a UnitOfWork is created wrapping a completion handler. The UnitOfWork is passed to t2 and if the condition is correct then the unit of work is completed.

var t1 = new Task();
var t2 = new Task();

var unitOfWork = t1.DoSomeWork();
t2.DoSomeOtherWork(unitOfWork);

Assert.IsTrue(t1.WorkComplete);

public class Task
{
    public Boolean WorkComplete { get; private set; }

    public UnitOfWork DoSomeWork()
    {
        UnitOfWork result = null;
        if (/* Some condition */)
        {
            result = new UnitOfWork(() => this.WorkComplete = true);
        }
        return result;
    }

    public void DoSomeOtherWork(UnitOfWork unitOfWork)
    {
        if (/* Some condition */)
        {
            unitOfWork.Complete();
        }
    }
}

public class UnitOfWork
{
    protected Action Handler { get; private set; }

    public UnitOfWork(Action handler)
    {
        this.Handler = handler;
    }

    public void Complete()
    {
        this.Handler.Invoke();
    }
}

Upvotes: 2

Views: 225

Answers (3)

guillaume31
guillaume31

Reputation: 14064

I'm not sure if the domain really needs to be involved here.

Is a Task really an identified domain concept in your ubiquitous language ? Will the logic about the chain of tasks remain identical even in an application with a different user experience (think mobile/tablet app) ?

I usually use UnitOfWork's at the Application level, not Domain level. I see them more as business transactions that cover a use case, a user's flow of work.

In contrast, I orchestrate Domain transactions inside specific Domain Services, with regular transaction scopes rather than UoW's. But even then, my domain entities aren't aware of the overarching transaction. It seems odd to me that an entity should know about the completion state of a domain process and the next object in the chain.

For long-running domain transactions, you might be interested in the concept of Sagas.

Upvotes: 0

GraemeMiller
GraemeMiller

Reputation: 12253

Domain events probably would do it. They allow easy inter-aggregate communication - Eric Evans described as key element he wished had been included in the blue book

A domain event allows you to describe that something has happened in your domain and then other parts of the domain can respond to it. E.g. OrderConfirmed may be an event and then it could be handled be processes within other contexts. Someone might have to pack it etc. someone might have to send an email confirming it. Different subscribers are then responsible for reacting to that event. Domain Events are named for things that have happened. These contrast with commands which are requests you are making to the domain which may not be able to happen. A domain event has occurred

Jimmy Bogard explains usage in his DDD primer series

Upvotes: 3

David Osborne
David Osborne

Reputation: 6791

Have you considered events via the Event Aggregator pattern?

Upvotes: 0

Related Questions