A qual camada o UIModel pertence?

[cassioferrazzo]

A abordagem trazida pelo @rviannaoliveira relacionada ao UIModel me deixou muito feliz, utilizo diariamente um conceito similar a esse, concebido exatamente como ele comenta no vídeo, algo que simplesmente saiu da cartola e se encaixou muito bem para separar camadas, melhorar coverage de testes unitários e mais um tanto de vantagens...

Pois bem, no conceito apresentado pelo colega, temos o UIModel, uma classe que a mim parece algo como o design pattern adapter, onde uma entidade vem da camada de dados e é traduzida para atender os requisitos da view.
Esta classe faz parte da camada de apresentação, ou view, ou presenter, ou UI.... Bem, aí está um ponto bacana para debatermos sobre. Em qual camada deveria estar essa "transformação" da camada de dados para apresentação?

Aqui, no meu contexto, eu faço isso no UseCase. Ao meu ver é no UseCase que temos as regras de negócio da aplicação e, como estamos falando de mobile, traduzir um Date para String é regra de negócio. Evidente que não apenas isso, porem este exemplo é algo que tradicionalmente se faria na camada de apresentação.

O que talvez realmente devesse ser debatido é o que de fato é regra de negócio para um projeto mobile?
Eu me perguntei isso, e de dentro da minha cartola saiu a seguinte resposta "TUDO QUE PRECISA DE PROCESSAMENTO", seja ele uma estrutura de decisão ou laço de repetição.
Essa afirmação me parece muito muito coerente, pois os processamentos vão acontecer exclusivamente fora da main thread. Ok estamos falando de micro/nano/mini/quase nada segundos, eu sei, porém é Android, ele poderia, em tese, rodar até numa havaianas com um prego em baixo, sem falar no benefício do usuário que possui um galaxy pocket...

Recapitulando:

1. O repository fornece a entidade de acordo com o data souce;
2. O UseCase pega esses dados e "digere" para a view;
3. Por sua vez, o ViewModel recebe esse ViewObject e encapsula em um LiveData;
4. A Activity ou o fragment observa esse LiveData e atribui os dados aos componentes.

OBS: Costumo chamar a entidade que trafega entre o UseCase -> ViewModel -> Views de ViewObject e é um data class da vida que atende exclusivamente os requisitos da camada de apresentação.

Enfim, acredito que tenha conseguido externalizar um pouco do meu pensamento sobre o assunto. Caso não tenha ficado claro, eu posso providenciar uns snippets pra auxiliar, mas eu garanto que na minha cabeça faz total sentido hahahahaha.
Se você leu isso até aqui e achou que não tem pé nem cabeça compartilha sua visão aí tb, vamos trocar ideia e evoluir juntos. Não deixem de contribuir.