Comments 11
Спасибо за то что дочитали до конца.
Я только настроился и… все… конец. Сейчас даже Твиты длиннее)
UFO just landed and posted this here
Я тоже подумал об автоматизации, и вариантов в голове возникло два: 1) DSL, генерирующий и Kotlin-код, и Swift-код; 2) транспайлер из одного в другой. Я бы сам выбрал первый вариант — в знакомом мне C#-стеке могло бы выйти несложно. Кстати, не так давно проходила статья о делании DSL на Kotlin (примером был DSL для тестовых сценариев) — похоже, так тоже можно сделать довольно быстро.
Сложно назвать кроссплатформенной разработкой нативную разработку для двух платформ
Есть же Kotlin Native и gradle-плагин Konan, который позволяет компилить pure-kotlin код без изменений сразу в ios-фреймворк
Все же дядя Боб рекомендует, что бы был один класс на один use case, а не один класс на 8 use case'ов как у вас. Ну и слово «Interactor» не обязательно добавлять в название класса. Ну и интерфейс репозиториев тоже странный (sendCode, notifyConfirmHashListener и т. д.), он должен отображать работу по обеспечению персистентности бизнес сущностей, а не повторять, почти один в один, интерфейс интерактора
да тут более менее еще, это репозиторий-слой тут может быть несколько однотипных запросов к примеру, а use-case это на слой выше, где можно комбинировать различные запросы из одного/нескольких репозиториев. use-case должен быть уникальным, поэтому там зачастую один-два метода
Спасибо вам за ваши замечания))
Почему-то я думал что это история про использование Kotlin/Native для реализации доменной логике на двух платформах
Sign up to leave a comment.
Clean architecture в контексте кроссплатформенной разработки