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?
views:
78answers:
2Unless 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.
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!