Скажу по секрету олимпиадники не всегда хорошо адаптируются к промышленному программированию после окончания вузов. Решить задачку это не систему спроектировать.
ООО... понятно. Без разницы. Структура в гошке/сях это суть есть состояние. То есть сущность и/или vo, агрегат. Без разницы. Интерфейсы для состояний это конечно сильно))
И то что ты в данном контексте видишь в них разницу уже говорит о плохом понимании доменного подхода. Сорян что задеваю самолюбие но это факт. Ниче. Ещё научишься. Удачи и все смайлики мира тебе)))
"структуру допустимо изменять только в рамках определенного интерфейса." интерфейс для состояния? блин как это я сразу не заметил. Чел - ты даже приблизительно не понимаешь о чем говоришь - это чушь страшная. Модели и VO это единичные бизнес концепции и не подразумевают вариативности. ЗЫ: как то на собесе мне предложили привести пример open/close принципа для модели)) я спросил "это что подвох?" - приняли за правильный ответ))
вот именно - бизнесу надо ехать и для этого он спрашивает диспетчера(тебя) что делать, а ты говоришь что шашечки не важны можно и на пожарной машине ехать и тоже доедешь. Мусье знает толк в извращениях. ДДД на гошке - охохох
Конечно чуть иначе. Конечно тоже можно. Просто всего лишь надо уметь готовить
И цветы можно куриным супом поливать. В нем тоже есть вода. Вода всего лишь жидкость для полива цветов(ООП всего лишь инструмент) Просто надо знать нюансы борьбы с плесенью. А так вполне достижимо.
Можно небоскребы из древесины строить. У моего дедушки баня из бревен и ничего не ломается уже полвека. Железобетон всего лишь конструкционная необходимость.
Блин ну как можно в одном коменте сообщить что ООП это инструмент. И тут же сообщить этот инструмент не обязателен.
Молоток всего лишь нужен чтобы гвозди забивать. На тебе статью как забивали гвозди топором и все забили успешно.
Могу немного раскрыть тему если тебе не скучно это. Я сегодня добрый)
Ддд это про приближение к мышлению человечков. Всепроникающий язык, бизнес сущности итд. ООП это уже шаг в этом направлении. Ддд исправляет ошибки горе программистов(анемичная модель нарушает инкапсуляцию как минимум) и делает следующий шаг. Ты справедливо заметил что ООП это инструмент. И это именно инструмент описания бизнеса. То есть логики приложения приближенно к мышлению кожаных мешков. Конечно можно притянуть это и в гошку. Но зачем? Инструмент уже создан. Специальный.
Кстати это ответ и на комментарий выше. DDD light? Чивооо? Костыли только рождают новые костыли. Плавали знаем. Попытки частичного внедрения возможны, но надо очень сильно быть тёртым дддшником и то лучше не надо. Скорее всего будет хуже. И это не только мое мнение.
Скорее согласен, но с допущениями. То есть некоторые паттерны(стратегические тоже) применимы в принципе и сами по себе. Но как ансамбль DDD красиво работает там где родилось. То есть для ООП. Это как Event Sourcing и CQRS. Можно готовить и по отдельности, но такого импакта как вместе не достичь. Синергия уже не та.
Вот при этом и CQRS. Query отдельно, с разными представлениями, собираемыми из разных агрегатов и/или уже хранящихся собранными. И кстати возможно в разных bounded contexts, то есть возможно Вам просто надо разные варианты сущности из разных контекстов вместо разных представлений. А в командной части будут лежать честные агрегаты. Отвечающие только за свою консистентность. Агрегат это термин программирования. Что в ddd что в uml. Так же как ассоциация. Это тип связи. Иначе возникает много вопросов и придется пояснять за агрегат каждому встречному)
CQRS? Агрегат это граница консистентности, а не одно большое представление вроде бы как. Если он не меняется транзакционно весь целиком, то без разницы что многие ассоциации включены в представление. Да ещё и в разные. Короче, этот монстр не агрегат.
Скажу по секрету олимпиадники не всегда хорошо адаптируются к промышленному программированию после окончания вузов. Решить задачку это не систему спроектировать.
"как вы можете выбрать между монолитом и микросервисами?"
Даже выбирать не буду. Сразу модульный монолит. Микросервисы хороши только для докладов на симпозиумах.
Мне надоело. Я спать
И опять же костыли
Дык интерфейс не нужен
ООО... понятно. Без разницы. Структура в гошке/сях это суть есть состояние. То есть сущность и/или vo, агрегат. Без разницы. Интерфейсы для состояний это конечно сильно))
И то что ты в данном контексте видишь в них разницу уже говорит о плохом понимании доменного подхода. Сорян что задеваю самолюбие но это факт. Ниче. Ещё научишься. Удачи и все смайлики мира тебе)))
"структуру допустимо изменять только в рамках определенного интерфейса." интерфейс для состояния? блин как это я сразу не заметил. Чел - ты даже приблизительно не понимаешь о чем говоришь - это чушь страшная. Модели и VO это единичные бизнес концепции и не подразумевают вариативности.
ЗЫ: как то на собесе мне предложили привести пример open/close принципа для модели)) я спросил "это что подвох?" - приняли за правильный ответ))
вот именно - бизнесу надо ехать и для этого он спрашивает диспетчера(тебя) что делать, а ты говоришь что шашечки не важны можно и на пожарной машине ехать и тоже доедешь.
Мусье знает толк в извращениях. ДДД на гошке - охохох
Конечно чуть иначе. Конечно тоже можно. Просто всего лишь надо уметь готовить
И цветы можно куриным супом поливать. В нем тоже есть вода. Вода всего лишь жидкость для полива цветов(ООП всего лишь инструмент) Просто надо знать нюансы борьбы с плесенью. А так вполне достижимо.
Можно небоскребы из древесины строить. У моего дедушки баня из бревен и ничего не ломается уже полвека. Железобетон всего лишь конструкционная необходимость.
Блин ну как можно в одном коменте сообщить что ООП это инструмент. И тут же сообщить этот инструмент не обязателен.
Молоток всего лишь нужен чтобы гвозди забивать. На тебе статью как забивали гвозди топором и все забили успешно.
Могу немного раскрыть тему если тебе не скучно это. Я сегодня добрый)
Ддд это про приближение к мышлению человечков. Всепроникающий язык, бизнес сущности итд. ООП это уже шаг в этом направлении. Ддд исправляет ошибки горе программистов(анемичная модель нарушает инкапсуляцию как минимум) и делает следующий шаг. Ты справедливо заметил что ООП это инструмент. И это именно инструмент описания бизнеса. То есть логики приложения приближенно к мышлению кожаных мешков. Конечно можно притянуть это и в гошку. Но зачем? Инструмент уже создан. Специальный.
Кстати это ответ и на комментарий выше. DDD light? Чивооо? Костыли только рождают новые костыли. Плавали знаем. Попытки частичного внедрения возможны, но надо очень сильно быть тёртым дддшником и то лучше не надо. Скорее всего будет хуже. И это не только мое мнение.
Скорее согласен, но с допущениями. То есть некоторые паттерны(стратегические тоже) применимы в принципе и сами по себе. Но как ансамбль DDD красиво работает там где родилось. То есть для ООП. Это как Event Sourcing и CQRS. Можно готовить и по отдельности, но такого импакта как вместе не достичь. Синергия уже не та.
Я и не такое про DDD читал. Не удивительно. Шарлатаны цветут и пахнут.
А как бы ниче тот факт что как бы эээ ... Это сборник бест практикс для ООП.
DDD без ООП? Лихо
Эмпирически.
Нда
Опять забыли про Presentation и отнесли его к инфраструктуре. Маразм крепчает.
Вот при этом и CQRS. Query отдельно, с разными представлениями, собираемыми из разных агрегатов и/или уже хранящихся собранными. И кстати возможно в разных bounded contexts, то есть возможно Вам просто надо разные варианты сущности из разных контекстов вместо разных представлений. А в командной части будут лежать честные агрегаты. Отвечающие только за свою консистентность. Агрегат это термин программирования. Что в ddd что в uml. Так же как ассоциация. Это тип связи. Иначе возникает много вопросов и придется пояснять за агрегат каждому встречному)
CQRS? Агрегат это граница консистентности, а не одно большое представление вроде бы как. Если он не меняется транзакционно весь целиком, то без разницы что многие ассоциации включены в представление. Да ещё и в разные. Короче, этот монстр не агрегат.
Use case вызывает use case? Напрямую? И потом концов не собрать. А внутри транзакции дергать? Или пусть будут более одной и минус атомарность?