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