Одно действие с множеством модификаций. Как организовать архитектуру?

Question

[Multu]

Приветствую всех!
Прошу помочь разобраться со следующей проблемой. Есть на первый взгляд очень простой веб-проект.

Суть его в следующем. Пользователь (на уровне его профиля закреплен вид договора) заполняет несколько простых форм (для заключения договора) следующего вида:
ФИО, телефон, email, адрес, и т.д. И эти данные сохраняются для заявления на оказание услуг.

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

Пока что решаю проблему так, что создаю для каждого случая новый метод, новое предоставление (по сути на 95% копипастой занимаюсь), например createBookerRu, createAsat, createBookerUa. Методы везде идентичные, кроме проверок на валидацию формы, а представления я привожу к нужному виду. Кол-во видов договоров начало сильно расти, уже около 70 вариантов, и далее еще будет расти. На каждый вид заводить свой метод кажется утопией.

Подскажите, если уже приходилось решать подобную проблему, в какую сторону вообще смотреть?
Свое видение: иметь один метод create, который умеет обработать любой вид договора, но не понятно, каким образом сделать динамичными представления, как провести валидацию формы, как быть если одно и тоже поле (телефон) может иметь разные требования валидации (Беларусь, Россия, Украина)?

Answer 1

[Котик Антон]

Я бы попробовал использовать паттерн Factory.
Фабрика будет создавать форму для конкретного типа документа, в ней не должно быть дублирования кода.
Список полей и правила их валидации для каждого типа договоров хранить в конфигурационных файлах concrete-document-type.php:

<?php
return [
    'elements' => [
        'name',
        'surname',
        'phone' => [
            'validators' => ['by']
        ],
        ...
    ],
    ...
];

Структуру привёл условную. Фабрика должна уметь по требуемому типу договора получить нужный конфигурационный файл и по нему построить нужную форму договора.

У вас получится 70 конфигурационных файлов. Дальше можно думать, как их максимально упростить. Например, у вас есть PhoneElement формы, использующий PhoneValidator, вы создаёте его наследника PhoneByElement с валидатором беларусского номера телефона. И конфигурационный файл превращается в:

<?php
return [
    'elements' => [
        'name',
        'surname',
        'phone_by',
        ...
    ],
    ...
];

Или добавляете понятие локали в конфигурационный файл:

<?php
return [
    'country' => 'by',
    'elements' => [
        'name',
        'surname',
        'phone',
        ...
    ],
    ...
];