Is an “order” a concept or an app? I quote Daniel’s thoughts on an email stream, in order to port the discussion to this forum:
" I’ve been pondering exactly this example (but thinking about Amazon and how I’d describe its behavior with concepts). The way I currently see it is that there is a concept for an item type in a catalog (a book with an ISBN, for example); a concept of an item that is purchased (I might call this concept “shopping cart” because it has actions for changing quantity, submitting the order, etc); a concept of a payment in return for some goods; a concept of a warehoused item, with issues of being in stock, finding the item, etc; a concept of packaging, perhaps, in which multiple items are assembled into a box; a concept of a shipped item that has a manifest, tracking etc; and then finally concepts such as return merchandise authorization. In a system like Amazon’s, all of these must be synchronized together. In a conventional implementation, you might have a single order record with fields corresponding to each of the concepts (and some applying to more than one concept). Now the question that you seem to be asking is: is there a single concept that somehow fits all of these concepts together, and has in its operational principle the fact that an item is usually bought, stocked, packaged, shipped, returned, etc."
Indeed, it seems that we could see an order as an object which purpose is traceability of the transaction, which computes the current statuses (ordered, paid, packed, shipped…) and keeps track of the full history of events. It is an object which has memory and which is stateful.
In terms of usage, an order file should be accessible by the customer service, by the customer herself on her personal page, but also by bots which track pending orders, lost orders, claims, and so on.
In this regard, it looks like there would be an order status and order history concepts, which would be synced by an order app with events happening in the billing and logistics systems.
But an order is also more than that. It is foremost complex business logic, which holds the rules binding the actions together, for example that you issue a bill only after shipping, or that you accept returns 90 days after purchase. Of course these rules may themselves be depending on the customer VIP status, or on the product type, or some logistics constraints. Object logic seems to sit inside concepts rather than apps, if I am not mistaken?.. But given the flexibity required on “business logics” should’nt we make that a concept on its own sake, which would be attached to a particular order given the meta-rules outlined above?