The answer is... it depends on what you're intending. If you're looking to achieve scalable code then the best practice is generally to create a Domain Transfer Object (DTO) that is a view into the current state. This is done in the services themselves usually and are regenerated every time the domain object changes (Eventual consistency is key, as trying to keep consistency at all times won't happen). The DTO is optimized for the query that it serves as well as the data it is intended to display, it may be a composite of more than one domain object. But most importantly it is independent of the domain object and is unaware of the domain object. That might sound contradictory, but it's not. I would highly suggest reading up on Command Query Response Segregation (CQRS) as it is probably the best approach to what you're doing.
CQRS allows you to make your web site (or any client) agnostic to your domain. This is important as your domain model needs to manage its own business rules internally and should not rely on an external consumer to ensure consistency and correctness. As far as the website is concerned the domain to it is the DTOs that are designed specifically for its queries. When you need your website to be able to change your domain you expose commands that it sends to the services with the domain entity id and the relevant data just for that command. The services then execute the command or return a result saying that they were unable to.
Now the fully qualified answer here must come with the caveat of: if this is an internal only low usage application you need to decide whether having a scalable domain/query model matters more than speed of completion. Do you need the system fast, or do you need the system to be fast and scalable.