views:

78

answers:

2

Sorry for the naive question; I'm still working through understanding DDD. Let's say I have an IOrderService. Is this where I would have a method GetNewOrderID? Or, I guess more generally, what is the right way to allocate new orders in a DDD scenario?

A: 

Unless I've misunderstood DDD then it's not a naive question - instead when it's not clear where the responsibility then not enough of the domain has been investigated / understood. Things like:

  • What is the format of the Order ID, what information goes into a single OrderID.
  • Is there a requirement to save anything at the point of getting a new OrderID - like who requested it, etc.
  • Is there a requirement that requested, but unused Order IDs be freed up?

One or more of these requirements might clarify the situation.

Paul Hadfield
@Paul Hadfield: Thanks! Let's say that order IDs are sequentially allocated, there might be a need to save when the order ID was reqeusted, and there is no requirement that requested but unused order IDs be freed.
JonathanS
In this case and with the information you've provided I would say that yes, it could be a method defined by the interface, and implemented in classes that inherit from the interface. Again, as I see it DDD is a way of seeing what is to be developed. Good design and TDD is then used to make sure that is implemented in stable way that is testable. In that if you wanted a sequential number, then that should be centrally (a service) handled so it copes with multiple users. Then whether the OrderID is actually an identity column in a db or not is up to the system design.
Paul Hadfield
+1  A: 

I like to listen to the words that the business use. If they talk about, for instance, catalogue orders and phone orders both being sources of orders, I might have an OrderSource or IOrderSource instead of an OrderService - the last is code-speak instead of business-speak. I might have two implementations, or just one which uses an identifier to say "this is from a phone", depending on how different the processes are.

If the business people talk about getting IDs from their service, then yes, do that. It's more likely though that they talk about receiving an order from an OrderSource, dispatching it to the Warehouse or creating an OrderForm and receiving a ReferenceNumber. That ReferenceNumber may well be the primary key, but it's probably not an Id.

The language that the business use can guide you to write software which matches their process well. Keeps things easy to change and helps you spot if there's an aspect of the domain which could use some learning. The design patterns are all the same that you're used to; I just don't call my code after those if the business have some better terms. See DDD's Ubiquitous Language, and good luck!

Lunivore