Здравствуйте, друзья, подскажите, пожалуйста, по архитектуре Есть класс ContactDomain, который должен

мапиться к двум другим UI классам: ContactUi и ContactDetailsUi. Проблема в том, что ContactDomain у меня описан так:
data class ContactDomain(...) : Abstract.Object<ContactUi, ContactDomainToUiMapper>, где ContactUi то к чему мапится и ContactDomainToUiMapper сам маппер. Прописать еще раз такой интерфейс котлин мне не позволяет по понятным причинам, но не создавать же еще один идентичный интерфейс для еще одного маппера? Как это делается по умному?

было бы хорошо, но там разные данные лежат в каждой, обьединить нельзя

Почему доменный класс вообще знает про свои ui аналоги и мапперы?

Правильно понимаю, что тогда домен должен мапиться к общему юи, а потом этот юи во вьюможельке сам мапиться нужной субмоделиЮи?

Кажется не правильно понимаете)

Доменной вообще не важно, во что она маппится. Она и знать не должна, что её маппить будут) Это тупо данные, усе.

наверное моя проблема, что не уточнил, что использую мапперы в своих дата классах. СЕйчас сделал так, что если хочу сделать ContactUi, то передаю маппер в map(mapper: DomainToUiMapper): ContactUi, если нужны COntactDetailsUi, то map(mapper: DomainToDetailsUiMapper): ContactDetailsUi

в общем, без примера кода понять сложно, но суть в том, что ваш домен вообще ничего не должен знать про UI модели, и один и тот же domain класс может мапиться хоть в один UI класс, хоть в 10, и в нём не будет храниться об этом информации, потому что UI зависит от домена, но домен на зависит от UI

Спасибо, вроде проясняется. Но тогда, если у меня все поля приватны, то у слоя (в данном случае домен), должен быть метод map(Mapper<T>): T, который принимает какой либо маппер и отдает ему все свои данные, верно понимаю логику?

если я правильно понимаю проблему - то делают наоборот, маппер в presentation слое принимает domain модель и внутри преобразует domain модель в UI

А как он ее преобразует, если поля у модели домена приватны?

domain модель - обычный класс, насколько я понимаю, берёшь данные из геттера

Дата класс с приватными полями, чтобы они наружу не вылезали. Ответствннность маппинг одного слоя к другому предоставлена мапперам и исаолняется исалючительно ими

Если это дата класс и поля неизменяемые, то их нечего скрывать

что значит наружу не вылезали? Не обращайся к этим полям там, где не нужно - и никаких проблем

Поля то неизменяемые, но это не мешает вам в любом месте заменить один объект другим, где изменилось поле на ваш выбор

если честно, вообще не понял, что это означает и также не понял, чем помогут приватные поля в таком случае

у вас какое-то интересное видение архитектуры, и чтобы помочь вам с проблемой, нужно посмотреть на какой-то её микро-пример, так что запилите gist и можно будет предметно обсуждать)

Если что-то не должно вылезать наружу, то и никакой маппер не должен отдавать эти данные наружу. Кажется вы не правильно понимаете смысл приватных полей. Как сказали выше — по клину именно внешние слои подготавливают данные для себя, а не внутренние. Соответственно маппер у вас должен быть в UI\Presentation, а не в Domain.

https://gist.github.com/savvasenok/0c3c3b55dc37fb2a0745edf1e8efd8e9 вот пример того, как я сейчас сделал. Имея доменный обьект я могу сделать из него нужный мне юи, просто передав необходимый маппер в метод мап map()

домен так то не знает во что он превращается с маппером. Он просто знает, что в маппер нужно положить некоторые/все свои данные, а он уже вернет обьект другого слоя Может не там и не так научился, если у вас есть учебные материалы, то я с удовольствием почитаю

Во, отлично, пошли вопросы: 1) в чём смысл класса ContactDetailsUi? Им никто никак не может воспользоваться, как и ContactDomain, и ContactUi, никто не может работать с их пропертями. 2) ContactDomain зависит от ContactDomainToUiMapper и ContactUi, это нарушение направления зависимостей. Зато ContactDomainToDetailsUiMapper как будто не зависит от ContactDomain, но зачем-то дублирует весь его набор полей 3) Зачем доменному объекту передавать маппер только чтобы он вызвал на нём какую-то функцию и вернул результат? 4) Зачем ContactDomainToDetailsUiMapper интерфейс если это простейший класс с одним методом, и у этого интерфейса никогда не будет второй реализации? Чего вы пытаетесь добиться таким витиеватым кодом, в которым смысл несут только три сущности и две чистые функции map?

Я для упрощения примера опустил некоторые вещи. Могу скидывать по необходимости, либо менять исходный гист 1) Для упрощения примера Юи не маппился, но вообще он реализует интерфейс(для каждого Юи обьекта разный), внутри которого метод map с нужными параметрами. Например, чтоб замапить ContactUi к визуалу, то используется следующий код contactUi.map(object : ContactUi.ContactUiMapper { override fun map(id: Int, name: String, photoUrl: String) { button.setOnClickListener { clickListener.click(id) } userFullName.text = name loadPhotoWithGlide(photoUrl) } }) 2-4 и концовка) Я не знаю как ответить. Вероятно, вы правы. Начал изучать архитектуру по примерам из @easyCodeRu, оттуда и подходы. Если есть лучше, то я только рад увидеть