Отделение бизнес логики от фреймворка Symfony?

Question

[DollyPapper]

Привет всем. Только открываю для себя "правильное" проектирование архитектуры ПО, и начал писать пет проект за основу которого выбрал чистую архитектуру. Дядя Боб пишет, что фреймворк это деталь и его идея понятна, но когда на практике я начал отделять бизнес слой от слоя инфры немного впал в ступор. То есть например в контексте разработки на симфони, как можно отделить сущности и репозитории от самой симфони? Мы же не имеет больше права генерировать их. Как поступать в этом случае? Писать свои реализации? Проясните пожалуйста данную тему.

Answer 1

[Максим Федоров]

Генератор — просто инструмент для помощи, по итогу сущности чисты, не считая аннотаций/атрибутов для маппинга в ORM, но это просто мета-информации и завязка не существенна (не считая маленького компромисса с ArrayCollection). То есть если вы выберите др ORM, то эти аннотации вам не помешают никак, просто лишние заюзанные классы аннотаций

Имея сущности доктрины — у нас не связанный от фреймворка код, пишите спокойно бизнесуху, не обращая внимания на то, как оно потом маппится. То есть практически все по каннонам

Чтобы отделить репозиторий от домена — просто в домене делайте интерфейс, а вот реализация этого репозитория будет в Infrastrucure Layer, но это избыточно... риск минимальный, если сделаете не совсем по канону, а именно риск стоит как основной аргумент такового отделения (не просто же вы словам следуете, а причину понимаете?)
Разработка строится на компромисах, если смените доктрину на др ORM — так и так писать новые репозиторий, вероятность низкая и многие например не делают такие интерфейсы — слишком усложнит код...
Вам надо будет просто репозиторий в маппинге ORM\Repository заменить в таком случае

Некоторые компании пишут интерфейсы и сильно усложняют код, но тк риск минимальный изменений, то такое усложнение приводит как правило к усложнению и не более. Следуйте здравому смыслу.
Мой довод нельзя раскручивать "ну раз минимальный, то завяжусь по полной". Все же отделение логики надо делать

чтобы все же соблюсти эту чистоту
и не сильно усложнить, то можно систему разбить на модули/фичи
и каждый модуль будет иметь такие слои
почему лучше это сделать:
- реализация репозиториев хоть и инфраструктурная, но правится часто при изменении домена, а значит сильно далеко прятать не вариант, иначе сильно все будет размазано... потому модуль делают трехслойным (инфра, домен и апликейшн слой)

пример

Comments

[DollyPapper]

Хорошо, с сущностями оно может и так, а как быть с репозиториями? Получается чтобы быть развязанным от симфони мы не можем в них использовать например QBuilder, верно? Или в репозитории и так и так не хорошо писать SQL и между репозиторием и базой должен быть еще один слой который как раз будет в базу ходить?
UDP: пока писал свой вопрос, вы уже отредактировали свой. Вопрос отпадает, спасибо.

[Максим Федоров]

DollyPapper,

про репозитории добавил ответ

[DollyPapper]

Это пет проект, по этому сейчас хочу по полной быть крайне категоричным и писать только по канону :)

[Максим Федоров]

если хотите прямо отделить, то доменный уровень будет знать только о интерфейсе
а вот реализация лежать не в домене

чтобы все же соблюсти эту чистоту и не сильно усложнить, то можно систему разбить на модули/фичи
и каждый модуль будет иметь такие слои
почему лучше это сделать:
- реализация репозиториев хоть и инфраструктурная, но правится часто при изменении домена, а значит сильно далеко прятать не вариант, иначе сильно все будет размазано... потому модуль делают трехслойным (инфра, домен и апликейшн слой)

[DollyPapper]

Максим Федоров, спасибо еще и за пример. Можно тогда еще небольшой вопрос. А в чем здесь отличие между сервисами и usecase? Думал, что usecase в понятиях CA и есть "сервисы"

[Максим Федоров]

DollyPapper,
юзкейсы — это сценарии использования, что как-бы дословно и переводится
отличия от др сервисов в том, что др сервисы — какие-то службы с какой-то ответственностью, отличной от бизнесс-процесса

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

просто слово "сервисы" очень обтекаемое и не говорит чего там происходит, бизнес-логика или просто вспомогательное что-то или фиг пойми что

[Максим Федоров]

DollyPapper, согласно Мартину, юзкейсы: варианты испольщования нашего домена, его инварианты и сценарии использования

сервисы: ну что-то, что помогает, опять же согласно переводу этого слова

[DollyPapper]

Максим Федоров, понял. То есть если подытожить немного, то например проверка в какой timezone проживает пользователь это usecase, а вот обработать дату, например ее в timestamp перевести - сервис.
Спасибо большое, очень помогли.

Answer 2

[Zhainar]

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

Например, если в коде у вас было:

$companyEmployees = $entityManager
    ->createQueryBuilder()
    ->where('companyId = :company')
    ->where('active = true')
    ->fetchCollection();

то этот код заменяется на интерфейс

interface CompanyRepository {
    public function getActiveEmployees(): array;
}

а в коде вызывается метод этого интерфейса, при этом реализация уже может быть любой

class DoctrineCompanyRepository implements CompanyRepository {
    public function getActiveEmployees()
    {
         return $entityManager
             ->createQueryBuilder()
             ->where('companyId = :company')
             ->where('active = true')
             ->fetchCollection();
    }
}

class EloquentCompanyRepository implements CompanyRepository {
    public function getActiveEmployees()
    {
         return Company::where()->where()->get();
    }
}

class MockCompanyRepository implements CompanyRepository {
    public function getActiveEmployees()
    {
         return [new Employee($name, $position), new Employee($name2, $position2)];
    }
}

class SqlCompanyRepository implements CompanyRepository {
    public function getActiveEmployees()
    {
         return Db::query('select * from company_employees t where t.company_id = :id and ...')->fetchAll();
    }
}

соответственно в вашем коде вы должны передать объект нужного репозитория

class CompanyController 
{
    public function fireAllAction()
    {
         $companyService = new CompanyService(new DoctrineCompanyRepository());
         ...
    }
}


class CompanyServiceTest
{
    public function testFireAllMethod()
    {
         $companyService = new CompanyService(new MockCompanyRepository());
    }
}

Comments

[dmitriy]

все по делу, но я предпочитаю использовать
interface CompanyRepository {
public function getActiveEmployees(): EmployeCollection;
}