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.

  • Why do you think DDD requires you to only access orders through customers? Can you reference or link to what you've read?
    – bdsl
    Jul 19 at 16:57
  • 1
    That really depends what works best for your users. DDD is not about how to design your solution (and it's absolutely nothing to do with database design), it's about how to design your conceptual model -- i.e. it's about analysing, modelling and communicating your requirements. For that you need to focus on the needs and expectations of your users and stakeholders. The question of whether your system needs to access customers through orders really depends on whether that's what your users want to do -- focus on their UI/UX and how they will use the system. Jul 19 at 17:46

1 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."

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.