Можно попробую ответить?) Вы когда результат с базы получаете можете его весь протолкнуть под типом "результат получения заказа" в конструктор программного объекта и обработать.
Если честно в статье постоянно об что-то спотыкаешься (как будто вы сами не до конца разобрались) например:
Из функционального программирования я бы порекомендовал взять уважение к неизменяемым структурам данных и избегание сайд-эффектов, где это возможно (например, CQS).
Если открыть вашу ссылку на вики, то там видно что cqs это больше про ООП
Идея была в том что когда тебе лень, можно потрудиться (выучить построение кода в данном случае) чтобы потом меньше работать) Собственно архитектурные решения и направлены на уменьшение сложности работы над проектом) Но так как лень, тема не расскрыта
Проба своих литературных возможностей, смогу ли я передать свое чувство лени которое посетило меня в момент когда я открыл проект, и судя по первому комментарию к статье у меня получилось)
Ну и плюсом это ощущение на много сильнее и чаще появляется когда работаешь на "дядю"
Никто не спорит что мнение может поменяться. Про паттерны ООП я слышу примерно тоже самое, но мне и они нравятся. Цели убедить что именно какой-то "мой" подход в который я верю правильный у меня нету, как и доказывать что-то, пользуйтесь чем хотите, ну и собственно я буду пользоваться чем хочу.
Что значит с логикой в сущностях? А если у вас не DDD, а ООП то логика где? Мне кажется вы тоже не так видите DDD, DDD это концепция бизнес разработки, когда все в контексте, все понимают что делают, как и для чего. Выделите в коде свои (бизнес) действия и выделите действия с инфраструктурой этого самого кода, напишите "словарь" для этого и ходите объясняйте-продавайте, что вы все за код цепляетесь, если вам нужно понизить сложность, есть прекрасные паттерны ООП, а еще есть теория что весь код (при попытке перейти на чистую архитектуру) скатывается к гексогональной архитектуре (где-то читал, не могу сейчас найти если честно) тоесть на взаимодействии через интерфейсы на уровне слоев.
В первом моем комментарии на который вы отвечали всетаки идет разговор про реализацию объектов в коде, это никак не зависит от бизнеса. Окей, если это правило DDD, то у меня свой DDD, от которого я взял все плюсы (по моему мнению) и все же программист решает что будет в коде, а не кто-то еще.
Функциональные программисты тоже могут решить бизнес задачу, и без объектов. Я маленько не об этом. Все же вы не сможете прямо на кодовых объектах общаться с бизнесом)
Мне кажется вы маленько не туда смотрите, всетаки проблема которую решает DDD - помощь при разработке, когда разработчик не погружен глубоко в область, по идее вы должны бизнес процессы перевести в код и общаться в компании в контексте этих кодовых процесов. Отсюда и часть проблемы будет уже ее решением (бизнес будет понимать что вы делаете с кодом, что меняете). Получается что по инверсии зависимостей все приложение будет зависить от бизнес контекста (домена), а не наоборот, что и придает некую чистоту проекту.
А как по факту там ООП или еще что-то, это маленько про другое. По поводу слоистости и чистоты (поддерживаемости кода), как мне кажется, разработчик рано или поздно сам приходит к этому, поэтому она, наверное, как некий факт воспринимается в контексте DDD.
Можно попробую ответить?) Вы когда результат с базы получаете можете его весь протолкнуть под типом "результат получения заказа" в конструктор программного объекта и обработать.
Если честно в статье постоянно об что-то спотыкаешься (как будто вы сами не до конца разобрались) например:
Если открыть вашу ссылку на вики, то там видно что cqs это больше про ООП
Ну и блок схемы ваши конечно прекрасны
Спасибо за поддержку, выгорание и правда важная тема в нашей работе. А так, это попытка выехать на отрицательном хейте, ну и к слову - 19к просмотров)
Идея была в том что когда тебе лень, можно потрудиться (выучить построение кода в данном случае) чтобы потом меньше работать) Собственно архитектурные решения и направлены на уменьшение сложности работы над проектом) Но так как лень, тема не расскрыта
Проба своих литературных возможностей, смогу ли я передать свое чувство лени которое посетило меня в момент когда я открыл проект, и судя по первому комментарию к статье у меня получилось)
Ну и плюсом это ощущение на много сильнее и чаще появляется когда работаешь на "дядю"
Ради этого все и затевалось
Из вашего сообщения следует что все ООП это DDD? Но не каждое DDD это ООП?))
Ну и кстати, если прослеживать комментарии с самого начала, то вы занимаетесь манипуляцией
А может и не быть ООП, правильно? Или DDD доступно только в проектах где ООП языки?
Никто не спорит что мнение может поменяться. Про паттерны ООП я слышу примерно тоже самое, но мне и они нравятся. Цели убедить что именно какой-то "мой" подход в который я верю правильный у меня нету, как и доказывать что-то, пользуйтесь чем хотите, ну и собственно я буду пользоваться чем хочу.
Спасибо за статью!
DDD это не только про код, тут надо брать 2 команды и сравнивать если вы хотите каких-то цифр.
А так, я в процесе работы сам пришел к чему-то похожему, все же мы одно дело делаем (стараемся).
Что значит с логикой в сущностях? А если у вас не DDD, а ООП то логика где? Мне кажется вы тоже не так видите DDD, DDD это концепция бизнес разработки, когда все в контексте, все понимают что делают, как и для чего. Выделите в коде свои (бизнес) действия и выделите действия с инфраструктурой этого самого кода, напишите "словарь" для этого и ходите объясняйте-продавайте, что вы все за код цепляетесь, если вам нужно понизить сложность, есть прекрасные паттерны ООП, а еще есть теория что весь код (при попытке перейти на чистую архитектуру) скатывается к гексогональной архитектуре (где-то читал, не могу сейчас найти если честно) тоесть на взаимодействии через интерфейсы на уровне слоев.
Промазал веткой
В текущем проекте они лежат в бизнес логике, но они не чистые table module, а с примесью entity
В первом моем комментарии на который вы отвечали всетаки идет разговор про реализацию объектов в коде, это никак не зависит от бизнеса. Окей, если это правило DDD, то у меня свой DDD, от которого я взял все плюсы (по моему мнению) и все же программист решает что будет в коде, а не кто-то еще.
Функциональные программисты тоже могут решить бизнес задачу, и без объектов. Я маленько не об этом. Все же вы не сможете прямо на кодовых объектах общаться с бизнесом)
Мне кажется вы маленько не туда смотрите, всетаки проблема которую решает DDD - помощь при разработке, когда разработчик не погружен глубоко в область, по идее вы должны бизнес процессы перевести в код и общаться в компании в контексте этих кодовых процесов. Отсюда и часть проблемы будет уже ее решением (бизнес будет понимать что вы делаете с кодом, что меняете). Получается что по инверсии зависимостей все приложение будет зависить от бизнес контекста (домена), а не наоборот, что и придает некую чистоту проекту.
А как по факту там ООП или еще что-то, это маленько про другое. По поводу слоистости и чистоты (поддерживаемости кода), как мне кажется, разработчик рано или поздно сам приходит к этому, поэтому она, наверное, как некий факт воспринимается в контексте DDD.
Объект в коде решает только задачу объекта в коде, есть процесс и вы его объясняете компьютеру (и себе) на объектах.
Что по вашему значит DDD сущность? Типо у вас половина кода DDD, а половина нет? Это ведь не так работает
Классно что есть люди кто думает своей головой и не ведётся на хайп