Clean architecture в контексте кроссплатформенной разработки

[@Lietto]

Спасибо за то что дочитали до конца.

Я только настроился и… все… конец. Сейчас даже Твиты длиннее)

[@rasfront]

Это моя первая статья.)) А так надеюсь со временем получится написать что-нибудь пообъемнее.

[@sashagil]

Я тоже подумал об автоматизации, и вариантов в голове возникло два: 1) DSL, генерирующий и Kotlin-код, и Swift-код; 2) транспайлер из одного в другой. Я бы сам выбрал первый вариант — в знакомом мне C#-стеке могло бы выйти несложно. Кстати, не так давно проходила статья о делании DSL на Kotlin (примером был DSL для тестовых сценариев) — похоже, так тоже можно сделать довольно быстро.

[@tapoton]

Сложно назвать кроссплатформенной разработкой нативную разработку для двух платформ

[@anegin]

Есть же Kotlin Native и gradle-плагин Konan, который позволяет компилить pure-kotlin код без изменений сразу в ios-фреймворк

[@Leg3nd]

Все же дядя Боб рекомендует, что бы был один класс на один use case, а не один класс на 8 use case'ов как у вас. Ну и слово «Interactor» не обязательно добавлять в название класса. Ну и интерфейс репозиториев тоже странный (sendCode, notifyConfirmHashListener и т. д.), он должен отображать работу по обеспечению персистентности бизнес сущностей, а не повторять, почти один в один, интерфейс интерактора

[@vplusm]

да тут более менее еще, это репозиторий-слой тут может быть несколько однотипных запросов к примеру, а use-case это на слой выше, где можно комбинировать различные запросы из одного/нескольких репозиториев. use-case должен быть уникальным, поэтому там зачастую один-два метода

[@rasfront]

Я недавно совсем начал использовать чистую архитектуру и поэтому пока совершаю многие ошибки. Я благодарен вам за ваши комментарии)))

[@rasfront]

Спасибо вам за ваши замечания))

[@voddan]

Почему-то я думал что это история про использование Kotlin/Native для реализации доменной логике на двух платформах