Здравствуйте, 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>>>https://ru.wikipedia.org/wiki/%D0%AD%D0%BC%D0%B5%D1%80%D0%B4%D0%B6%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C
G>>А почему такое же свойство не может проявиться у достаточно большой системы без DDD? В чем особенность именно DDD?

S>ДДД утв. что если вы правильно поняли бизнес и модель предметной области, то все должно взлететь. Делайте так и все получится.
Если есть контрпример, то можно считать утверждение ложным?



S>>>Возможно. 101 раз повторю -- это вкусовщина. У разработчика из Я. по ссылке выше на этот счет может быть другое мнение. И это нормально.
G>>Поэтому и не надо отсылать к мнению и чату ГПТ. Приведи просто пример, хоть свой, хоть из интернета, кода с DDD, который по твоему демонстрирует преимущества и я его перепишу без ДДД и сравним по любым формальным (не зависящим от мнения) характеристикам
S>Ну ведь фигней занимаетесь, не будете переписывать огромный софт под 1млн. без ДДД. Ну к чему эта бравада?
S>Какое-то детсадовское взятие на слабо. Не серьезно.
Как тогда доказать что-то про ДДД?

G>>Пока выглядит так, что ДДД хорош только потому что он кому-то нравится.
G>>Меня интересует более научный подход, когда результат можно как-то измерить.

S>Я говорил, что он не плох, если кому-то не нравится. Ровно в этом моя позиция. Научный подход в ИТ вещь такая себе -- почему написали на C#, когда можно было на С++ или вообще на Си? Это бред и демагогия, не нравится, не пользуйтесь. Я вот избирательно что-то для себя в ДДД подчеркнул и мне
хорош, никакого научного подхода не надо.
Звучит как вера. Вам верить никто не мешает, но нести свою веру другим в целом противопоказано.

S>Блин, ну какой научный подход у agile, рефакторинга и solid?
Есть конечно, исследования всякие.
Насчет solid не знаю, про agile и рефакторинг находил.