I am reading the book Applying-Domain-Driven-Design-Pattern.
In its model design, it has the Order hold reference to Customer, but if it was me doing the design, i will probably have the Customer hold reference to Order.
So, the question, when designing unidirectional relationship, how to decide the direction?
the answer to this is driven by the functionality of the application. If you need to query orders by customer, then your approach is correct. However, if customers are queried by their orders, then the model design is correct.
If you need to do both, then it's a bidirectional relationship and you may choose to model it as many-to-many.
A structure serves some function.
That is, think of how your classes will be used. Will Customer be queried for its orders? Will Order be queried for its Customer? If both, then you need a bidirectional relationship.
I think if this were an order processing system where Orders are the operational-level concept and Customers provided the context for how to process orders, then an OrderService needs to have Orders refer to the Customer who made the Order. On the other hand, as others have pointed out, it's possible for a Customer can be queried for its orders. This is possible in a customer service system, where the help desk. In this case, I can see a CustomerService that needs Customers to have many Orders.