Тоже делал такое, дико удобно разрабатывать и писать тесты. Но есть нюансы, о которых узнаешь только начав работать с этим:
Много маппингов структур между слоями
Нужен DI-контейнер, иначе при развитии проекта становится сложно уже не в бизнес логике, а в инициализации зависимостей
Поход репозиториев требует какого-то решения для транзакций. Зачастую это усложняет код, приводит к утечке абстракции в слой бизнес-логики и при определенных реализациях также может замедлить выполнение
Зачастую в юзкейсах есть общий код, который надо куда-то выделить. При этом не хочется каждый раз в функции пробрасывать зависимости
Как реализовать паттерн outbox в репозитории без утечки абстракции и кросс зависимости между адаптерами?
Это только то, что вспомнил. Жаль никто не пишет про это. Возможно, напишу как-нибудь статью.
По умолчанию виджет не скрывается, чтобы не поехала верстка в формах. Бывают формы, где нужно скрыть не только виджет, но и часть верстки (строку таблички, подпись или что-то еще). Чтобы корректно скрыть виджет можно использовать специальное js событие.
Было бы удобнее, если бы в настройках был пункт «скрыть если не робот» и опционально колбэк для скрытия дополнительной верстки?
Все же для reCaptcha и Некапчи ботов будут писать специализированных, поэтому сравнивать статистику по ним нельзя. Более того, для Некапчи их еще вообще нет, а если появятся, то мы будем их изучать и усиливать алгоритм.
Да, согласен с вами. У нас не было точной даты релиза, поэтому что-то доказывать другим сложно. Наверно единственное документальное подтверждение того, что это наша идея — это заявка на изобретение, поданная в декабре 2013 года (если это так важно, то наверно скан или копию документа можно будет предоставить).
Вопрос в том, что дешевле — купить валидного пользователя и запостить 1000 сообщений или купить 1000 распознанных капч за 1$. Капча — это не идеальная защита от спама. Надо учитывать несколько факторов: влияние капчи на конверсию, критичный уровень спама, стоимость защиты и т.д.
Фишка в том, что мы не выводим капчу всем подряд, а пытаемся на основе дополнительной информации оценить, кем является пользователь. Если по ряду признаков мы решаем, что это человек, то капчу не показываем.
Тоже делал такое, дико удобно разрабатывать и писать тесты. Но есть нюансы, о которых узнаешь только начав работать с этим:
Много маппингов структур между слоями
Нужен DI-контейнер, иначе при развитии проекта становится сложно уже не в бизнес логике, а в инициализации зависимостей
Поход репозиториев требует какого-то решения для транзакций. Зачастую это усложняет код, приводит к утечке абстракции в слой бизнес-логики и при определенных реализациях также может замедлить выполнение
Зачастую в юзкейсах есть общий код, который надо куда-то выделить. При этом не хочется каждый раз в функции пробрасывать зависимости
Как реализовать паттерн outbox в репозитории без утечки абстракции и кросс зависимости между адаптерами?
Это только то, что вспомнил. Жаль никто не пишет про это. Возможно, напишу как-нибудь статью.
Это устоявшаяся терминология Clean-Arch-like структур проекта. Лучше одному привыкнуть к общим названиям, чем всем к уникальным.
Было бы удобнее, если бы в настройках был пункт «скрыть если не робот» и опционально колбэк для скрытия дополнительной верстки?
Что такое среднестатистическое поведение?