0

I'm trying to apply some DDD concepts and i'm just wondering what makes more sense: for an entity to invoke its own methods, or for the user (actor) to do so?

For example, let's say we have an Appointment entity. A user is able to cancel the appointment only if s/he is the owner of that appointment (so we need to check that the user has the proper permissions before we can allow that action). We can do this one of two ways:

pseudocode

// method #1
User.Cancel(a *Appointment) result

// method #2
Appointment.Cancel(u *User) result

The bounded context is "Appointments", but it seems to make more sense for a user to invoke behaviours on the entity than the other way around. Which way is better and why?

user7467314
  • 725
  • 1
  • 6
  • 10

1 Answers1

1

First of all you need to determine what is the Aggregate root (AR), the User or the Appointment. In order to determine that you should inspect the business invariants that must be protected, you should see what is the transactional boundary. There is a very nice article here. An AR is an entity that is used to access all its sub/nested entities.

So, there will be an AR and a sub-entity (the other entity in your design) or two ARs, depending on your design.

Then, you acces that command method on the aggregate by specifying only the ID of the other entity, and not the hole object. 

Appointment.Cancel(uId *UserID)

Or

User.Cancel(aId *AppointmentID)

Now, the permission checking is in general a behavior that doesn't naturally belong in an Aggregate. That verification is done before the method is called. The aggregates design should not be influenced solely by this permission thing. For example a secretary could also cancel an appointment, not only the participants. Permission checking is in another bounded context.

From what I understand so far from your domain the Appointment should be an AR and your code should look like this:

Appointment.Cancel(byWhom *UserID)

One last thing, if you follow the CQS pattern then that method does not return anything.

Constantin Galbenu
  • 16,951
  • 3
  • 38
  • 54
  • Thanks for the answer. Everything is clear except for when you say that permission checking does not belong in an aggregate. I thought that's what aggregates were for -encapsulating domain knowledge and enforcing invariants. To use your example, shouldn't the appointment `AR` know what a Secretary domain object can and cannot do? – user7467314 Apr 23 '17 at 22:04
  • 1
    The authorization is a cross cutting concern and thus is a generic sub-domain. In the DDD book by Eric Evans, in the Implementing DDD book and in all other sources this is implementid as another BC. You could read more here: http://stackoverflow.com/a/23485141/2575224 or just search "permission checking ddd" on google – Constantin Galbenu Apr 24 '17 at 00:55