как Разбивать базу проекта на Domain и Application Logic

fixxxer

К.О.
Партнер клуба
Да меня в общем то пока не ddd интересует, а только разделение на слои и подход с Service Layer и как все это варится.
Чтобы разделять, в этом нужен какой-то смысл. Разделение ради разделения смысла не имеет.

Если хочешь ответа на вопрос - отошлю к литературе: Vernon, Implementing DDD. Пытаться пересказать своими словами 500 страниц книги в рамках комментария на форуме считаю бессмысленным, очень легко упустить суть.
 

ivanov77

Новичок
Я не на дао DDD и подобные решения для интерпрайза нацелился.
Чисто на слои, про которые уже писали еще до ddd, вот как у фаулера, его же книга не про ddd.

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

fixxxer

К.О.
Партнер клуба
Тогда просто начни с написания кода, который легко тестировать. По TDD.
Если тест написать просто, этого достаточно для низкой связности.
Только это должен быть честный юнит-тест, а не что-то, что инициализирует половину фреймворка и требует доступ к базе данных.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@Adelf и @WMix
Работал я недавно с тем случаем, когда проект писали студенты, а он взял и вырос.
Ну, как - продажникам нужен модуль, программеры расписаны, поручили джуниорам быстро запустить - ну, и потом переписать. Джуниоры сделали, как-то запустили, а потом все уволились.
Документации мало - надо быстрее выкатить. Соответственно, никого вообще не увольняют, иначе код некому поддерживать, а логика там сложная.

В общем, этот подход к разработке привел к тому, что в компании собралось порядка 200 человек, которые годами фиксят баги и тушат пожары. Им постоянно очень не хватает программистов. Посчитай цену такой экономии в 5-летнем промежутке.
 
Последнее редактирование:

Adelf

Administrator
Команда форума
Отлично. Отрасль растет :) Все хорошо.
Продвигать хороший код вредно! А то, не дай бог, нужда в миллионах программистов отпадет...
 

Вурдалак

Продвинутый новичок
Джуниоры сделали, как-то запустили, а потом все уволились.
<...>
В общем, этот подход к разработке привел к тому, что в компании собралось порядка 200 человек, которые годами фиксят баги и тушат пожары. Им постоянно очень не хватает программистов. Посчитай цену такой экономии в 5-летнем промежутке.
AR очень хорош в большинстве CRUD-операций. Особенно - вместе с генератором кода, <...> Время разработки простейших операций сокращается раз в 20, скорость исполнения падает на проценты.
Есть участок задач, которые надо сделать как можно дешевле, и поддерживать их не предполагается. А если и надо будет менять - то через много лет.
У денег есть цена - деньги в будущем гораздо дешевле, чем сегодня. Поэтому автогенерация бывает экономически выгодна.
С учетом того, что из MVP что-то вырастает в 0.5% случаев - это в целом выгодно. <...> Дальше при росте стоимость владения выходит высоковата, ну что ж теперь.
*Дьявольский смех*
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Дело в том, что это никакое не противоречие.
Описываемая ситуация - не MVP, это большой enterprise. Там нет Active Record, не было генерации кода. Там статика :) "Классы нужны потому что автозагрузка так сделана." (С) Senior Principal Applications Developer, Oracle corp.

ActiveRecord я наблюдаю в другом проекте - небольшой, но много лет в разработке. Все нормально с Active Record . Важно держать классы компактными, думать про инкапсуляцию и декомпозицию, для нового функционала - SOA.
Guns don't kill people - people kill people.
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
@grigori, ну так с микросервисами, если на них вменяемо разбивать, получатся те же ddd-шные bounded contexts. :) Если контексты маленькие, можно даже и с тупым rest/crud нормально жить, костылями обрастет не сильно. Ну и наоборот, в ddd-коде каждый bounded context можно безболезненно вынести в отдельный микросервис.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Да, я о том же. По сути вопроса, DDD - это вообще не про код, не про слои, не про классы. Низкоуровневая архитектура - вот это про Active Record.
А в DDD главное - это описать терминологию и выделить контексты. Человеческим языком.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Ты даже процитировал: это относится к коду, который поддерживать не предполагается.
Вот если так делать код, про который знаешь, что потом придется переписывать - ничего не выйдет.

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

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

WMix

герр M:)ller
Партнер клуба
а обьясните плиз, что за проблема в crud, ну в смысле любой mapper или dao оно по сути и есть crud или я чтото не понимаю?
PHP:
interface Mapper{
  public create(Entity $obj): int;
  public read(int $id): Entity;
  public update(Entity $obj): void;
  public delete(Entity $obj): void;
}
логике домена от этого ни горяче не холодно
 

fixxxer

К.О.
Партнер клуба
@WMix, на уровне инфраструктуры персистенции, конечно, никакой проблемы нет (я мог бы, конечно, придраться к create():int, но не буду ;)).
Проблема возникает, когда это просачивается наружу.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Проблема возникает когда на это вешают зависимости в другом функционале. Когда это простой REST, или листинг с пангинацией, как частный случай - проблем не возникает.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
в чем суть ненавистного антипаттерна ActiveRecord:
1. interface Mapper реализуется в классе маппинга на конкретную таблицу. Наследование от базового класса мапперов неважно.
2. Слой логики приложения пропускается. Вызовы CRUD пишутся прямо в контроллере. $Users->find($user_id);
3. Валидация данных пропускается - все в параметрах метода контроллера. public function getUser($user_id int): string
4. API привязан к структуре базы. http://site.com/users/1234
5. клик мышкой, ура, у меня список пользователей в админке
 
Сверху