Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Для разработчика из видео выше это будет не так -- у него ДДД имеет доказанную пользу. Короче, это субъективщина. G>>Мне кажется ты не понимаешь суть слова "доказанную"...
S>Доказанную в кавычках, согласен. Типа работает. Применил ДДД -- получилось.
насколько я знаю примерно также доказывают "эффективность" гомеопатии.
S>>>Это можно решить в самый последний момент, согласно ДДД. Это детали. G>>Так вот мы пришли к этому моменту. Это одна таблица или нет? S>Ну какая разница-то для данного обсуждения?
Я бы сказал решающая, потому что ответ на этот вопрос это тот самый процесс проектирования, который я предлагаю пройти до конца чтобы проверить что DDD в принципе имеет смысл как методология.
S>>>На мой взгляд, скорее это методология, а не набор готовых рецептов. По-отдельности применять можно, но сложно. Точнее уже разбили на стратегически и тактические паттерны. G>>Пробелма в том, что без "тактических паттернов" методология DDD настолько очевидна, что смысла нет в отдельном названии. G>>Она сводится к трем вещам: G>>1) Универсальный язык для общения с заказчиком. По сути это раздел "термины и определения" из ТЗ по любому стандарту G>>2) Разделение проблемы на области — то что везде называние "модулями" (термин из структурного программирования) или "подсистемами" (термин из системной инженерии). В книге вернона и последующих даже упоминается иерархния (вложенность) областей, также как модули и подсистемы могут иметь вложенность. G>>3) Ограниченные контексты — единицы разработки и\или единицы деплоя. G>>Еще недавно появился EventStorming — по сути обычные брейнштормы, если отвязать их от event sourcing.
S>Да, вполне согласен. Не исключаю, что все эти моменты под одну крышуметодологию запихнули и все. Как-то так оно и есть. S>Потом решили развивать идею дальше, и появились тактические паттерны и тп.
См историю, тактические паттерны появились в начале. Все описал фаулер еще до эванса. Вся суть ДДД с самого начала — натягивание философии на паттерны. Когда модным стал CQRS — он появился в книгах DDD. Когда стали модными микросервисы — они тоже появились в книгах по DDD.
G>>Фактически ничего нового DDD не дает. Мы все это видели например в UML — диграммы компонентов это предметные области, а диаграммы развертывания, диаграммы юзкейсов, процессов и логической структуры. S>Ну тактические все-таки что-то новое, все эти agg root, transaction script, entity, values. А так да, взяли отовсюду понемногу.
Это фаулер описал, до DDD
S>>>Значит тут и репозиторий особо не нужен, обычный DAL. G>>Так это в любой программе так. S>Какой сервис в компании не беру, везде есть Repository. Это уже ~Dal по сути.
Мода — она такая, везде ропозитарии, хотя они не нужны.
S>>>Но опять же, никаких разумных сравнений произведено не было -- loc, сложность поддержки и т.п. Чисто умозрительные вывод. G>>Серьезно? Только что описал почему фактически не было никаких языков кроме ОО, которые имело смысл изучать. Это сейчас есть не(до)-ОО языки, такие как Go, Rust и Kotlin
S>Вкусовщина, типа нраится\ не нраится. Могли бы perl для веба взять. Никаких экспериментов по написанию веб приложения на пхп, а потом на C# не было же?
Книг по perl было на прядок меньше, на фоне C++\java\C# и остальных.
G>>Какой промпт? Напиши кодом то, что ты словами хочешь объяснить. G>>Всего-то надо по-ДДДному сделать проверку остатков. S>1) Каким боком это к дискуссии? S>2) Речь же шла про инвариант класса, а не ДДДшное исполнение чего-то. Инвариант класса и ДДД противоречат где-то?
Как обычно попытка решить нетривиальную задачу проектирования с помощью DDD приводит или к "это другое" или к CQRS и эвентсорсингу.
S>>>А бд не с объектами в памяти работает? G>>нет конечно, она с данными на диске работает. S>Она(бд) эти данные потом в память себе загоняет и работает с ними. Так что в памяти и работает.
Тем не менее "объектами" там не пахнет.
S>>>Ну если у нас данные лежат в бд, то естественно что их надо забрать оттуда. G>>нет конечно, проверка остатков делается без поднятия в память данных. S>Как?
Запросом на уровне базы, который писал выше. Из базы на уровень приложения ничего не попадает.
S>>>Кто-то считает, что 1 млн лок на пхп без ДДД это уже вилка. Ну вот можно от этой цифры отталкиваться. Хотя сколько людей, столько мнений. G>>Очередное мнение, которое подкреплено примерно ничем? S>Чем хуже вашего мнения?
Тем что я не пытаюсь доказать полезность и применимость DDD.
Бремя доказательство обычно возлагается на того кто утверждает, пока он не представил объективные аргументы.
S>>>Возможно. 101 раз повторю -- это вкусовщина. У разработчика из Я. по ссылке выше на этот счет может быть другое мнение. И это нормально. G>>Поэтому и не надо отсылать к мнению и чату ГПТ. Приведи просто пример, хоть свой, хоть из интернета, кода с DDD, который по твоему демонстрирует преимущества и я его перепишу без ДДД и сравним по любым формальным (не зависящим от мнения) характеристикам S>Ну ведь фигней занимаетесь, не будете переписывать огромный софт под 1млн. без ДДД. Ну к чему эта бравада? S>Какое-то детсадовское взятие на слабо. Не серьезно.
Как тогда доказать что-то про ДДД?
G>>Пока выглядит так, что ДДД хорош только потому что он кому-то нравится. G>>Меня интересует более научный подход, когда результат можно как-то измерить.
S>Я говорил, что он не плох, если кому-то не нравится. Ровно в этом моя позиция. Научный подход в ИТ вещь такая себе -- почему написали на C#, когда можно было на С++ или вообще на Си? Это бред и демагогия, не нравится, не пользуйтесь. Я вот избирательно что-то для себя в ДДД подчеркнул и мне
хорош, никакого научного подхода не надо.
Звучит как вера. Вам верить никто не мешает, но нести свою веру другим в целом противопоказано.
S>Блин, ну какой научный подход у agile, рефакторинга и solid?
Есть конечно, исследования всякие.
Насчет solid не знаю, про agile и рефакторинг находил.
Re[24]: Что если не разделять строго dto, entity, bo...
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, Sinclair, Вы писали:
G>>>Тем более есть проблема: кроме Clean Architecture и DDD в медийном поле вообще не существует других подходов. У альтернативы ДДД даже названия собственного нет, она состоит из применения принципов YAGNI, KISS, DRY, top-down подхода к проектированию и разработке, частично SOLID. S>>Эмм, частично антиподом является anemic model. Термин введён, афаир, как ругательство апологетами DDD, но вполне отражает как минимум часть подхода.
A>Anemic model антипод Rich model, и ничто не мешает ее использовать в DDD.
Точно?
Насколько я знаю основной паттернов DDD является aggregate root — сущность, которая поднимается из бд и все изменения вызываются из нее. То есть мы взываем Root.DoSmth(...), а рут в свою очередь вызывает методы дочерних объектов. Именно рут отвечает за целостность операции
За все затягивание и сохранение отвечает репозиторий (это второй по важности паттерн в DDD), а вызывающий код работает с объектами.
Все остальные паттерны, такие как команды, эвенты, domain services и value object призваны обходить ограничения такого дизайна.
A>У DDD проблема такая же как и у ООП, все про него рассказывают, но действительно понимают границы применения единицы.
ООП люди понимают и применяют, посмотри на любой UI фреймворк на ОО-языке — WPF или, прости господи, WinForms.
А еще можешь посмотреть базовые библиотеки дотнета или жабы, они тоже полны достаточно качественного ООП (со своими особенностями каждая).
Других хорошим применений ООП немного и попытка натянуть на ООП состояние приложения в основном ущербна. На эту тму у товарища Лиипперта есть потрясающая серия статей Wizards and Warriors, которую я даже перевел на хабре
A>Как раз поэтому бездумное следование принципам DDD можно противопоставить принципам YAGNI, KISS.
YAGNI и KISS — первичны, они даже DRY превосходят. Если ваше ООП не соответствует YAGNI, то у вас плохое ООП.
Здравствуйте, Sinclair, Вы писали:
A>>и ничто не мешает ее использовать в DDD S>Тут — спорно. По Фаулеру, она — антипаттерн. S>Рич модель является стандартом DDD; многие вообще считают, что без неё никакого DDD нет.
Мне наоборот казалось, что сейчас большинство склоняются к anemic.
S>Было бы неплохо показать какой-нибудь авторитетный источник, который бы объяснял, где проходят эти границы применимости. S>Как тут верно заметил коллега gangustas, за последние 16 лет не появилось ни одного убедительного примера, который бы показал преимущества DDD при полном его использовании (а не когда мы от него оставляем какой-то несущественный фрагмент).
Нет их, сам всех про такой спрашиваю Я как раз писал о частичной применимости.
Re[25]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
G>Насколько я знаю основной паттернов DDD является aggregate root — сущность, которая поднимается из бд и все изменения вызываются из нее. То есть мы взываем Root.DoSmth(...), а рут в свою очередь вызывает методы дочерних объектов. Именно рут отвечает за целостность операции G>За все затягивание и сохранение отвечает репозиторий (это второй по важности паттерн в DDD), а вызывающий код работает с объектами.
Это всё детали реализации. Что мешает реализовать aggregate root как сервис и dto?
G>ООП люди понимают и применяют, посмотри на любой UI фреймворк на ОО-языке — WPF или, прости господи, WinForms. G>А еще можешь посмотреть базовые библиотеки дотнета или жабы, они тоже полны достаточно качественного ООП (со своими особенностями каждая).
А если взять корпоративные приложения, для которых DDD в первую очередь и предназначен, много там качественного ООП именно в бизнес домене?
Re[34]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
S>>>>Значит тут и репозиторий особо не нужен, обычный DAL. G>>>Так это в любой программе так. S>>Какой сервис в компании не беру, везде есть Repository. Это уже ~Dal по сути. G>Мода — она такая, везде ропозитарии, хотя они не нужны.
Репозиторий как DAL конечно не нужен, здесь ORM нормально справляется. Если же репозиторий как сервис, работающий с внешними данными, и который является частью домена, то почему нет.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Блин, ну он же говорит, что работал в мамбе где было 1млн loc на пхп. И там, например, анкета могла быть в 50 разных контекстах. И если бы S>>не ДДД, то по его мнению, было бы очень и очень плохо. Т.е. окупается поддерживаемостью. S>Похоже, что он словом DDD называет что-то другое, чем Эванс с Фаулером.
Кстати, думается, что не только он, а, наверное, все, кто сталкивается с DDD.
S>Потому что вот эта вот "анкета в разных контекстах" — это либо просто anemic class, позволяющий строгую типизацию таблицы (и каждый потребитель в каждом контексте тащит из неё то, что нужно лично ему), либо про класс, реализующий 50 разных интерфейсов, т.к. в каждом контексте нужно что-то своё.
Я полагаю, что про какие-нибудь Bounded context и Ubiquitous language, типа анкета всплывает в куче разных
контекстов, и чтобы это не был один огромный объект с 50 интерфейсов, а какой-нибудь Agg. Root в BC.
S>>Не знаю. Но в целом может быть, т.к. абстракций там накручивают не мало. S>Дело не в абстракциях, а в архитектуре. В анемике у "объектов" нет никакого поведения, что позволяет описывать бизнес-логику в терминах трансформаций этих объектов. Пример gangustas уже приводил. S>И вот такое описание позволяет напрямую транслировать эту логику с языка, на котором пишет программист-прикладник, в язык нижележащей платформы (например, SQL) и исполнять его прямо там. S>А в DDD поведение описано на какой-нибудь императивной Java. Поэтому мы даже примитивный p.set_LastName() не можем превратить в update person p set p.LastName = — это же чорный ящик!
Так p.set_LastName() к ДДД никакого отношения не имеет, это уже какие-то детали реализации.
S>Вместо этого мы поднимем в память JVM весь этот Person c его сотней полей, потом вызовем Чорный ящик, а потом будем при коммите лихорадочно шерстить список изменений, чтобы сгенерировать update не по исходному коду, а по наблюдаемым побочным эффектам.
Ну да, он про производительность и говорил.
S>>Вы хотели с кем-то пообщаться за 16 лет, вот пожалуйста. Это в любом сообществе так. Идите в группу дотнет и начните рассказывать S>>про преимущества ручной сборки мусора. S>Это всё нерелевантно. Плоскоземельщиков тоже великие толпы. Идти к ним проповедовать — а зачем? Вопрос как раз в том, есть ли чему научиться полезному у плоскоземельщиков.
Ну а как узнать, если не пытаться заговорить, а ходить вокруг да около?
Здравствуйте, Sinclair, Вы писали:
S>>Вашему же я должен довериться, что ДДД не нужен. А его почему-то нет. S>Не, тут работает презумпция ненужности. Каждый раз, когда вам предлагают какую-нибудь новую практику — хоть уринотерапию, хоть методику или парадигму разработки — по умолчанию ответ "обойдёмся". S>Это задача предлагающего доказать, что с ним будет лучше. S>У DDD фундаментальная проблема — многие вопросы в нём неразрешимы совсем. Другие — создают трудности, которых нет в других подходах.
Какие, например?
Кодом людям нужно помогать!
Re[30]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sinclair, Вы писали:
S>>Детали реализации -- да, скрывает. Добавьте соотв. метод в соотв. интерфейс и всех делов. S>Не получится.
Почему, как репозиторий зависит от физического хранилища?
S>>Проверка инварианта делегируются бд, а класс получает результат этой проверки. В бд можно делать еще lock, если что. S>Нет, это так не работает. Из-за этого примерно все образцы DDD либо не работают вообще, либо чудовищно неэффективны.
А при чем здесь DDD? Здесь побочный разговор на тему проверки инвариантов в случае, когда данные хранятся в бд.
Я так понимал суть вопроса.
S>>>>Вычитать соотв. поля из бд, взяв соотв. лок предварительно, посчитать и в зависимости от, продолжить работу. S>Ну, то есть то, что СУБД обеспечивала из коробки, мы превращаем в закат солнца вручную.
Речь про транзакции? Я не знаю как обеспечивать инваринат класса (домена), если все данные хранятся в бд.
Кроме как неэффективно все лочить ничего придумать не могу, а если использовать бд для этого, то это уже
не инвариант класса получается.
Кодом людям нужно помогать!
Re[34]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
S>>Да, вполне согласен. Не исключаю, что все эти моменты под одну крышуметодологию запихнули и все. Как-то так оно и есть. S>>Потом решили развивать идею дальше, и появились тактические паттерны и тп. G>См историю, тактические паттерны появились в начале. Все описал фаулер еще до эванса. Вся суть ДДД с самого начала — натягивание философии на паттерны. Когда модным стал CQRS — он появился в книгах DDD. Когда стали модными микросервисы — они тоже появились в книгах по DDD.
Может быть, но ДДД очень любят применять при распилах монолита на микросервисы. Работал в таком проекте.
S>>Ну тактические все-таки что-то новое, все эти agg root, transaction script, entity, values. А так да, взяли отовсюду понемногу. G>Это фаулер описал, до DDD
Ну а Эванс добавил стратегические паттерны и превратил все это методологию. Что называется стоял на
плечах гигантов.
S>>Какой сервис в компании не беру, везде есть Repository. Это уже ~Dal по сути. G>Мода — она такая, везде ропозитарии, хотя они не нужны.
Соглашусь. Ну, кстати, и ООП тоже своего рода мода.
S>>Вкусовщина, типа нраится\ не нраится. Могли бы perl для веба взять. Никаких экспериментов по написанию веб приложения на пхп, а потом на C# не было же? G>Книг по perl было на прядок меньше, на фоне C++\java\C# и остальных.
Странно, учитывая что он на 20 лет появился раньше. А на питон почему не смотрели, вроде для него уже
были фреймоврки для веба?
S>>1) Каким боком это к дискуссии? S>>2) Речь же шла про инвариант класса, а не ДДДшное исполнение чего-то. Инвариант класса и ДДД противоречат где-то? G>Как обычно попытка решить нетривиальную задачу проектирования с помощью DDD приводит или к "это другое" или к CQRS и эвентсорсингу.
При чем здеьс обеспечение инварианта и ДДД?
S>>Она(бд) эти данные потом в память себе загоняет и работает с ними. Так что в памяти и работает. G>Тем не менее "объектами" там не пахнет.
Объектами самой бд, типа строки\колонки\талбицы и т.п.
S>>Как? G>Запросом на уровне базы, который писал выше. Из базы на уровень приложения ничего не попадает.
А ответ от базы где и кем анализируется, для чего запрос-то делать, если ответ никуда не попадет, точнее
не попадет в приложение?
G>>>Очередное мнение, которое подкреплено примерно ничем? S>>Чем хуже вашего мнения? G>Тем что я не пытаюсь доказать полезность и применимость DDD.
Я пытаюсь настоять на его полезности хотя бы в рамках распила монолита на микросервисы. Как-то
работает. Все. Про общую пользу я речь не вёл.
G>Бремя доказательство обычно возлагается на того кто утверждает, пока он не представил объективные аргументы.
У меня их нету, выбор языка ОПП C# вы тоже особо не доказывали, а просто вкусовщина или книжек мало.
S>>ДДД утв. что если вы правильно поняли бизнес и модель предметной области, то все должно взлететь. Делайте так и все получится. G>Если есть контрпример, то можно считать утверждение ложным?
Давайте разберем контрпример. Хотя думаю, что мое утверждение выше было чрезмерно сильным.
Возможно ДДД ничего такого не утверждает.
S>>Ну ведь фигней занимаетесь, не будете переписывать огромный софт под 1млн. без ДДД. Ну к чему эта бравада? S>>Какое-то детсадовское взятие на слабо. Не серьезно. G>Как тогда доказать что-то про ДДД?
Не знаю, методом проб и ошибок.
S>>Я говорил, что он не плох, если кому-то не нравится. Ровно в этом моя позиция. Научный подход в ИТ вещь такая себе -- почему написали на C#, когда можно было на С++ или вообще на Си? Это бред и демагогия, не нравится, не пользуйтесь. Я вот избирательно что-то для себя в ДДД подчеркнул и мне G>хорош, никакого научного подхода не надо. G>Звучит как вера. Вам верить никто не мешает, но нести свою веру другим в целом противопоказано.
Блин, ну как тогда любая технология взлетает, если в нее по сути по началу верять пару человек,
если вообще не один? При таком подходе никакого ООП бы не было.
S>>Блин, ну какой научный подход у agile, рефакторинга и solid? G>Есть конечно, исследования всякие. G>Насчет solid не знаю, про agile и рефакторинг находил.
Ну вот про научно доказанную пользу agile я бы почитал.
Кодом людям нужно помогать!
Re[26]: Что если не разделять строго dto, entity, bo...
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Насколько я знаю основной паттернов DDD является aggregate root — сущность, которая поднимается из бд и все изменения вызываются из нее. То есть мы взываем Root.DoSmth(...), а рут в свою очередь вызывает методы дочерних объектов. Именно рут отвечает за целостность операции G>>За все затягивание и сохранение отвечает репозиторий (это второй по важности паттерн в DDD), а вызывающий код работает с объектами.
A>Это всё детали реализации. Что мешает реализовать aggregate root как сервис и dto?
А есть пример такой архитектуры. Я правда не понимаю как это должно выглядеть.
G>>ООП люди понимают и применяют, посмотри на любой UI фреймворк на ОО-языке — WPF или, прости господи, WinForms. G>>А еще можешь посмотреть базовые библиотеки дотнета или жабы, они тоже полны достаточно качественного ООП (со своими особенностями каждая). A>А если взять корпоративные приложения, для которых DDD в первую очередь и предназначен, много там качественного ООП именно в бизнес домене?
Примерно ничего. ООП плох для моделирования связей и ограничений в предметной области.
Re[35]: Что если не разделять строго dto, entity, bo...
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
S>>>>>Значит тут и репозиторий особо не нужен, обычный DAL. G>>>>Так это в любой программе так. S>>>Какой сервис в компании не беру, везде есть Repository. Это уже ~Dal по сути. G>>Мода — она такая, везде ропозитарии, хотя они не нужны.
A>Репозиторий как DAL конечно не нужен, здесь ORM нормально справляется. Если же репозиторий как сервис, работающий с внешними данными, и который является частью домена, то почему нет.
Почему для внешних данных нужен репозиторий? Зачастую внешний сервис, это именно сервис. Ты ему запросы, он тебе ответы. Все. Никакого ооп не надо. И заботиться о целостности внешних данных не надо. На то они и внешние.
Я как раз писал о частичной применимости.
