How to model domain classes for the business layer is a topic on which full books were written. It would be far too broad to answer in a general way, but here a couple of remarks that should help you to avoid some common traps:

• First, you need to separate concerns: the domain is not the application. The application just provides functionality to its users to work with the domain.

• Requirements may help you to identify the domain objects, regardless if you use use-cases or user-stories. Use cases are typically used to identify domain entities in a systematic way, using the Entity-Control-Boundary approach. In this regards, you have already identified a lot.

• You need to design the domain according to the relationships in the domain, independently of the current application will present these. A wise pioneer once said: "Premature optimisation is the root of all evil"

• Requirements are always a good opportunity to liaise with the users for challenge your reality in addition to clarifying their expecations. Example: Is there really 1 bill for 1 pallet? Always? Maybe it's ok and then go on. But if your're in doubt, clarify it first to avoid painful surprises. Typical counter-example: there's a first invoice, but due to a price increase or a customer discount granted after a complaint, there's a second invoice after all. Or worse, somle items on the palette were returned and credited to the customer.

• Domain Driven Design can really help you to use the right approach here. Get Ewan's book and you'll see a lot clearer how to struture the relationships according to domain needs.

• Domain models show associations, but rarely limit their direction because it's not a core concern for the domain. As you already found out: one view may need one direction, and another view the reverse. And maybe in a couple of month, you'll have the need to start navigation at a pallet stack? Your design shall remain evolutive. If you are in business applications, the performance gains that you could hope by implementing only mono-directional associations are tiny compared to the cost to later implement the inverted navigation. And if you use DDD, anyway, the repository design will make this kind of worrying useless: you need a pallet? Ask the PalletReportory by id; you need a bill? Ask the BillRepository by id. You need the pallets based on a bill? Ask the PalletRepository by bill_id.

How to model domain classes for the business layer is a topic on which full books were written. It would be far too broad to answer in a general way, but here a couple of remarks that should help you to avoid some common traps:

• First, you need to separate concerns: the domain is not the application. The application provides functionality to its users to work with the domain. Sometimes an application covers completely the domain, but sometimes the domain is shared between several applications. Moreover if you decompose your app into distinct layers, it’s exactly to separate different concerns and to avoid business functions from being so deeply intertwined with other concerns (presentation, persistence, ...) that it’s not maintainable in the long run. For all these reasons, the domain deserves to be well understood.

• Requirements may help you to identify the domain objects, regardless if you use use-cases or user-stories. Use cases are typically used to identify domain entities in a systematic way, using the Entity-Control-Boundary approach. In this regards, you have already identified a lot.

• You need to design the domain according to the relationships in the domain, independently of the current application will present these. A wise pioneer once said: "Premature optimisation is the root of all evil"

• Requirements are always a good opportunity to liaise with the users for challenge your reality in addition to clarifying their expecations. Example: Is there really 1 bill for 1 pallet? Always? Maybe it's ok and then go on. But if your're in doubt, clarify it first to avoid painful surprises. Typical counter-example: there's a first invoice, but due to a price increase or a customer discount granted after a complaint, there's a second invoice after all. Or worse, somle items on the palette were returned and credited to the customer.

• Domain Driven Design can really help you to use the right approach here. Get Ewan's book and you'll see a lot clearer how to struture the relationships according to domain needs.

• Domain models show associations, but rarely limit their direction because it's not a core concern for the domain. As you already found out: one view may need one direction, and another view the reverse. And maybe in a couple of month, you'll have the need to start navigation at a pallet stack? Your design shall remain evolutive. If you are in business applications, the performance gains that you could hope by implementing only mono-directional associations are tiny compared to the cost to later implement the inverted navigation. And if you use DDD, anyway, the repository design will make this kind of worrying useless: you need a pallet? Ask the PalletReportory by id; you need a bill? Ask the BillRepository by id. You need the pallets based on a bill? Ask the PalletRepository by bill_id.