Я смесь документооборота с CRM и еще некоторыми задачами до 2016го года на Delphi 7 + MS SQL + PHP/JS + Excel/VBA пилил, а потом фирма закрылась...
Десять лет почти прошло, почему сейчас все та же семерка? Понимаю, что многие из следующих версий были так себе, но 2010 мне понравилась (успел на ней проект разработать и отдать заказчику во время бесплатного триал-периода )))
Автор никак не упомянул удивительно высокую позицию Дельфи (старый и быстрый язык, который многие уже похоронили, а когда-то, до Питона, Pascal преподавали в ВУЗах) и некоего Scratch (это что, вообще, такое??? придется гуглить и повышать ему рейтинг )) внезапно обогнавших PHP. Неужели, возрождается разработка клиент-серверных десктопных приложений?
Представьте, Вам не нужно ничего, кроме вывода в консоль, но Вы заморочились и сделали интерфейс для логов. Проходит год или два, становится нужно писать логи в файл. Вы пишете новый класс логгера, передаете в конструктор - все везде автоматически пишется в файл.
И, наоборот, поленились делать интерфейс, везде прямой вызов принта - надо будет изменить каждый вызов...
А тут, внезапно, вендор убрал из репозитория свою либу по политическим или экономическим причинам. Или через пять-семь лет Вы решили сменить умерший фреймворк на актуальный, но в тысячах мест вызов печати через конкретный класс конкретной либы...
Если временный файл на десяток строк - пофиг, если доменная логика серьезного проекта, лучше через внедрение зависимости и интерфейс.
Я определяю интерфейс репозитория в доменном слое, чтобы выразить, какие операции нужны для работы с доменными объектами, но при этом реальную работу (вызовы save(), findById() и тд) провожу из приложения (use cases).
Получается, в домене лежит интерфейс, который доменом не используется, почему бы не положить его на уровне приложения? )
Мне, анимичная модель не близка, но и необходимость сервисов очевидна. Я за подход описанный классиками: если логика затрагивает одну сущность, скорее всего, ей место в методе класса этой сущности, а доменные сервисы нужны, если изменяются несколько сущностей-агрегатов или просто автономных сущностей (это важно, потому, что изменением подчиненных сущностей, вероятно, должен заниматься метод агрегата). Мне кажется, инкапсулируя поведение и соблюдение инвариантов сущности в нее саму, мы существенно упрощаем логику внешних сервисов: сервис знает интерфейс сущности, и программисту сервиса нет необходимости думать о реализации этой логики и, возможно, даже знать о ней. Это освобождает оперативную память в голове )
Я, честно, еще далек от как полного понимания ДДД так и от его реализации при помощи многослойных архитектур (события, транзакции через единицы работы, определение границ агрегатов и другие моменты - все это вызывает больше вопросов, чем является для меня рабочим инструментом, тем более что, для условий PHP эти паттерны нужно переосмысливать), но хотелось бы уточнить такие моменты:
1) "В DDD часто используют интерфейс репозитория в доменном слое, а реальную реализацию помещают в инфраструктурный слой."
Мне кажется, что взаимодействие с репозиториями скорее должно быть на уровне приложения (use-cases), а доменные сервисы должны работать с уже готовыми сущностями и не заморачиваться вопросами получения/сохранения. Возможно, у Вас есть примеры, когда предпочитаемый мной подход не срабатывает? Но в других местах статьи Вы помещаете обращения к репозиториям в слой приложения. Просто опечатка?
2) "Например, Entity отвечает за данные, Domain Service - за бизнес-логику, а Infrastructure Service - за взаимодействие с внешними системами."
Вы исключаете логику из Entity, т.е. выступаете за анемичную модель? Но в другом месте Вы же пишете:
"Симптом: файл domain.ts, в котором вроде бы описаны Entities, а по факту там класс ради класса. Или Value Object, который не содержит никакой логики, а просто один кортеж полей."
Т.е. критикуете анимичную модель. Поясните! )
3) Вы не рекомендуете создавать ValueObjects, если они не содержат логику, но, у меня есть соображение, для чего полезны ValueObject без логики: они обеспечивают строгость типизации по бизнесовым принципам. Например, если сервис вычисления среднего значения получает два числа, мы можем случайно отправить в него одновременно вес и длину - они оба числовые, но вот что за значение мы получим на выходе? С другой стороны, при создании классов Weight и Length, перепутать будет сложно, но понадобится два сервиса/метода, причем, не только для вычисления среднего, но и для сложения/вычитания, если это нужно для бизнеса )
4) Поскольку метод pay() в сущности Order реализует просто изменение статуса заказа на "Оплачено", возможно, название стоило уточнить на что-то вроде markAsPaid, чтобы не смешивать с сервисом, который будет реализовывать логику связанную со списанием/зачислением денег и не путать других читателей-комментаторов ).
У меня про паттерны спрашивают постоянно, даже те, кто, по моим ощущениям, сам не очень понимает (тут хватает упоминания аббревиатур без расшифровки :)). Правда, я претендовал на миддла, возможно, собеседующие считают, что senior по умолчанию обязан знать основы проектирования.
Мне кажется, Вы взяли факты, опыт и сделали прямо противоположный логике вывод: проблема не в абстракциях, а в слишком большом количестве различающихся реализаций! Язык (и обычный и программный) в идеале должен быть один, но максимально абстрагированный от реализации, потому, в что в жизни нам важен результат, а не подкапотные механизмы :)
10 минут в наше время это огромная разница.
Я такси часто использую, когда опаздываю. Если приложение машину сначала 5 минут ищет, а потом машина 10 минут едет, то от выигрыша остается уже не так и много.
Я смесь документооборота с CRM и еще некоторыми задачами до 2016го года на Delphi 7 + MS SQL + PHP/JS + Excel/VBA пилил, а потом фирма закрылась...
Десять лет почти прошло, почему сейчас все та же семерка? Понимаю, что многие из следующих версий были так себе, но 2010 мне понравилась (успел на ней проект разработать и отдать заказчику во время бесплатного триал-периода )))
Автор никак не упомянул удивительно высокую позицию Дельфи (старый и быстрый язык, который многие уже похоронили, а когда-то, до Питона, Pascal преподавали в ВУЗах) и некоего Scratch (это что, вообще, такое??? придется гуглить и повышать ему рейтинг )) внезапно обогнавших PHP. Неужели, возрождается разработка клиент-серверных десктопных приложений?
Представьте, Вам не нужно ничего, кроме вывода в консоль, но Вы заморочились и сделали интерфейс для логов. Проходит год или два, становится нужно писать логи в файл. Вы пишете новый класс логгера, передаете в конструктор - все везде автоматически пишется в файл.
И, наоборот, поленились делать интерфейс, везде прямой вызов принта - надо будет изменить каждый вызов...
А тут, внезапно, вендор убрал из репозитория свою либу по политическим или экономическим причинам. Или через пять-семь лет Вы решили сменить умерший фреймворк на актуальный, но в тысячах мест вызов печати через конкретный класс конкретной либы...
Если временный файл на десяток строк - пофиг, если доменная логика серьезного проекта, лучше через внедрение зависимости и интерфейс.
Эм... Передавать коту еду в конструктор, это живодерство! ) Если немного подумать, то, все же, логичнее передавать объект еды в метод едения )
Получается, в домене лежит интерфейс, который доменом не используется, почему бы не положить его на уровне приложения? )
не туда ответил
Мне, анимичная модель не близка, но и необходимость сервисов очевидна. Я за подход описанный классиками: если логика затрагивает одну сущность, скорее всего, ей место в методе класса этой сущности, а доменные сервисы нужны, если изменяются несколько сущностей-агрегатов или просто автономных сущностей (это важно, потому, что изменением подчиненных сущностей, вероятно, должен заниматься метод агрегата). Мне кажется, инкапсулируя поведение и соблюдение инвариантов сущности в нее саму, мы существенно упрощаем логику внешних сервисов: сервис знает интерфейс сущности, и программисту сервиса нет необходимости думать о реализации этой логики и, возможно, даже знать о ней. Это освобождает оперативную память в голове )
Поясните, пожалуйста, Вы про анимичную модель или про что-то другое? Если второе, то расскажите подробнее, пожалуйста.
Я, честно, еще далек от как полного понимания ДДД так и от его реализации при помощи многослойных архитектур (события, транзакции через единицы работы, определение границ агрегатов и другие моменты - все это вызывает больше вопросов, чем является для меня рабочим инструментом, тем более что, для условий PHP эти паттерны нужно переосмысливать), но хотелось бы уточнить такие моменты:
1) "В DDD часто используют интерфейс репозитория в доменном слое, а реальную реализацию помещают в инфраструктурный слой."
Мне кажется, что взаимодействие с репозиториями скорее должно быть на уровне приложения (use-cases), а доменные сервисы должны работать с уже готовыми сущностями и не заморачиваться вопросами получения/сохранения. Возможно, у Вас есть примеры, когда предпочитаемый мной подход не срабатывает? Но в других местах статьи Вы помещаете обращения к репозиториям в слой приложения. Просто опечатка?
2) "Например, Entity отвечает за данные, Domain Service - за бизнес-логику, а Infrastructure Service - за взаимодействие с внешними системами."
Вы исключаете логику из Entity, т.е. выступаете за анемичную модель? Но в другом месте Вы же пишете:
"Симптом: файл
domain.ts, в котором вроде бы описаны Entities, а по факту там класс ради класса. Или Value Object, который не содержит никакой логики, а просто один кортеж полей."Т.е. критикуете анимичную модель. Поясните! )
3) Вы не рекомендуете создавать ValueObjects, если они не содержат логику, но, у меня есть соображение, для чего полезны ValueObject без логики: они обеспечивают строгость типизации по бизнесовым принципам. Например, если сервис вычисления среднего значения получает два числа, мы можем случайно отправить в него одновременно вес и длину - они оба числовые, но вот что за значение мы получим на выходе? С другой стороны, при создании классов Weight и Length, перепутать будет сложно, но понадобится два сервиса/метода, причем, не только для вычисления среднего, но и для сложения/вычитания, если это нужно для бизнеса )
4) Поскольку метод pay() в сущности Order реализует просто изменение статуса заказа на "Оплачено", возможно, название стоило уточнить на что-то вроде markAsPaid, чтобы не смешивать с сервисом, который будет реализовывать логику связанную со списанием/зачислением денег и не путать других читателей-комментаторов ).
Бегло почитал про лямбды в облаках... На первый взгляд похоже на перерождение PHP: процесс собирается с нуля, выполняется и умирает. )
Я такси часто использую, когда опаздываю. Если приложение машину сначала 5 минут ищет, а потом машина 10 минут едет, то от выигрыша остается уже не так и много.