Потомучто на момент создания это враппера это было единственное внятное api для взаимодействия с baresip.

Не только в ядре подменяют это слово.

MVP — шаблон проектирования пользовательского интерфейса (Model-View-Presenter).

С моей точки зрения допущены серьезные ошибки в определении:
1) MVP — это архитектурный паттерн для построения архитектуры приложений с пользовательским интерфейсом, а не для проектирования пользовательского интерфейса.
2) MVP можно использовать и в программном обеспечении без пользовательского интерфейса.

Ну а какие тут детали, разпознает за нас гугл, синтез делает ЦРТ, вообщем и все. Мы просто пользуемся существующим API.

Да, здесь практически нет технических подробностей, так как проект очень большой, и описать его даже просто с технической точки зрения в одной статье не представляется возможным. Есть статья про устройство ядра системы habrahabr.ru/post/282253.
Если смотреть на архитектуру в целом то это SOA очень близкое к тому что рассказывает Яндекс об Алисе www.youtube.com/watch?v=_law_tey0OQ но естественно попроще)

Нас вполне устраивает )

С яндексом все сложно, когда мы начинали у них качество синтеза было хуже. У них сложная схема подключения к API (договоры, бумажная волокита, бюрократия). У яндекса очень плохая поддержка(ответы от сапорта можно ждать месяцами). И голоса нам не понравились.

Синтез от ЦРТ, работаем через http api. Перед запуском многие пробовали, но по совокупности подошел ЦРТ.

Если вы имеете ввиду ботов, то не проблема сделать бота и принимать голосовое сообщение с адресами так же как из телефонного звонка. Но тут мы уже будем конкурировать с приложениями на телефонах. И в маленьких городах это мало востребовано пока.

Как показывает наш опыт, люди не пугаются. Им просто надо немного привыкнуть, а дальше это входит в норму и их все устраивает.

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

В рамках правил хабра не могу разглашать подробности, но если интересно, пишите в личку, скину живой номер куда можно позвонить и поговорить с роботом :)

Уходят с этим спорить не буду, но у вас есть статистика какое количество заказов до сих пор идет через телефон? А у вас есть статистика заказов через телефон и приложения для мелких городов?
Есть рынок и на этом рынке есть условия работы, если вы их не принимете то вы идете на другой рынок с другими конкурентами и правилами работы. А телефоны живы и будут жить еще очень долго.

С помощью распознования речи и синтаксического анализа лекго выделить адреса. «рубинштейна 24» распознается и геокодируется вообще без каких-то проблем.
Гораздо хуже с трезвыми, которые чаще не могут назвать адреса. У нас есть механизми уточниня поездок, которые не распознались с первого раза.

Бизнес-логика конечно не оперирует, но вот программная модель этой бизнес логики которую разрабатывают программисты еще как будет оперировать и привидением типов и использовать циклы и операторы и создавать типы данных.

Ну я бы сказал что все есть с точки поддрежки технологий, баз данных, апи, библиотек и т.д…
В этом плане у нас все работа с финраструктурными частями основана на готовых решениях, тут и работа с базой и роутинг и всевозможные апи.
На себя было взята только организация каркаса, бизнес-логики и верхней части хранения.
На каркас ушло гдето 1-2 месяца 1 человека, дальше мелкие доработки.
В наше время вообще использование громостких фреймворков часто стрельба по воробьям из пушки, легко можно собрать свое приложение хранящее бизнес логику и окружить его готовыми библиотеками работающими с инфраструктырными частями.

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

Платформа написана и не стоит на месте, есть планы после анализа развивать ее дальше, написанная статья тоже говорит о том что мы будем учитывать критику :)

Тесты у нас приемочные, есть план перейти на тестирование базнес логики по контекстам.
Логика есть как в контекстах так и в сущностях.
Модулей как таковых нет есть наборы контекстов.
Ну контроллер и TransactionScript конечно похожи но это разные концепции, не стоит их путать. Как вы говорите control-flow инфраструктуры и control-flow бизнес логики это 2 разные вещи, хотя часто их сваливают в одно и это как раз Controller слой в MVC подобных фрейворках.

Я бы сказал так что маппер делает только меппинг, а сохранение как финальная чать мепинга.
Сама логика разрабатывается так чтоб в мепперах не надо было работать со сложными связями объектов, каждый меппер знает только свой один объект с которым он работает.

SRP очень важен, но в реальности к нему надо стремится как к идеалу но достигнуть его бывает достаточно сложно или в некоторых случаях нецелесообразно.

Ссылка это как бы показатель того что первый код тут был написан уже давно :)

Тут палка о двух концах, в целях бизнеса вообще могут быть не нужны все эти архитектурные плюшки, есть проекты в которых жуткий га*нокод и они приносят бизнесу доход.
С другой стороны инженер должен исследовать.
Здесь уже надо балансировать между этим двумя крайностями)

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