Что значит с логикой в сущностях? А если у вас не DDD, а ООП то логика где? Мне кажется вы тоже не так видите DDD, DDD это концепция бизнес разработки, когда все в контексте, все понимают что делают, как и для чего. Выделите в коде свои (бизнес) действия и выделите действия с инфраструктурой этого самого кода, напишите "словарь" для этого и ходите объясняйте-продавайте, что вы все за код цепляетесь, если вам нужно понизить сложность, есть прекрасные паттерны ООП, а еще есть теория что весь код (при попытке перейти на чистую архитектуру) скатывается к гексогональной архитектуре (где-то читал, не могу сейчас найти если честно) тоесть на взаимодействии через интерфейсы на уровне слоев.
В первом моем комментарии на который вы отвечали всетаки идет разговор про реализацию объектов в коде, это никак не зависит от бизнеса. Окей, если это правило DDD, то у меня свой DDD, от которого я взял все плюсы (по моему мнению) и все же программист решает что будет в коде, а не кто-то еще.
Функциональные программисты тоже могут решить бизнес задачу, и без объектов. Я маленько не об этом. Все же вы не сможете прямо на кодовых объектах общаться с бизнесом)
Мне кажется вы маленько не туда смотрите, всетаки проблема которую решает DDD - помощь при разработке, когда разработчик не погружен глубоко в область, по идее вы должны бизнес процессы перевести в код и общаться в компании в контексте этих кодовых процесов. Отсюда и часть проблемы будет уже ее решением (бизнес будет понимать что вы делаете с кодом, что меняете). Получается что по инверсии зависимостей все приложение будет зависить от бизнес контекста (домена), а не наоборот, что и придает некую чистоту проекту.
А как по факту там ООП или еще что-то, это маленько про другое. По поводу слоистости и чистоты (поддерживаемости кода), как мне кажется, разработчик рано или поздно сам приходит к этому, поэтому она, наверное, как некий факт воспринимается в контексте DDD.
Наверное потому что это в какой-то степени как картина, DDD у всех одно (условно простые фигуры/примитивы из рисования) но результат у всех разный, который зависит от компетенции архитектора.
Да и темболее, я сейчас читаю книгу банды четырёх, и там говорится что вы не можете просто взять код условного паттерна и вставить в свой проект, это больше про мысль, а так вы можете хоть все паттерны перемешать вместе, или один другим заменять, в книге они приводят примеры какой патерн можно каким заменить например.
Например в текущем проекте я взял что-то из MVC (контроллеры) и паттерн ООП - команда. Пользователь через точку входа (контроллер) отправляет запрос, формируется пул команд (от 1 до бесконечности) выполняется, обрабатывается и возвращается пользователю результат. Это все очень хорошо ложится друг с другом, и вникнуть в проект проще когда каждая его часть формализована, а не просто работает.
У вас не должно быть в проекте деление на DDD сущности и сущности базы данных. Система в базу должна сохранять результат выполнения своей логики. Мне например ближе TableModule и не надо никаких объектов городить с огромными конструкторами.
По поводу кстати большого количество переменных в конструкторе, в книге по ООП написано - метод должен ожидать в параметрах объект, а не кучу значений с указанием примитивов языка.
Мне кажется заказ это как раз плохой пример, у вас всетаки продукт это отдельный объект, а корзина это объект который в себя собирает объекты продукта, вы же не в свойства объекта корзины пихаете все продукты? (Так можно делать, если объект корзины содержит поле под массив объектов продукта)
Ну и всеже вы не обновляете объект ради обновления, вы хотите сохранить информацию о заказе и редактируете хранилище свое, а тут можно 1 функцией и 1 sql запросом обойтись, а не делать апдейт на каждое поле.
Не обязательно у клиентского кода (а скорее даже обязательно не должно быть) доступа к изменению свойств объекта просто по желанию, обычно это должно быть реакцией на что либо самого объекта, иначе, сами подумайте, какой смысл закрывать свойства объекта, но позволять в любом месте просто менять их?
Вы наверное просто не видели как раньше, до времен огромных компаний, которые разрекламировали "советующие" нейросети и напихали их в каждую дыру (хочу заметить что многие из них вообще бесплатные), пытались продать эти самые нейросети бизнесу. Тогда это выглядело как табличка с цифрами или в лучшем случае график и все это на питоне.
Забавно что во всех этих революциях как-то замалчиваются Индусы выдающие себя за нейросети или автопилот теслы который продавали как искусственный интеллект, но работало все на с++, мне кажется если держать это в голове, то и такого восторга не будет.
Очень много текста конечно, но как по мне вы в кучу скидываете понятия хоть чучуть пересекающиеся и из-за этого качество изложенного страдает (моё мнение). DDD никак не протеворечет/запрещает паттерны ООП или какие либо ещё. Домен не является неизменяемым фундаментом на всем цикле жизни приложения, домен нужен для строгой инверсии зависимости и изоляции кода который отвечает за бизнес логику от кода который помогает этой бизнес логике работать с технической точки зрения.
Мне кажется вы причино следственные связи путаете. То что человек завернул нейросеть в удобный интерфейс и продаёт как революцию, а результат работы нейросети может даже отталкивать.
DDD это не только про код, тут надо брать 2 команды и сравнивать если вы хотите каких-то цифр.
А так, я в процесе работы сам пришел к чему-то похожему, все же мы одно дело делаем (стараемся).
Что значит с логикой в сущностях? А если у вас не DDD, а ООП то логика где? Мне кажется вы тоже не так видите DDD, DDD это концепция бизнес разработки, когда все в контексте, все понимают что делают, как и для чего. Выделите в коде свои (бизнес) действия и выделите действия с инфраструктурой этого самого кода, напишите "словарь" для этого и ходите объясняйте-продавайте, что вы все за код цепляетесь, если вам нужно понизить сложность, есть прекрасные паттерны ООП, а еще есть теория что весь код (при попытке перейти на чистую архитектуру) скатывается к гексогональной архитектуре (где-то читал, не могу сейчас найти если честно) тоесть на взаимодействии через интерфейсы на уровне слоев.
Промазал веткой
В текущем проекте они лежат в бизнес логике, но они не чистые table module, а с примесью entity
В первом моем комментарии на который вы отвечали всетаки идет разговор про реализацию объектов в коде, это никак не зависит от бизнеса. Окей, если это правило DDD, то у меня свой DDD, от которого я взял все плюсы (по моему мнению) и все же программист решает что будет в коде, а не кто-то еще.
Функциональные программисты тоже могут решить бизнес задачу, и без объектов. Я маленько не об этом. Все же вы не сможете прямо на кодовых объектах общаться с бизнесом)
Мне кажется вы маленько не туда смотрите, всетаки проблема которую решает DDD - помощь при разработке, когда разработчик не погружен глубоко в область, по идее вы должны бизнес процессы перевести в код и общаться в компании в контексте этих кодовых процесов. Отсюда и часть проблемы будет уже ее решением (бизнес будет понимать что вы делаете с кодом, что меняете). Получается что по инверсии зависимостей все приложение будет зависить от бизнес контекста (домена), а не наоборот, что и придает некую чистоту проекту.
А как по факту там ООП или еще что-то, это маленько про другое. По поводу слоистости и чистоты (поддерживаемости кода), как мне кажется, разработчик рано или поздно сам приходит к этому, поэтому она, наверное, как некий факт воспринимается в контексте DDD.
Объект в коде решает только задачу объекта в коде, есть процесс и вы его объясняете компьютеру (и себе) на объектах.
Что по вашему значит DDD сущность? Типо у вас половина кода DDD, а половина нет? Это ведь не так работает
Классно что есть люди кто думает своей головой и не ведётся на хайп
Наверное потому что это в какой-то степени как картина, DDD у всех одно (условно простые фигуры/примитивы из рисования) но результат у всех разный, который зависит от компетенции архитектора.
Да и темболее, я сейчас читаю книгу банды четырёх, и там говорится что вы не можете просто взять код условного паттерна и вставить в свой проект, это больше про мысль, а так вы можете хоть все паттерны перемешать вместе, или один другим заменять, в книге они приводят примеры какой патерн можно каким заменить например.
Например в текущем проекте я взял что-то из MVC (контроллеры) и паттерн ООП - команда. Пользователь через точку входа (контроллер) отправляет запрос, формируется пул команд (от 1 до бесконечности) выполняется, обрабатывается и возвращается пользователю результат. Это все очень хорошо ложится друг с другом, и вникнуть в проект проще когда каждая его часть формализована, а не просто работает.
Еще тут (всмысле на Хабре) говорят что на каждый микросервис нужна своя база данных, как по мне тоже в минус микросервисам это можно записать)
У вас не должно быть в проекте деление на DDD сущности и сущности базы данных. Система в базу должна сохранять результат выполнения своей логики. Мне например ближе TableModule и не надо никаких объектов городить с огромными конструкторами.
По поводу кстати большого количество переменных в конструкторе, в книге по ООП написано - метод должен ожидать в параметрах объект, а не кучу значений с указанием примитивов языка.
Мне кажется заказ это как раз плохой пример, у вас всетаки продукт это отдельный объект, а корзина это объект который в себя собирает объекты продукта, вы же не в свойства объекта корзины пихаете все продукты? (Так можно делать, если объект корзины содержит поле под массив объектов продукта)
Ну и всеже вы не обновляете объект ради обновления, вы хотите сохранить информацию о заказе и редактируете хранилище свое, а тут можно 1 функцией и 1 sql запросом обойтись, а не делать апдейт на каждое поле.
Не обязательно у клиентского кода (а скорее даже обязательно не должно быть) доступа к изменению свойств объекта просто по желанию, обычно это должно быть реакцией на что либо самого объекта, иначе, сами подумайте, какой смысл закрывать свойства объекта, но позволять в любом месте просто менять их?
Нейросеть в текущей реализации не доберётся до стадии о которой можно филосовствовать
Вы наверное просто не видели как раньше, до времен огромных компаний, которые разрекламировали "советующие" нейросети и напихали их в каждую дыру (хочу заметить что многие из них вообще бесплатные), пытались продать эти самые нейросети бизнесу. Тогда это выглядело как табличка с цифрами или в лучшем случае график и все это на питоне.
Забавно что во всех этих революциях как-то замалчиваются Индусы выдающие себя за нейросети или автопилот теслы который продавали как искусственный интеллект, но работало все на с++, мне кажется если держать это в голове, то и такого восторга не будет.
Очень много текста конечно, но как по мне вы в кучу скидываете понятия хоть чучуть пересекающиеся и из-за этого качество изложенного страдает (моё мнение). DDD никак не протеворечет/запрещает паттерны ООП или какие либо ещё. Домен не является неизменяемым фундаментом на всем цикле жизни приложения, домен нужен для строгой инверсии зависимости и изоляции кода который отвечает за бизнес логику от кода который помогает этой бизнес логике работать с технической точки зрения.
Мне кажется вы причино следственные связи путаете. То что человек завернул нейросеть в удобный интерфейс и продаёт как революцию, а результат работы нейросети может даже отталкивать.
В DeepSeek глубокое рассуждение и описание нейросети каждого действия вроде из коробки идёт? Но, по моему, логики нейросетке это не прибавило