DTO/Model-ViewModel clean up

[dstarr]

Problem: The Models folder in Services Solution contains a mis-mash of objects representing either Application Models (PlanModel, OffersModel), API Response classes mapped from original DTOs (Subscription Result) and ViewModels. Sometimes there is no clear definition of where goes where.

Solution: Organize and refactor Application Objects to increase clarity of what objects should be used.

Benefits: Developer productivity

[dstarr]

Should we use records as view models?

[alexdrenea]

I am 100% in favor of using records.

I would like to have a bit of a design / architecture design session to evaluate and organize the types of model / DTO / ViewModels we use and identify opportunities to improve separation of concerns while refactoring.

My initial analysis, I identified 4 types or "models" but no clear rules on where to use what:

• Database Entities (these are stored in the DataAccess project) and are relatively well separated.
• Marketplace API Models (we have the actual Classes that come from the library itself, as well as some extra models that usually end in "Result" and are meant to be clones / copies of those models)
• Application Models - should be separate than DB Entities and API responses, used as a "transition" layer between our code and our dependencies (they are currently not clearly separated and sometimes used interchangeably with other models
• View Models - based on the application model and offering extra business logic / properties that are needed in displaying the views.

What I'd like is to come to an agreement and architecture guidance on how and where we use these types of models and answer some of these questions:

• What types of objects do repository methods interact with? What about Service Methods?

• Who is responsible for ViewModel <-> AppModel <-> DB Entity translation?

• Where does validation happen? Etc..