3

I always see standard Order classes implemented with a "Status" property, but I don't feel comfortable with that. Isn't the status a property of the fulfillment process instead of the order itself? What about orders that can be subject to different fulfillment processes?

5

Isn't the status a property of the fulfillment process instead of the order itself?

It is. The Status shouldn't belong to an Order, neither the taxes or other financial details. When modelling the Order concept it should be modelled according to what it is (domain definition) and NOT according to how it's displayed or used by other domain processes.

A customer doesn't order statuses, discounts or taxes. He orders products/services and attaches vouchers or coupons codes. And that's all an Order should contain. Financial details and order fullfilment tracking are use cases of the concept NOT parts of the concept.

What a client or store employee sees is a view model which contains more than the document Order. It contains inventory data or invoice data or shipping data. So the Status is actually a concept of the Order fulfilment process (saga) which can be organized in other processes (product reservations, billing, shipping) each with their very own statuses.

OP, you're right: Status has no place in Order's definition. It's just the easy way out to define an improper model mixing together different subdomains.

| improve this answer | |
  • Thanks for your response, great to know that I'm not alone! Do you know where can I find a proof of concept of an alternative, more natural way to model this? (article, sample code, open source application, ...) – user3013752 Feb 5 '14 at 20:23
  • I'd suggest to just do it. Or wait until I write an article about it :)) – MikeSW Feb 5 '14 at 20:31
  • I struggled for quite a few days trying to build an alternative, yet feasible model but couldn't find anything that made me happier. I finally reached analysis paralysis recently, so I'll stick a Status property to my class and patiently wait for your article! If you accept suggestions for your articles, I have like another zillion questions like this! :) – user3013752 Feb 5 '14 at 20:49
  • Noooo... don't stick the status to a class that doesn't need it. Create something like OrderFullfilmentTracker (bad name) and stick the Status to it. – MikeSW Feb 5 '14 at 21:53
  • My current approach is a FulfillmentReport property in the Order class, which contains all the properties relevant to the fulfillment process (status, etc.). Would you have a property in your Order linking it to the corresponding OrderFulfillmentTracker? I guess no, and the problem with completely disconnecting the Order from the status is that it causes too many problems with queries, because you (almost) always want to retrieve the Order with the fulfillment information. Dealing with that in an elegant way is challenging. Any suggestions? – user3013752 Feb 5 '14 at 22:10
2

Isn't the status a property of the fulfillment process?

No, it's the status of an order, unless you plan on attaching a fulfillment process to the order. Normally, that's not how it works; think of a fulfillment process as a "factory" that processes orders. A property on such a process might look like "how many orders are currently in the shipment queue?"

Your customer isn't going to look up a fulfillment process when he wants to know what the status of his order is; he's going to look up his order. As the programmer, you're going to want to maintain that status in the Order record (or an OrderStatus table), not some fulfillment process (although the list of possible statuses may be influenced by that process).

| improve this answer | |
  • The factory idea is interesting, your response got me thinking for a while. I guess it comes down to defining what an order is. I tend to see orders as commands, and I think in that case the Staus makes no sense (the status of a command... what's that?) instead, it's actually the status of its execution (hence, the status of the associated fulfillment process). Is this the same way you think of an order? – user3013752 Jan 27 '14 at 21:41
  • An order is an object, not a method. It is a container for items, quantities and prices. – Robert Harvey Jan 27 '14 at 21:42
  • Would it be wrong to say that it's a command to purchase specific quantities of a set of items at a given price? Why? – user3013752 Jan 27 '14 at 21:55
  • 1
    No, that's a command alright. But you don't execute that command until you gather the specific quantities of a set of items at given prices from the customer. And when you do execute that command, it creates an object called an order, and that order gets fed into the order fulfillment process. The state of that order (including its status) should travel along with that order. – Robert Harvey Jan 27 '14 at 22:12
  • I get it, but can you help me define more formally what that order is? That would definitely end my nightmare :) Thanks! – user3013752 Jan 27 '14 at 22:52
2

Isn't the status a property of the fulfillment process instead of the order itself?

Not necessarily. The fulfillment process may have a contributing status for the Order, but it's possible that there are multiple fulfillment processes. Final status needs to remain with the Order.

What about orders that can be subject to different fulfillment processes?

Exactly. You've provided the counter example showing why Status should belong to the Order. Think about how you would track an order that was fulfilled through two separate processes. Work on the order could be complete in one fulfillment route but not even started within another.

| improve this answer | |
  • I envision an order being fulfilled by either one process or another, but not by more than one, and I could easily track the "status" of the order by associating the fulfillment process (process instance, so to speak) with the order, and having the property there. An order doesn't even need to know what kind of process it's associated with. Even things like "Cancel" an order make more sense to me in terms of the fulfillment process (what you want to Cancel is in fact the fulfillment process that is being carried out). Does this make sense? – user3013752 Jan 27 '14 at 20:39
  • 2
    Think of it in terms of your business domain. People interact with orders, they don't interact with a process. And while you have a point that the fulfillment process creates the action that affects the order's state, the order status still belongs to the order. You could always pass an Order into the FulfillmentProcess() which can then return a state for the process. The Order can then update itself based upon replies from the fulfillment process(es). – user53019 Jan 27 '14 at 20:42
  • I really don't see why the fact that people don't interact with the fulfillment process implies that an order object must carry a Status property. Could you please elaborate on this? As I commented earlier, if an order is a command I see no reason why it should have a Status (execution status?) property, tying it completely to the fulfillment process it will be subject to. Either this has been modeled incorrectly since forever, or I just can't understand what the rationale behind it is. I'm still as confused as I was when I posted the question. – user3013752 Jan 29 '14 at 21:24
  • 1
    People interact with a View. The view model is quite different than the Order domain object. The view model has a Status, the Order doesn't need it as the Order is most of the time an immutable object (it can vary from domain to domain) – MikeSW Feb 4 '14 at 21:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.