Сервер может делать не только это

А логику так тестить и вообще поддерживать проще.

Так Фаулер завещал: https://martinfowler.com/bliki/PresentationDomainDataLayering.html

> presentation (UI), domain logic, and data access.
Интерфейс ген_сервера — это Thingy, логика — Impl, data access — State?

Просто там выше четыре модуля описаны.

Я скорее даже про первую картинку из статьи. А так все верно:

Presentation - GenServer (на 95% уже написан за тебя, спасибо OTP)
Domain - это функции над стейтом, пишутся тобой
Data - здесь это твой стейт. В данном случае тоже все написано за тебя (ссам тип данных и базовые функции работы с ним из стандартной библиотеки)

На простом проекте это может и не столь важно, но вот когда проект растет годами - тут Single Responsibity Priniciple действительно помогает людям.

Тогда зачем разделять Server и Impl, если presentation уже за тебя написали в OTP?

Тут сервер - это твой GenServer. OTP тебе дает примитив, чтобы его построить.

Ты же не GenServer запускаешь, а свой модуль в котором use GenServer

Но там ведь работает код из GenServer.

Ща, кажется я где-то видел объяснение прям для Elixir/OTP, попробую найти))

Пока не нашел, но вот статья с конкретными примерами: https://pragdave.me/blog/2017/07/13/decoupling-interface-and-implementation-in-elixir.html

И на примере этих примеров можно уже что-то сказать конкретное.

При такой архитектуре, в случае когда нужно отрефакторить в сервер или из сервера - модуль с логикой остается нетронутым. Т е не нужно переписывать тесты и т п. Т е при рефакторинге ты можешь напортачить с имплементацией GenServer, но логику что уже есть не сломаешь.

Это соответвует Open-Closed Principle из SOLID.

Поэтому удобно облегчить себе жизнь в будущем и разделить логику и "оборачивание логики в сервер".

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

Но если такой задачи не стоит и код "одноразовый" - то писать можно как угодно, лишь бы работало и заказчик был доволен)

Был короткий модуль в пол-экрана, его распилили на пять модулей с алиасами и макросами.

Are you sure this is a good practice?

Оверинжинирг никто не отменял))

В случае тривиальной логики я скорее всего разделять не стану.

А вот если логика занимает 4+ строк - то лучше вынесу.

Если 7+ точно вынесу.

7 строк — выносить в отдельный модуль?..

Ну да. В Elixir это уже что-то существенное. За 7 строк можно столько наворотить.