Multiple domain objects and repositories to support different uses of the same entity?

Question

I am developing an application that allows users to track work-order status. The default interface lists all open work-orders and allows users to update the status of an individual work-order. This list is 'live' in that it will update when changes are made by other users on other workstations.

There is an optional UI that is used infrequently (but required) that will list all work-orders for the current day (w/o that were open at some point during the day). Users cannot make changes to this list and this list is static, i.e. a snapshot at the time the list is displayed and not 'live'.

Work-order data is retrieved from a back-end service. The service contract can be updated as needed.

My issue modeling the domain around the two use-cases for the WorkOrder entity. I will have two Views and associated View Models in my presentation layer, but should I have two separate domain objects and repositories?

Additional info:

• The "all" view is accessed infrequently and by the end of a business day, this list could be quite large and require a sizable amount of memory if cached on the client.
• The "current" view is kept in-sync with changes from other users by handling a broadcast event/notification indicating that changes were made and refreshing the list.

Answer 1

You don't need separate WorkOrder entities since it is the same work order concept present in both views, but you may need distinct read-models to represent those entities in specific types of queries. A read model is a read only, data only object which is designed to fit a particular query.