Комментарии 2
А можно чуть более подробно, почему в UDF не нужны протоколы? В статье об этом дважды, но оба раза просто констатация факта, без пояснений. Причем, во втором случае написано, что есть проблема, которую бы могли решить протоколы (связность и абстракции), но приходится почему-то искать другие способы.
И в продолжение нашего разговора в предыдущей статье, кажется, что после разбиения доменной логики на независимые кусочки, каждый такой кусочек вправе обладать своим собственным состоянием. А состояния разных кусочков агрегируются медиатором. Медиатор самого высокого уровня будет иметь общее единое состояние, если оно кому-то будет нужно.
Спасибо. Статья интересная. Ждем продолжения.
Отсутствие протоколов — это скорее следствие такого подхода к проектированию домена. Не нужны, потому что нет необходимости отделять один модуль от другого, они и так не знают друг о друге и общаются через общего предка. Отказываясь от протоколов мы не теряем тестируемость и масштабируемость, но и делаем тесты максимально простыми. Нам не нужно писать или генерировать множество моков, достаточно просто провалидировать результат работы редюсеров. Для нас это критически важно, так как это позволяет писать нам unit тесты очень быстро и в больших объемах.
В целом ничего не имеем против протоколов, но если их можно не использовать и глобально ничего не терять, то почему бы не использовать) Но здесь речь только про доменный слой. Там где мы используем полноценные объекты, например в UIKit, мы используем протоколы, хотя и это не обязательно. Чуть подробнее про альтернативу протоколам можно посмотреть здесь.
Что касается разбиения доменной логики, то согласен. Более того, конкретный стейт даже не знает где он будет хранится, это определяется в предке. Некоторые стейты могут быть полностью computed и просто высчитываться из существующих данных, а не физически где-то храниться.
Модуляризация доменного слоя в UDF. Часть I