DDD Thought Process for Customers & Orders Relationship

Question

I currently have a database centric web app for my company. For the office staff, the whole system is based around orders. There is an order list page. Warehouse manages his part by reading, preparing and marking incoming orders as 'prepared', 'dispatched' etc..

Telephone staff takes new orders from customers using the same page (access to products and inventory on the same page).

What I understand from what I read up until now, requires clarification before I read further hence I am here. DDD-wise (this is where I am confused) I should only access orders through customers right? In this case if I design my application to be based on Orders, then accessing Customers would be through orders? If so, getting a Customer list would require me to retrieve all orders and access their owners one by one?

I would really appreciate any help with my struggle. Any reading/watching materials and if there are any people who had a similar difficult time when trying to switch their thinking from database-centric to DDD, any experience would be useful.

Answer 1

Even knowing that the system deals with sales, customers, and orders is not enough information to provide you with specific guidance. Customers, orders, sales, and warehouses are all "things." Domain driven design is more concerned about organizing things around business rules, so that an object has all of the information necessary to execute it's part of the business process.

You will need to do a deeper analysis of the business processes, and how each department interacts with customers, orders, and other departments before deciding how the application should be divided and organized.

Each department deals with a different aspect of the business. A concept like an "order" can exist in multiple aspects depending on who is using the system and what rules they need to follow. The sales and warehouse departments could both have the concept of an order, but they are allowed to do different things with an order. For example, a warehouse worker could "fill" an order, but a sales staff member cannot. The sales staff could cancel an order, but perhaps the warehouse staff can only mark an order as being out of stock.

The concept of an order might exist twice, and therefore might deserve to be represented by two different classes. The class used for sales would have different methods than the class modeling the process for managing orders in the warehouse after they are created.

The same can be applied to customers. The concept of a customer could appear multiple times in your domain model. It all depends on the perspective of the end user, and the rules they should follow. This is where a deeper analysis of the business processes becomes beneficial. You need to discover the rules first. You need to know who is responsible for which parts of the process before you can conclude that "I should only access orders through customers."