Конструктор гибкий) Имеются фабричные методы
Об интерфейсе, кончено речи не идёт) это вообще последнее дело)

Кажется тогда, что ваша проблема - в смешанном слое транспорта и бизнес логики рассылок. Если вы их разнесете, то все должно встать на свои места

Ещё тогда вопрос. Под каждый транспорт нужен отдельный шаблон:
- mail
- sms
- service

Как их лучше реализовать? В одной сущности Template и уже внутри делать гибкий конструктор создания для каждого транспорта:
Template::createEmail(...)
Template::createSms(...)
Template::createService(...)
Если говорит о базе, то при таком подходе таблица будет одна на все типы транспорта.

Либо лучше под каждый транспорт свой шаблон:
new MailTemplate(...);
new SmsTemplate(...);
new ServiceTemplate(...);
При таком подходе все данные будут отделены в свои таблицы.

В дальнейшем могут добавиться типы транспорта: чат, пуш. Я склоняюсь ко второму варианту, но не избыточен ли он?

Да, наверное, они разные, всё таки. Задачи у них разные. Просто я увидел в них много общего и подумал, что одно и то же. В принципе развеяли мои сомнения по соединению их) Конечно, посмотрю ещё бизнес процессы, но уже склоняюсь к разделению их, как и планировалось сначала)

Меня смутило, что много общего. В целом ничего не запутано. Просто много общего)

У меня правда очень мало контекста, чтобы ответить на этот вопрос (не говоря уже «чтоы ответить правильно»).

Я бы посоветовал посмотреть на систему уведомлений в ларавел через метод via.  И вот этот сайт в придачу https://laravel-notification-channels.com

Там чуть больше 50 опенсорсных каналов, где каждый отвечает за транспорт по своему уровню.  
Когда вызывается уведомление в методе via() вы определяете (роутите по сути) какие каналы вам нужны, и дальше взвываете метод. В каждом методе уже оборачиваете шаблон. Если это кажется не правильным, то тут можно сделать фабрики и вызывать методы, вынеся часть этой логики в отдельный класс. С точки зрения srp это будет более верно.

Чтобы ответить более предметно, как минимум нужно знать, где и как задаются и управляются событийные уведомления, каким набором данных обладает каждый из шаблонов под каждое уведомление; как они  администрируются.

В принципе смотрел это) Планирую использовать symfony/notifier. Он похож) Полазаю ещё. Вдруг что-то придёт в голову)

Уведомления создаются в Listener доменных событий. На каждое событие по сути подписывается пользователь и выбирает канал доставки. Вот и вся кухня) вроде просто, но запутался)

Может вам стоит посмотреть в сторону декоратора?На рефакторинг .гуру как раз сей паттерн рассматривается в контексте вашей задачи

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

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

В момент создания сообщений и уведомлений из этих правил становится ясно, к каким адресатам они должны попасть и по каким каналам, т.е. происходит диспетчеризация. Здесь уже создаются сущности транспортного уровня "письмо", "SMS", "пуш", "сообщение в сервисе" (и в процессе создания письма например вызывается сервис его форматирования).

Дальше они попадают в сервисы, осуществляющие доставку и обработку всех ошибок доставки.

Итого: две сущности "уведомление" и "сообщение", два диспетчера, вспомогательные форматтеры, сервисы доставки по числу каналов связи. Кажется так.

Можете показать где рассматривается пример уведомлений с этим партерном?) Глянул бы)

Примерно понял) Единственное: 1. Не пойму сообщения, шаблоны нужно ли разделять на каждый транспорт и шаблон своя независимая сущность?
2. Система рассылки и уведомлений одно и то же, либо разное? Обсуждая тут пришли к тому, что разные вещи. Что думаете вы?

1. Если нет задачи варьировать оформление писем, а надо просто красиво и совместимо их форматировать с брэндингом сервиса - то я бы оставил один шаблонизатор.

2. Это доменному эксперту виднее. В каких-то случаях можно считать (маркетинговую?) рассылку частным случаем уведомления, это немного упростит конструкцию.

Всем привет. Скажите, пожалуйста, если ли какие-то шаблоны для документации проекта в confluence. Я имею в виду структуру, что документировать, как и так далее. Если поделитесь полезными ссылками буду непременно благодарен!

Давай сслыку на гит

это мем)

это обман

А как же кроссревью 😔