-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
как Разбивать базу проекта на Domain и Application Logic
- Автор темы ВеликийПрограмист
- Дата начала
Чтобы разделять, в этом нужен какой-то смысл. Разделение ради разделения смысла не имеет.
Если хочешь ответа на вопрос - отошлю к литературе: Vernon, Implementing DDD. Пытаться пересказать своими словами 500 страниц книги в рамках комментария на форуме считаю бессмысленным, очень легко упустить суть.
ivanov77
Новичок
Я не на дао DDD и подобные решения для интерпрайза нацелился.
Чисто на слои, про которые уже писали еще до ddd, вот как у фаулера, его же книга не про ddd.
То что ddd требует себе слои, это уже следствие того что слои видимо стоящая штука. Как например фреймы требуют pdo, так и ddd для воплощения каких то своих идей требует слои.
Про смысл разделения я читал - высокое зацепление и низкая связность, возможность тестировать сервисы, в моделях прибраться...
Чисто на слои, про которые уже писали еще до ddd, вот как у фаулера, его же книга не про ddd.
То что ddd требует себе слои, это уже следствие того что слои видимо стоящая штука. Как например фреймы требуют pdo, так и ddd для воплощения каких то своих идей требует слои.
Про смысл разделения я читал - высокое зацепление и низкая связность, возможность тестировать сервисы, в моделях прибраться...
@Adelf и @WMix
Работал я недавно с тем случаем, когда проект писали студенты, а он взял и вырос.
Ну, как - продажникам нужен модуль, программеры расписаны, поручили джуниорам быстро запустить - ну, и потом переписать. Джуниоры сделали, как-то запустили, а потом все уволились.
Документации мало - надо быстрее выкатить. Соответственно, никого вообще не увольняют, иначе код некому поддерживать, а логика там сложная.
В общем, этот подход к разработке привел к тому, что в компании собралось порядка 200 человек, которые годами фиксят баги и тушат пожары. Им постоянно очень не хватает программистов. Посчитай цену такой экономии в 5-летнем промежутке.
Работал я недавно с тем случаем, когда проект писали студенты, а он взял и вырос.
Ну, как - продажникам нужен модуль, программеры расписаны, поручили джуниорам быстро запустить - ну, и потом переписать. Джуниоры сделали, как-то запустили, а потом все уволились.
Документации мало - надо быстрее выкатить. Соответственно, никого вообще не увольняют, иначе код некому поддерживать, а логика там сложная.
В общем, этот подход к разработке привел к тому, что в компании собралось порядка 200 человек, которые годами фиксят баги и тушат пожары. Им постоянно очень не хватает программистов. Посчитай цену такой экономии в 5-летнем промежутке.
Последнее редактирование:
Вурдалак
Продвинутый новичок
Дело в том, что это никакое не противоречие.
Описываемая ситуация - не MVP, это большой enterprise. Там нет Active Record, не было генерации кода. Там статика
"Классы нужны потому что автозагрузка так сделана." (С) Senior Principal Applications Developer, Oracle corp.
ActiveRecord я наблюдаю в другом проекте - небольшой, но много лет в разработке. Все нормально с Active Record . Важно держать классы компактными, думать про инкапсуляцию и декомпозицию, для нового функционала - SOA.
Guns don't kill people - people kill people.
Описываемая ситуация - не MVP, это большой enterprise. Там нет Active Record, не было генерации кода. Там статика
"Классы нужны потому что автозагрузка так сделана." (С) Senior Principal Applications Developer, Oracle corp.ActiveRecord я наблюдаю в другом проекте - небольшой, но много лет в разработке. Все нормально с Active Record . Важно держать классы компактными, думать про инкапсуляцию и декомпозицию, для нового функционала - SOA.
Guns don't kill people - people kill people.
Последнее редактирование:
@grigori, ну так с микросервисами, если на них вменяемо разбивать, получатся те же ddd-шные bounded contexts. Если контексты маленькие, можно даже и с тупым rest/crud нормально жить, костылями обрастет не сильно. Ну и наоборот, в ddd-коде каждый bounded context можно безболезненно вынести в отдельный микросервис.
Если контексты маленькие, можно даже и с тупым rest/crud нормально жить, костылями обрастет не сильно. Ну и наоборот, в ddd-коде каждый bounded context можно безболезненно вынести в отдельный микросервис.
Ты даже процитировал: это относится к коду, который поддерживать не предполагается.
Вот если так делать код, про который знаешь, что потом придется переписывать - ничего не выйдет.
Разница подходов зависит от размера проекта. В крупном проекте менеджеры сверху спускают задачу менеджерам снизу, и там наверху никого не интересует, можно ли ее сделать. Разработчиков нет, интернет отключили, или офис залило - никого не спрашивают о реализуемости задачи, ее просто ставят. Менеджеры внизу выкручиваются как могут, чтобы попасть наверх - нанимают студентов, обманывают, приказывают делать плохо.
Тут имеет смысл ввести guidelines, как ты всегда говоришь, и следить за качеством везде, чтобы мудаки не могли приказать делать плохо там, где нельзя.
Менеджеры нарушают правила, конечно, но когда правила есть - нарушение можно озвучить на совещании, и у менеджера начинает болеть задница. Тут в твоих принципах есть большой смысл.
А когда проект небольшой - обсуждается каждая задача. Нет ресурсов - меняют планы, подстраиваются. В одном месте вкладываются, на другом - экономят. Маленькие проекты в итоге побеждают, становятся крупными, и обрастают эффективными менеджерами.
Вот если так делать код, про который знаешь, что потом придется переписывать - ничего не выйдет.
Разница подходов зависит от размера проекта. В крупном проекте менеджеры сверху спускают задачу менеджерам снизу, и там наверху никого не интересует, можно ли ее сделать. Разработчиков нет, интернет отключили, или офис залило - никого не спрашивают о реализуемости задачи, ее просто ставят. Менеджеры внизу выкручиваются как могут, чтобы попасть наверх - нанимают студентов, обманывают, приказывают делать плохо.
Тут имеет смысл ввести guidelines, как ты всегда говоришь, и следить за качеством везде, чтобы мудаки не могли приказать делать плохо там, где нельзя.
Менеджеры нарушают правила, конечно, но когда правила есть - нарушение можно озвучить на совещании, и у менеджера начинает болеть задница. Тут в твоих принципах есть большой смысл.
А когда проект небольшой - обсуждается каждая задача. Нет ресурсов - меняют планы, подстраиваются. В одном месте вкладываются, на другом - экономят. Маленькие проекты в итоге побеждают, становятся крупными, и обрастают эффективными менеджерами.
Последнее редактирование:
а обьясните плиз, что за проблема в 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;
}
).Вурдалак
Продвинутый новичок
Что имеется в виду?
в чем суть ненавистного антипаттерна 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. клик мышкой, ура, у меня список пользователей в админке
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. клик мышкой, ура, у меня список пользователей в админке