Is it anti-pattern to alter domain model on front end?

Question

We are making a quiz application, I'm trying to integrate my Angular 2 UI with the REST api.

Our Quiz domain model consist of the following (simplified) hierarchy:

-Quiz -Category -Question -Choice

where parent doesn't know its children, but child knows its parent. For example, Choice has a reference for a Question, but Question doesn't have reference to choice. We chose this approach to be able to fetch the quiz data more flexible and modular approach, also avoiding circular references.

However, in the front end it's counter-intuitive to use inverted linking, as views are built naturally layer-by-layer iterating deeper in the domain object structure. It makes sense to render view for Question first, and render sub-view for Choices after. It just seems impossible with the current domain model, where I should start from Choice.

My question is, if it's common or approved to convert the domain model on the front end, so I wold gather all data and add Choice reference to Question afterwards, making the model compatible for top-down approach? And of course convert it back when POSTing to REST api.

Does this indicate bad design, or is it approved to alter the domain model?

Answer 1

It's very typical to use the domain model as the resources in the web API layer, but it's usually not the right thing to do. The domain layer has clients, including the web API. The web API has clients, including your UI. The needs and wants of domain clients are not the same as the needs and wants of web API clients.

Write your web API for your clients. If it's best for clients to have a link from a question resource to its associated choice resources, then include that link. If the clients want the choices embedded, make that an option. If that means the domain layer gets hammered because you need to make multiple expensive calls from the web layer, then fix the domain layer so it gives the web layer what it needs.

Answer 2

Its common to "invert" your front end models when your api is designed to be modular this way. Though this is regardless of tech stack. Whether asp.net mvc, php, or angular, your website retrieves top down so you are doing an invert whether explicit or not.

The reason this inverting is so visible in Angular is because Angular is a nested component framework. And nested components require that deep object hierarchies remain intact (thus the explicit inverting). This is opposed to say asp.net mvc, where the framework doesn't lend itself to deep nested components, so developers tend to break up levels of the object hierarchy into separate pages with separate controllers, or flatten the hierarchy into single models to be displayed in single views with single controllers orchestrating the api calls. Thus the "inverting" effect isn't explicit.

So yes, you need to invert, and it's accepted.

The flip side to this is building your domain in a top down approach and your api in a top down aggregate approach, which prevents the invert on the client, and is increditably powerful/convenient with angular. You would then need to do the invert in your data access layer which i find much less disruptive.