Здравствуйте, gandjustas, Вы писали:
S>>Для разработчика из видео выше это будет не так -- у него ДДД имеет доказанную пользу. Короче, это субъективщина.
G>Мне кажется ты не понимаешь суть слова "доказанную"...
Доказанную в кавычках, согласен. Типа работает. Применил ДДД -- получилось.
S>>Это можно решить в самый последний момент, согласно ДДД. Это детали.
G>Так вот мы пришли к этому моменту. Это одна таблица или нет?
Ну какая разница-то для данного обсуждения?
G>Какой? Почему в этом примере именно Employee? Что этот пример должен был нам сказать?
G>Может нам наоборот стоит нарезать задачу контексты по другому? напрмиер на расчет зряплаты, грейдирование, итд. В каждом будут свои "root", а Employee как раз получится один для всех, так как он по сути просто справочник, который точно хранится в одной таблице.
G>Я тут не фантазирую, конфигурация 1С ЗУП так устроена. В 1С кстати заложена архитектура Event Sourcing и оптимизации темпоральных запросов (даже проверка остатков прекрасно решается), но в ней нет Domain Model (вернее эта модель полностью соответствует таблицам в БД) и Bounded Context (одна баз — один bounded context).
Ничего не могу сказать по поводу 1С ЗУП, сделали как считали правильным.
S>>На мой взгляд, скорее это методология, а не набор готовых рецептов. По-отдельности применять можно, но сложно. Точнее уже разбили на стратегически и тактические паттерны.
G>Пробелма в том, что без "тактических паттернов" методология DDD настолько очевидна, что смысла нет в отдельном названии.
G>Она сводится к трем вещам:
G>1) Универсальный язык для общения с заказчиком. По сути это раздел "термины и определения" из ТЗ по любому стандарту
G>2) Разделение проблемы на области — то что везде называние "модулями" (термин из структурного программирования) или "подсистемами" (термин из системной инженерии). В книге вернона и последующих даже упоминается иерархния (вложенность) областей, также как модули и подсистемы могут иметь вложенность.
G>3) Ограниченные контексты — единицы разработки и\или единицы деплоя.
G>Еще недавно появился EventStorming — по сути обычные брейнштормы, если отвязать их от event sourcing.
Да, вполне согласен. Не исключаю, что все эти моменты под одну
крышуметодологию запихнули и все. Как-то так оно и есть.
Потом решили развивать идею дальше, и появились тактические паттерны и тп.
G>Фактически ничего нового DDD не дает. Мы все это видели например в UML — диграммы компонентов это предметные области, а диаграммы развертывания, диаграммы юзкейсов, процессов и логической структуры.
Ну тактические все-таки что-то новое, все эти agg root, transaction script, entity, values. А так да, взяли отовсюду понемногу.
S>>Значит тут и репозиторий особо не нужен, обычный DAL.
G>Так это в любой программе так.
Какой сервис в компании не беру, везде есть Repository. Это уже ~Dal по сути.
S>>Но опять же, никаких разумных сравнений произведено не было -- loc, сложность поддержки и т.п. Чисто умозрительные вывод.
G>Серьезно? Только что описал почему фактически не было никаких языков кроме ОО, которые имело смысл изучать. Это сейчас есть не(до)-ОО языки, такие как Go, Rust и Kotlin
Вкусовщина, типа нраится\ не нраится. Могли бы perl для веба взять. Никаких экспериментов по написанию веб приложения на пхп, а потом на C# не было
же?
S>>Вот для кого-то и ДДД выглядит интересно.
G>Кстати регулярно в чатике дотнета вижу как приходит новичок, который хочет DDD изучать и его всем чатом начинают отговаривать.
102 заявляю, что я не апологет ДДД. Но вещь интересная и откидывать ее с порога не стоит, там говорят дельный, но возможно,
кому-то очевидные вещи. Но да, новичку изучать ДДД такое себе. Я как бы сам толком его не изучал -- посмотрел некоторое кол-во видео,
почитал хабр и проч. статьи и все. Никаких классиков не читал и не планирую.
G>Какой промпт? Напиши кодом то, что ты словами хочешь объяснить.
G>Всего-то надо по-ДДДному сделать проверку остатков.
1) Каким боком это к дискуссии?
2) Речь же шла про инвариант класса, а не ДДДшное исполнение чего-то. Инвариант класса и ДДД противоречат где-то?
S>>А бд не с объектами в памяти работает?
G>нет конечно, она с данными на диске работает.
Она(бд) эти данные потом в память себе загоняет и работает с ними. Так что в памяти и работает.
S>>Ну если у нас данные лежат в бд, то естественно что их надо забрать оттуда.
G>нет конечно, проверка остатков делается без поднятия в память данных.
Как?
S>>Кто-то считает, что 1 млн лок на пхп без ДДД это уже вилка. Ну вот можно от этой цифры отталкиваться. Хотя сколько людей, столько мнений.
G>Очередное мнение, которое подкреплено примерно ничем?
Чем хуже вашего мнения?
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>>Возможно. 101 раз повторю -- это вкусовщина. У разработчика из Я. по ссылке выше на этот счет может быть другое мнение. И это нормально.
G>Поэтому и не надо отсылать к мнению и чату ГПТ. Приведи просто пример, хоть свой, хоть из интернета, кода с DDD, который по твоему демонстрирует преимущества и я его перепишу без ДДД и сравним по любым формальным (не зависящим от мнения) характеристикам
Ну ведь фигней занимаетесь, не будете переписывать огромный софт под 1млн. без ДДД. Ну к чему эта бравада?
Какое-то детсадовское взятие на слабо. Не серьезно.
G>Пока выглядит так, что ДДД хорош только потому что он кому-то нравится.
G>Меня интересует более научный подход, когда результат можно как-то измерить.
Я говорил, что он не плох, если кому-то не нравится. Ровно в этом моя позиция. Научный подход в ИТ вещь такая себе -- почему написали на C#, когда
можно было на С++ или вообще на Си? Это бред и демагогия, не нравится, не пользуйтесь. Я вот избирательно что-то для себя в ДДД подчеркнул и мне
хорош, никакого научного подхода не надо.
Блин, ну какой научный подход у agile, рефакторинга и solid?
