Есть классы User, Company и Order и везде есть поле email, и есть сложная (но одинаковая) логика его проверки: регулярки, проверка длины, проверка домена...

Как это делают в ООП: паттерн Адаптер, DI-внедрение и прочий ужос-ужос...
Ну или абсолютный зашквар: публичный static-класс ("библиотека функций") со static-методом валидатором :)

Как это делают в ФП: одна чистая функция :)
Да, но...
Едва касаемся взрослого построения архитектуры, 100500 чистых функций превращаются в ад ручного связывания: пайплайны становятся невероятно хрупкими. Чтобы например собрать пайп для User, будешь вручную писать обёртки для каждого шага, чтобы типы совпали.
20 шагов - 20 ручных лямбд :)

Ну а наш Last Principles Framework пояснит, элите избранных :)
как это делают математики: элементарно и автоматически через контравариантный функтор (и при чём здесь профунктор).

+128 других math-паттернов. Осенью.

Кстати, рекомендую: "В среду 15 июля в 20:00 MSK в Лаборатории формальной математики стартует курс по современным теориям типов."
Особо полезно будет, кто проходил мой трек по HoTT.