DDD Logic implementation

  softwareengineering

Ive been tossing this around in my head for awhile. But I’m working on a project that consists of an Order, that has a OrderStatus. There is quite a bit of logic that revolves around the status and changing of it.

I’ve got my fake order class below and I’m curious on the possible ways of implementing this logic – I’ve run into issues because when calling ‘Approve’ for example, ‘Approve’ doesn’t know what the actual ‘OrderStatusId’ for the corresponding status is, and I’m not sure the correct way of relaying that information or doing it some other way entirely.

I’m curious how others here have implemented something similar. Currently I’m doing it in a domain Service instead that just has an ‘Approve’ and looks up the correct status. But that seems to be taking away a lot of the logic from the domain model.

Order
{
   Guid Id
   Guid OrderStatusId
   
    void Approve();// What is the correct OrderStatusId to set? Would need db lookup
    void Deny();
    void WithDraw();
 }

Would it make sense to pass a domain service to these calls like so:

  Approve(IOrderStatusResolver resolver)
  {
    var approvalStatus = resolver.ResolveStatus(OrderStatus.Approved);
    this.OrderStatusId =approvalStatus.Id
    //More logic etc.
  }

Thanks!

9

Having the status handling separate from the actual order is the way for you to go.

A status is always something that is related to some process. But the responsibility of the order is to say what items are ordered and by whom (and possibly other things). The status of the order is the location of that order in said process and so stems from a completely different responsibility. If the order needs to be presented with a status than this is really just a presentation issue and not one that must be dealt with in the core business logic. It should normally also not be possible to set an order state directly. The state is produced by providing the state machine of the order process with inputs and let that state machine figure out what the state of the order is.

3

Having an OrderStatusId on the object is a symptom of database first design and should be avoided unless you have some dynamically editable set of states

The easiest solution is simply to use an enum

I see from your comment that you do indeed have an editable list of states. Which begs so many questions. (What happens when they delete “Approved” from the list of order states?)

In this case presumably “Approving” an order is in of itself a user configurable action, and you can give them a drop down of states to choose from, saving the ID to be used with the “Approval” action

3

LEAVE A COMMENT