Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, gandjustas, Вы писали:
P>>>То есть, чаще всего вот эти "лишние" строки становятся такими только со временем. Это если отказаться от варианта "все дураки" G>>Тогда в чем проблема удалить код, который вообще не используется? Это же требует примерно 0 усилий.
P>Как вы это представляете, каждая строка сама напишет в Slack "репозиторий-путь-файл-номер, можно удалять?" P>Мертвый код сначаоа нужно идентифицировать. Чаще всего он просто выглядт, как живой код.
Давайте считать что мертвый код уже был идентифицирован, ибо если нет, то о чем разговор?
G>>Проблема удаления кода возникает когда он используется, на него много зазвано. P>Необязательно. Куда чаще мертвый код просто выглядит как живой и работающий, хотя нигде не вызывается или же его вызовы заканчиваются сразу на старте if (disabled) return;
Обычно мертвый код выглядит как классы которые нигде не создаются, находятся тремя-четырьмя кликами в студии.
Мы же говорим о тысячах строк такого кода, вряд ли это будет в таких ифах.
G>>То есть сначала делаем "главное чтобы заработало", потом устраняем ошибки в corner cases, очевидные code smells, вписываем в сущствующую архитектуру, делаем оптимальным. P>Это всё крайне растяжимое. У каждого своё видение, насколько глубоко это всё надо делать.
Рамки задачи всегда можно сохранить. Просто задавай себе вопрос: "как это влияет на ту задачу, которую мне сейчас необходимо решить?". Если никак, то не надо этого делать.
Кроме того, я изначально писал что нужно заниматься проектированием и программированием "сверху вниз", тогда контролировать скоуп несложно.
G>>Главное фокусироваться на одной задаче, а не заниматься проектированием системы. То есть не трогать ничего, что напрямую не касается данной задачи. P>Это общие слова.
Вполне конкретные.
P>Одна единственная задача это только краткосрочная перспектива.
Это именно краткосрочная.
P>Пример — думали хватит чисто эндпоинта таскать из ui в базу и обратно, а после первого релиза вылезло такое...
Ну так после первого релиза и поправьте. Никто ведь заранее не знал, что вылезет после релиза, а если бы пытались угадать, то вероятнее всего не угадали бы.
P>>>Например, реанимировать проект краткосрочными интервенциями "главное сделать" не получится. Скорее всего, он именно и зашел в тупик благодаря "главное сделать". G>>Как раз наоборот, в тупик заходят проекты, "проектируют наперед". Потому что если ты каждый раз делаешь минимум кода для решения задачи, то по какой причине у тебя появится тонна ненужного, но используемого кода?
P>Я вам уже привел пример Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования.
Практика показывает что занимаясь проектированием "только здесь и сейчас" почти всегда получается компактный код, который легко поддерживать. Как только пытаешься проектировать "наперед" появляется херня которая потом тянет назад, или просто зря тратишь время.
Особенно плохо если "каркас" приложения пишет "архитектор", а рядовые разрабы пытаются впихнуть в эти рамки свою логику, не имея возможности поменять неудобные места.
Re[14]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
S>>Без понимания и выработки соотв. абстракций решать проблемы будет крайне затруднительно. G>Честно не понимаю о чем речь. Давайте возьмём например разработку форума. Какие абстракции для этого нужно создать? Того что предлагает .NET FW недостаточно?
Ну, например, абстракция "Запись" или "Пользователь". Когда какой-то пользователь создает где-то "Запись". У абстракции "Запись"
может быть ряд своих атрибутов тип содержимого, когда создан, можно ли редактировать, показывать данную запись всем или только
зарегистрированным пользователем. У "Пользователя" есть свои атрибуты. Форум -- это группа записей объединенных по какому-либо
критерию, скажем подфорум. Ну в общем, продолжая в том же духе можно еще прикинуть какие-нибудь важные доменные объекты или
абстракции. Что такого предлагает .NET FW кроме инструментов для работы с абстракциями(доменными сущностями)?
S>>Это факт. Это, кмк, нужно для больших, типа банковских и т.п., сервисов и приложений. Но по отдельности и некоторые компоненты DDD можно S>>использовать -- ubitiquos language, bounded context и т.п. Но тут тогда уж проще следовать методологии целиком, а не по кускам выдергивать. S>>Мож не взлетает именно из-за кусочничества . G>Тем не менее не видел примеров где БОЛЬШЕ ДДД делает код лучше, чем когда МЕНЬШЕ ДДД. G>Может это какие-то слишком простые примеры были, но где взять сложные, чтобы можно было сравнивать подходы?
Ну вот я работал в компании, где монолит распили на микросервисы по ДДД. Вроде работало. Но опять же, от ДДД там только
разбивка на микросервисы с помощью Bounded Context + Ubiquitous Language. Короче, в основном стратегические паттерны.
Кодом людям нужно помогать!
Re[16]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
G>Вы сейчас пытаетесь сказать, что не бывает хорошего структурированного кода без "модели предметной области"? Я еще раз повторю что это неправда, предлагаю перестать об этом говорить.
А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями?
По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде.
G>Могу показать примеры хорошего структурированного кода, где нет ничего, что можно было было назвать "моделью предметной области". Опять-таки можно сказать что это простые примеры, но я не видел сложных примеров с ДДД, где везде хороший структурированный код.
Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области".
Кодом людям нужно помогать!
Re[15]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Без понимания и выработки соотв. абстракций решать проблемы будет крайне затруднительно. G>>Честно не понимаю о чем речь. Давайте возьмём например разработку форума. Какие абстракции для этого нужно создать? Того что предлагает .NET FW недостаточно?
S>Ну, например, абстракция "Запись" или "Пользователь". Когда какой-то пользователь создает где-то "Запись". У абстракции "Запись" S>может быть ряд своих атрибутов тип содержимого, когда создан, можно ли редактировать, показывать данную запись всем или только S>зарегистрированным пользователем. У "Пользователя" есть свои атрибуты. Форум -- это группа записей объединенных по какому-либо S>критерию, скажем подфорум. Ну в общем, продолжая в том же духе можно еще прикинуть какие-нибудь важные доменные объекты или S>абстракции.
Из этой речи я понял, что "абстракции" это описания типов хранимых данных, чтобы делать запросы и получать данные типизировано?
Если так, то слово "абстракция" тут неуместно.
S>Что такого предлагает .NET FW кроме инструментов для работы с абстракциями(доменными сущностями)?
Например ASP.NET Core Identity. Он как раз представляет из себя абстракцию (определяет операции, позволяющие потребителю не зависеть от их реализации) для работы с пользователями в любой системе.
Вы можете по образу и подобию сделать свою абстракцию для работы с темами и сообщениями в форуме. Но она имеет смысл только тогда, кода к этой абстракции будет обращаться кто-то еще.
Для решения конкретной задачи — создания форума — нужны такие абстракции как "обработчик веб-запроса" (контроллеры), доступ к данным Entity Framework Core, фоновые задачи — backgroundservice, инструменты для работы с конфигурацией — Configuration и Options/
Вы на них собираете нужную вам функциональность.
Какие абстракции еще нужны? Или все "абстракции" сводятся к описаниям типов хранимых и передаваемых данных?
Re[17]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Вы сейчас пытаетесь сказать, что не бывает хорошего структурированного кода без "модели предметной области"? Я еще раз повторю что это неправда, предлагаю перестать об этом говорить.
S>А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями?
1) Уменьшает дублирование кода
2) Уменьшает количество связей и сайд-эффектов
3) Уменьшает цепочку вызовов и количество промежуточных слоев между вызовов и действием
4) Увеличивает быстродействие
5) Уменьшает неявную передачу данных и изменение стояния
Это все вещи связанные, но в некоторых местах могут противоречить друг другу, поэтому хороший код это баланс.
S>По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде.
Вы как-то слишком широко применяете слово "абстракция". Когда вы создаете класс с набором свойств это не абстракция. Реализация интерфейса это тоже не абстракция. Абстракция это то, что использует такие классы или интерфейсы. А писать такой код нет необходимости. Большинство полезных абстракций уже есть в библиотеках, зачастую стандартных.
G>>Могу показать примеры хорошего структурированного кода, где нет ничего, что можно было было назвать "моделью предметной области". Опять-таки можно сказать что это простые примеры, но я не видел сложных примеров с ДДД, где везде хороший структурированный код. S>Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области".
Начнем с простого, позже смогу вырезать кусок из реального проекта.
Недавно делал пример для статьи на Хабре https://github.com/gandjustas/habr-post-stock-api, АПИшка для резервации заказов, работает с базой, содержит очень важную для бизнеса логику. Это как маленький кусок большого приложения
Там даже есть абстракция — очередь запросов (она не шибко полезная в целом)
Что там является "моделью предметной области", в чем её ценность, и как она влияет на остальные части кода?
Re: Что если не разделять строго dto, entity, bo...
Здравствуйте, Shmj, Вы писали:
S>По этому как бы, получается, есть вера что нужно разделять — но нет реального смысла.
Смысл появляется с ростом проекта и с изменениями в проекте. На этапе прототипа и всяких MVP можно не разделять. Основное — выкатить что хоть как то работающее как можно быстрее. А вот далее пойдет развитие, доработки и т.д. И тут рано или поздно появится именно необходимость уже все разделять. Но в теории может и не понадобиться, если по быстрому написали и далее изменений не требуется почти. Но далее наверняка будут миграции всякие, смены базы данных, смена библиотек, возможно даже смена языка программирования, плюс все будет переписываться частями, потребуются хитрые интеграции со сторонними сервисами, зачастую еще разных версий — вот тут уже будут и разные DTO и чего только не будет. И это все будет очень оправдано, так как это тупо сэкономит до хрена времени на разработку и поиск и исправление багов. А пока проект детский, большой необходимости в разделении на Entity, DTO и бизнес объекты по большому счету нет. При развитии это все можно достаточно быстро все выносить, сложности то в преобразовании никакой. Но ключевое — хоть и сами объекты могут и выполнять на начальном этапе разные роли, крайне важно даже на этапе прототипа MVP не смешивать логику ввода-вывода, UI и бизнес логику. Иначе проблемы будут даже на детских проектах и будет баг на баге.
Re[18]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
S>>А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями? G>1) Уменьшает дублирование кода G>2) Уменьшает количество связей и сайд-эффектов G>3) Уменьшает цепочку вызовов и количество промежуточных слоев между вызовов и действием G>4) Увеличивает быстродействие G>5) Уменьшает неявную передачу данных и изменение стояния G>Это все вещи связанные, но в некоторых местах могут противоречить друг другу, поэтому хороший код это баланс.
Ну т.е. код ради кода, понятно. Ну вот есть хороший код, который плохо решает поставленную задачу, поскольку автор
толком не разобрался в предметной области. Ну и какой прок от этой программы кроме эстетики кода?
Ну и самый главный вопрос, а как всему вышеперечисленному мешает оперирование объектами доменной модели?
S>>По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде. G>Вы как-то слишком широко применяете слово "абстракция". Когда вы создаете класс с набором свойств это не абстракция. Реализация интерфейса это тоже не абстракция. Абстракция это то, что использует такие классы или интерфейсы. А писать такой код нет необходимости. Большинство полезных абстракций уже есть в библиотеках, зачастую стандартных.
Делаю какой-нибудь реалистичны автотренажер или игру для машин, есть в стандартной библиотеке класс автомобиль, мотор и т.п.?
G>>>Могу показать примеры хорошего структурированного кода, где нет ничего, что можно было было назвать "моделью предметной области". Опять-таки можно сказать что это простые примеры, но я не видел сложных примеров с ДДД, где везде хороший структурированный код. S>>Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области". G>Начнем с простого, позже смогу вырезать кусок из реального проекта. G>Недавно делал пример для статьи на Хабре https://github.com/gandjustas/habr-post-stock-api, АПИшка для резервации заказов, работает с базой, содержит очень важную для бизнеса логику. Это как маленький кусок большого приложения
Ну мы ведем речь про явно более крупные приложения, а не про crud на 3 операции.
G>Там даже есть абстракция — очередь запросов (она не шибко полезная в целом)
Зачем, лукавое это? А что стандартная библиотека, кстати, не помогла?
G>Что там является "моделью предметной области", в чем её ценность, и как она влияет на остальные части кода?
Здравствуйте, gandjustas, Вы писали:
P>>Мертвый код сначаоа нужно идентифицировать. Чаще всего он просто выглядт, как живой код. G>Давайте считать что мертвый код уже был идентифицирован, ибо если нет, то о чем разговор?
Ага, давайте считать, что проблемы нет, а строчки сами будут говорить надо ли их удалять.
G>Обычно мертвый код выглядит как классы которые нигде не создаются, находятся тремя-четырьмя кликами в студии.
Необязательно. Чаще всего они могут создаться, вызываться итд по недостижимым путям. У вас нет абсолютно точного синтаксического анализатора, который выдаст всё на блюдечке — проблема останова мешает.
P>>Это всё крайне растяжимое. У каждого своё видение, насколько глубоко это всё надо делать. G>Рамки задачи всегда можно сохранить. Просто задавай себе вопрос: "как это влияет на ту задачу, которую мне сейчас необходимо решить?". Если никак, то не надо этого делать.
Вы в слова играете. У каждого своё видение, что именно относится к задаче. Например, один меняет метод, и все точки вызова проверит и поправит. А другой решит,что такая чистка к его задаче не относится, и даже тикет не создаст.
G>Кроме того, я изначально писал что нужно заниматься проектированием и программированием "сверху вниз", тогда контролировать скоуп несложно.
Это общие слова.
P>>Одна единственная задача это только краткосрочная перспектива. G>Это именно краткосрочная.
О чем я вам говорю, и это — проблема, т.к. все среднесрочные и долгосрочные цели вне фокуса.
P>>Пример — думали хватит чисто эндпоинта таскать из ui в базу и обратно, а после первого релиза вылезло такое... G>Ну так после первого релиза и поправьте. Никто ведь заранее не знал, что вылезет после релиза, а если бы пытались угадать, то вероятнее всего не угадали бы.
В этом и есть проектирование — выяснить, какие у вас цели, абы сделать, или глянуть чуть дальше, те самые среднесрочные-долгосрочные цели.
P>>Я вам уже привел пример Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования. G>Практика показывает что занимаясь проектированием "только здесь и сейчас" почти всегда получается компактный код, который легко поддерживать.
Вам что бы обратную совместимость заложить в какое апи уже надо отойти от здесь и сейчас, а рассмотреть а что же вообще может или не может появиться.
Или вы предлагаете сначала сломать, а потом, если у когото утекут миллионы, завести тикет и начать фиксить?
Re[18]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Что там является "моделью предметной области", в чем её ценность, и как она влияет на остальные части кода? S>Ну как минимум https://github.com/gandjustas/habr-post-stock-api/blob/main/Model.cs
То есть "модель предметной области" это типизированное описание схемы БД, так?
Апологеты DDD как раз с этим спорят.
S>>>А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями? G>>1) Уменьшает дублирование кода G>>2) Уменьшает количество связей и сайд-эффектов G>>3) Уменьшает цепочку вызовов и количество промежуточных слоев между вызовов и действием G>>4) Увеличивает быстродействие G>>5) Уменьшает неявную передачу данных и изменение стояния G>>Это все вещи связанные, но в некоторых местах могут противоречить друг другу, поэтому хороший код это баланс.
S>Ну т.е. код ради кода, понятно. Ну вот есть хороший код, который плохо решает поставленную задачу, поскольку автор толком не разобрался в предметной области. Ну и какой прок от этой программы кроме эстетики кода?
А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи?
И кто сказал что наличие "объектов доменной модели" автоматически приводит к хорошему решению задачи?
S>Ну и самый главный вопрос, а как всему вышеперечисленному мешает оперирование объектами доменной модели?
Никак не мешает и никак не помогает. Хотя зависит от того, что входит в понятие "оперирование объектами доменной модели", так как это может давать ограничения
Например код вида
Является "оперированием объектами доменной модели"?
S>>>По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде. G>>Вы как-то слишком широко применяете слово "абстракция". Когда вы создаете класс с набором свойств это не абстракция. Реализация интерфейса это тоже не абстракция. Абстракция это то, что использует такие классы или интерфейсы. А писать такой код нет необходимости. Большинство полезных абстракций уже есть в библиотеках, зачастую стандартных.
S>Делаю какой-нибудь реалистичны автотренажер или игру для машин, есть в стандартной библиотеке класс автомобиль, мотор и т.п.?
Мы тут вроде как корпоративные приложения рассматриваем, которые оперируют данными в бд в многпользовательском режиме.
Думаю если бы мы рассматривали однопользовательскую 3д игру (видимо под ней понимается автотренажер), то там были бы объекты движка, которые представляют из себя "объекты на сцене", с "геомертрией", "текстурами" итд
Нужно ли из них делать классы вроде "автомобиль", "мотор" — я не уверен.
G>>>>Могу показать примеры хорошего структурированного кода, где нет ничего, что можно было было назвать "моделью предметной области". Опять-таки можно сказать что это простые примеры, но я не видел сложных примеров с ДДД, где везде хороший структурированный код. S>>>Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области". G>>Начнем с простого, позже смогу вырезать кусок из реального проекта. G>>Недавно делал пример для статьи на Хабре https://github.com/gandjustas/habr-post-stock-api, АПИшка для резервации заказов, работает с базой, содержит очень важную для бизнеса логику. Это как маленький кусок большого приложения
S>Ну мы ведем речь про явно более крупные приложения, а не про crud на 3 операции.
Вспоминаем закон Галла
Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде
Вот простая система есть, мы начнем дополнять функциями, а модель БД — сущностями\таблицами
Если функции пухнут — делаем Extract Method.
Если несколько методов имеют один и тот же набор параметров, то делаем класс с этими параметрами в конструкторе и переносим вызовы внутрь него.
Сколько нам нужно функций, чтобы DDD с его паттернами стало давать какой-то профит?
G>>Там даже есть абстракция — очередь запросов (она не шибко полезная в целом) S>Зачем, лукавое это?
Да, в посте написано, что так делать не надо в подавляющем большинстве случаев.
S>А что стандартная библиотека, кстати, не помогла?
Помогла
Здравствуйте, Pauel, Вы писали:
G>>Обычно мертвый код выглядит как классы которые нигде не создаются, находятся тремя-четырьмя кликами в студии.
P>Необязательно. Чаще всего они могут создаться, вызываться итд по недостижимым путям. У вас нет абсолютно точного синтаксического анализатора, который выдаст всё на блюдечке — проблема останова мешает.
Если у вас код запускается недостижимыми путями (что бы это не значило), то проблемы в архитектуре гораздо серьезнее, чем лишний код.
P>>>Это всё крайне растяжимое. У каждого своё видение, насколько глубоко это всё надо делать. G>>Рамки задачи всегда можно сохранить. Просто задавай себе вопрос: "как это влияет на ту задачу, которую мне сейчас необходимо решить?". Если никак, то не надо этого делать. P>Вы в слова играете. У каждого своё видение, что именно относится к задаче.
В итоге все сойдутся на мнении лида и оно станет одно.
G>>Кроме того, я изначально писал что нужно заниматься проектированием и программированием "сверху вниз", тогда контролировать скоуп несложно. P>Это общие слова.
Это волне конкретный порядок действий, я не буду сюда очередной раз копипастить контент статьи.
P>>>Одна единственная задача это только краткосрочная перспектива. G>>Это именно краткосрочная. P>О чем я вам говорю, и это — проблема, т.к. все среднесрочные и долгосрочные цели вне фокуса.
И это хорошо. Требования часто меняются, будущее угадывать невозможно. Нет смысла ориентироваться на "долгосрочные" цели разрабатывая каждый блок функционала.
P>>>Пример — думали хватит чисто эндпоинта таскать из ui в базу и обратно, а после первого релиза вылезло такое... G>>Ну так после первого релиза и поправьте. Никто ведь заранее не знал, что вылезет после релиза, а если бы пытались угадать, то вероятнее всего не угадали бы. P>В этом и есть проектирование — выяснить, какие у вас цели, абы сделать, или глянуть чуть дальше, те самые среднесрочные-долгосрочные цели.
У меня есть эпичный пример на этот счет.
Был такой один проектировщик. Он даже ен ИТшник был, а фин менеджер. Проектировал процесс согласования. Говорил что должно быть строго три согласующих, потому что так уже 7 лет в компании было. И буквально на следующий день, как выпустили процесс, согласующих стало 2.
Как бы красиво не называли, это все попытка угадать будущее. И чаще всего люди не угадывают. Поэтому единственный универсальный способ — написать сегодня настолько мало, чтобы завтра было не жалко выкинуть.
Как только вы начинаете проектировать наперед, то создаете кучу ограничений и потом сложнее отказаться от написанного, ибо работает когнитивная ошибка невозвратных затрат, да и просто обосновать зачем столько делали становится сложнее.
P>>>Я вам уже привел пример Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования. G>>Практика показывает что занимаясь проектированием "только здесь и сейчас" почти всегда получается компактный код, который легко поддерживать.
P>Вам что бы обратную совместимость заложить в какое апи уже надо отойти от здесь и сейчас, а рассмотреть а что же вообще может или не может появиться.
Зачем нужна обратная совместимость?
1) если добавляется необязательное поле, то старый код продолжает работать
2) если поле обязательное, то старый код в любом случае сломается
3) если происходят более значимые изменения, то просто создается новый метод (возможно с номером версии в сегменте пути, querystring или заголовке)
P>Или вы предлагаете сначала сломать, а потом, если у когото утекут миллионы, завести тикет и начать фиксить?
Если задача создать новый метод не поломав старый, то она решается целиком. А не так, что сначала создается новый, а потом чинится старый. Некоторые изменения в системах должны быть атомарны — это и будет одна задача для одного программиста.
Re[19]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
P>>Необязательно. Чаще всего они могут создаться, вызываться итд по недостижимым путям. У вас нет абсолютно точного синтаксического анализатора, который выдаст всё на блюдечке — проблема останова мешает. G>Если у вас код запускается недостижимыми путями (что бы это не значило), то проблемы в архитектуре гораздо серьезнее, чем лишний код.
Вы слишком вольно фантазируете — счего вы взяли, что я пишу про свой код? Вот подробнее, пожалуйста. Как я вижу, крайне редко кто из разработчиков тщательно выкашивает мертвый код. Слишком сильно суеверие "работает — не трогай".
Например, код может инстанцироваться, а вызовы отключены ключом в конфиге, или эндпоинт-апи-функция-класс итд больше недоступны, или вызываются только из тестов и других таких же мертвых концептов. Никакой анализатор вам этого не покажет, например, в силу недостаточной ссылочной прозрачности в мейнстримных языках.
P>>Вы в слова играете. У каждого своё видение, что именно относится к задаче. G>В итоге все сойдутся на мнении лида и оно станет одно.
Или не сойдутся, например, лид в отпуске, на больничном, на мите, на собесе, а надо срочно, итд итд итд. А может просто часть вещей делегировал не тем людям.
G>>>Это именно краткосрочная. P>>О чем я вам говорю, и это — проблема, т.к. все среднесрочные и долгосрочные цели вне фокуса. G>И это хорошо. Требования часто меняются, будущее угадывать невозможно. Нет смысла ориентироваться на "долгосрочные" цели разрабатывая каждый блок функционала
Не надо будущее угадывать. Есть вещи, которые известны наверняка. Например, при написании логирования вы точно знаете, что логи нужно будет где то собирать, смотреть, мониторить, читать, анализировать и тд.
Соотвественно, нужно включать голову и писать ровно то, что точно понадобится позже, а не в момент X заводить тикет "в логах херня ничо не ясно"
G>Как бы красиво не называли, это все попытка угадать будущее. И чаще всего люди не угадывают. Поэтому единственный универсальный способ — написать сегодня настолько мало, чтобы завтра было не жалко выкинуть.
Браво — у вас та самая попытка угадать будущее, предположение что всё нахрен не надо. Так себе идея. Обычно при проектировании учитывают как минимум известные риски. Например, закладывают некоторую ожидаемую нагрузку.
А если вас буквально воспринять, то такими глупостями вообще заниматься не надо. А что — пока проект не стартовал, нагрузка неизвестна.
P>>>>Я вам уже привел пример Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования. G>>>Практика показывает что занимаясь проектированием "только здесь и сейчас" почти всегда получается компактный код, который легко поддерживать.
Компактность слишком часто идет с невозможностью мейнтейнить, или хотя бы прочитать, проанализировать. Вы что, не видели проектов, которые раздувают до монстров однострочниками, никому не понятным метапрограммированием, срезанием углов и прочим мракобесием?
Я в недалёком прошлом выбросил просто чудовищную кучу кода как раз такого сорта — просто дропнул весь компактнейший всемогутор. И это вобщем довольно частый паттерн — "светило" пишет настолько компактно, что разве что компилятор с архиватором обогнать могут.
А вас почитать, это и есть наилучший вариант.
Как минимум, код должен быть поддерживаемым, читабельным, сопровождаемым. Иначе вы его даже выбросить не сможете, хоть и сильно-сильно захотите. А это именно то самое будущее которое, по вашему, никак не доступно, ужос-ужос.
P>>Вам что бы обратную совместимость заложить в какое апи уже надо отойти от здесь и сейчас, а рассмотреть а что же вообще может или не может появиться. G>Зачем нужна обратная совместимость? G>1) если добавляется необязательное поле, то старый код продолжает работать
Необязательно
G>2) если поле обязательное, то старый код в любом случае сломается
Необязательно
G>3) если происходят более значимые изменения, то просто создается новый метод (возможно с номером версии в сегменте пути, querystring или заголовке)
Необязательно
Вы шота держитесь за какой то свой вариант
G>Если задача создать новый метод не поломав старый, то она решается целиком. А не так, что сначала создается новый, а потом чинится старый. Некоторые изменения в системах должны быть атомарны — это и будет одна задача для одного программиста.
Важно не то, как вы будете создавать, а как вы будете деливерить. Многие вещи будут слишком большим изменением на одного программиста.
Re[20]: Что если не разделять строго dto, entity, bo...
G>>>Что там является "моделью предметной области", в чем её ценность, и как она влияет на остальные части кода? S>>Ну как минимум https://github.com/gandjustas/habr-post-stock-api/blob/main/Model.cs G>То есть "модель предметной области" это типизированное описание схемы БД, так? G>Апологеты DDD как раз с этим спорят.
1)Сразу оговорюсь, я не апологет DDD. Я ни одно книжки по DDD не прочитал, и много знаю по касательной.
Я просто не считаю правильным отмахивать от DDD, как о бесполезной штуке. Оно большое, и люди частями или
целиком его вполне успешно применяют.
2)
То есть "модель предметной области" это типизированное описание схемы БД,
Что в этом плохого и кто с этим спорит? В DDD есть паттерн Repository, как раз и отвечает за сохранение главных
доменных сущностей, наверное и таблицы соотв. должны были быть.
S>>Ну т.е. код ради кода, понятно. Ну вот есть хороший код, который плохо решает поставленную задачу, поскольку автор толком не разобрался в предметной области. Ну и какой прок от этой программы кроме эстетики кода? G>А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи?
Никто не сказал, просто это, кхм, странно. Задача софта эмулировать соотв. процессы. Как можно эмулировать что-то без
соотв. сущностей?
G>И кто сказал что наличие "объектов доменной модели" автоматически приводит к хорошему решению задачи?
Никто не сказал. Но вот вопрос -- что лучше, плохо написанная программа, которая прилично решает соотв. проблему предметной
области, или хорошо написанная программа, которая плохо решает заявленную проблему? Вы лично за какую бы программу заплатили бы
деньги?
Я вообще не вижу противоречия между хорошим кодом и объектами доменной модели. Это прям какая-то странная дихотомия.
S>>Ну и самый главный вопрос, а как всему вышеперечисленному мешает оперирование объектами доменной модели? G>Никак не мешает и никак не помогает. Хотя зависит от того, что входит в понятие "оперирование объектами доменной модели", так как это может давать ограничения G>Например код вида G>
Скорее оперирование представлением в бд.
S>>>>По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде. G>>>Вы как-то слишком широко применяете слово "абстракция". Когда вы создаете класс с набором свойств это не абстракция. Реализация интерфейса это тоже не абстракция. Абстракция это то, что использует такие классы или интерфейсы. А писать такой код нет необходимости. Большинство полезных абстракций уже есть в библиотеках, зачастую стандартных.
Я несколько фривольно обращался со словом абстракция. Я под этим больше понимал идеи доменных объектов. Я за это слово
в данном контексте не держусь. Тут речь главным образом об "объектах доменной модели".
S>>Делаю какой-нибудь реалистичны автотренажер или игру для машин, есть в стандартной библиотеке класс автомобиль, мотор и т.п.? G>Мы тут вроде как корпоративные приложения рассматриваем, которые оперируют данными в бд в многпользовательском режиме.
Какая разница, софт есть софт.
G>Думаю если бы мы рассматривали однопользовательскую 3д игру (видимо под ней понимается автотренажер), то там были бы объекты движка, которые представляют из себя "объекты на сцене", с "геомертрией", "текстурами" итд G>Нужно ли из них делать классы вроде "автомобиль", "мотор" — я не уверен.
Нужно, т.к. пользователь ничего про "объекты на сцене" или текстуры не знает, а знает про автомобиль, мотор и с ними напрямую взаимодействует.
S>>Ну мы ведем речь про явно более крупные приложения, а не про crud на 3 операции. G>Вспоминаем закон Галла G>
G>Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде
G>Вот простая система есть, мы начнем дополнять функциями, а модель БД — сущностями\таблицами G>Если функции пухнут — делаем Extract Method. G>Если несколько методов имеют один и тот же набор параметров, то делаем класс с этими параметрами в конструкторе и переносим вызовы внутрь него.
It is easy to complain about software bloat, and examples of needlessly complex system abound. But your bloat may be my lifeline, and what I dismiss as superfluous may for you be essential. To paraphrase a comment by Ichbiah, the designer of Ada, small systems solve small problems. Outside of academic prototypes it is inevitable that a successful software system will grow in complexity if it is to address the variety of users’ needs and circumstances. What matters is not size but consistency: maintaining a well-defined architecture that can sustain that growth without imperiling the system’s fundamental solidity and elegance.
Апологет DDD какай-то такой целью и задавались. На сколько вышло -- Народ использует, конференции ежегодные проводят, значит
кому-то заходит.
G>Сколько нам нужно функций, чтобы DDD с его паттернами стало давать какой-то профит?
Какой-то дурацкий вопрос, если честно. Типа сколько нужно людей, чтобы лампочку вкрутить. Вы какую-то цифру ждете?
Она, скорее всего, у каждого будет своя.
S>>А что стандартная библиотека, кстати, не помогла? G>Помогла
Само собой, но ее одной не достаточно.
Кодом людям нужно помогать!
Re[21]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>1)Сразу оговорюсь, я не апологет DDD. Я ни одно книжки по DDD не прочитал, и много знаю по касательной.
А я прочитал
0) Архитектура Корпоративных Программных Приложений (АКПП) Мартина Фаулера (2002 год), там первый раз в популярной литературе появился термин Domain Model (модель предметной области), но еще никакого DDD не было.
Базовых книг по DDD, которые в принципе определяют что такое DDD, всего две:
1) Domain Driven Design Эрика Эванса (2003 год), а также товарищ Эванс выпустил несколько книг с тем же по сути контентом в 2006, 2013 и 2015 годах.
2) Implementing Domain-Driven Design Вона Вернона (2013 год), который также выпустил справочник на основе своей книги в 2015. Он дополняет DDD событийно-ориентированной архитектурой, CQRS и натягивает это все на Hibernate
Была еще пара книг:
3) Applying DDD (2006 год), там убрали всю философию и попытались сделать примеры кода, но примеры получились настолько невнятные, что практическая ценность книги околонулевая,
4) Patterns, Principles, and Practices of Domain-Driven Design (2015 год), с качественными примерами на .NET и современным, на тот момент, паттернами. По своим идеям и подходам она не приносит ничего нового в DDD по сравнению с книгой Вернона (2).
И все
Я не утрирую, с 2002 по 2017 год было всего два визионера про DDD, и одна достойная книга про DDD, не на Java, и Фаулер, который активно это все пиарил в своем блоге.
А потом пришел Роберт Мартин, который очень любит слово "Clean" и выпустил свою Clean Architecture, где по сути постулировал, что Clean Architecture = Onion\Hexagon Architecture, которые являются вариантами (разными?) layered arhitecture, у которых в центре Domain Model, поэтому всем нужно DDD, а еще Bounded Contexts в DDD отлично соотносятся с микросервисами.
И после этого материалы по DDD\Clean\Microservices посыпались как из рога изобилия.
Поэтому я, возможно, чуть лучше разбираюсь в DDD. Кстати Фаулера я прочитал в 2008, а Эванса в 2009, и еще тогда многие подходы мне показались сомнительными.
S>Я просто не считаю правильным отмахивать от DDD, как о бесполезной штуке. Оно большое, и люди частями или целиком его вполне успешно применяют.
А чем измеряется успех? В том что программа работает? В том что заказчик платит денег? Может это успех вопреки? Может без DDD денег было бы больше, а программа правильнее?
Без сравнения в равных условиях мы не узнаем.
S>2) S>
S> То есть "модель предметной области" это типизированное описание схемы БД,
S>Что в этом плохого и кто с этим спорит? В DDD есть паттерн Repository, как раз и отвечает за сохранение главных S>доменных сущностей, наверное и таблицы соотв. должны были быть.
Ты не на тот вопрос отвечаешь. Вопрос такой: является ли набор классов без логики, с которыми работает ORM, "моделью предметной области" в понимании ДДД (по книгам)? Я могу однозначно сказать что нет.
G>>А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи? S>Никто не сказал, просто это, кхм, странно. Задача софта эмулировать соотв. процессы. Как можно эмулировать что-то без соотв. сущностей?
Еще раз. DDD как набор паттернов, говорит нам:
— Domain Model это набор классов с данными поведением, которые соответствуют существительным в едином языке, выработанным между бизнесом и командой разработки
— Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов
Я сейчас не буду говорить о том, насколько корректно так проектировать программы, но без этого DDD не будет считаться DDD.
G>>И кто сказал что наличие "объектов доменной модели" автоматически приводит к хорошему решению задачи?
S>Никто не сказал. Но вот вопрос -- что лучше, плохо написанная программа, которая прилично решает соотв. проблему предметной S>области, или хорошо написанная программа, которая плохо решает заявленную проблему? Вы лично за какую бы программу заплатили бы S>деньги?
Я не очень понимаю критериев оценки "хорошо или плохо". Программа может проблему решать или не решать. Мне как пользователю совершенно без разницы есть там "модель предметной области" или нет. Если две программы одинаково решают мою (не какой-то абстрактной предметной области) проблему, то выберу ту, которая дешевле по совокупной стоимости владения.
S>Я вообще не вижу противоречия между хорошим кодом и объектами доменной модели. Это прям какая-то странная дихотомия.
Я тоже не вижу. Качество программы и наличие в ней domain model — вещи ортогональные, то есть независимые друг от друга.
S>>>Ну и самый главный вопрос, а как всему вышеперечисленному мешает оперирование объектами доменной модели? G>>Никак не мешает и никак не помогает. Хотя зависит от того, что входит в понятие "оперирование объектами доменной модели", так как это может давать ограничения G>>Например код вида G>>
G>>Является "оперированием объектами доменной модели"? S>Скорее оперирование представлением в бд.
То есть не соответствует DDD никак, да еще и ужасную вещь делает с точки зрения Clean Architecture — прибивает бизнес-логику к инфраструктуре.
Причем этот код решает задачу "сделать отгрузку товаров со склада X", которую крайне сложно описать в DDD, особенно чтобы была изоляция. Внезапно еще и "отгрузка" никак не фигурирует в моделях БД.
S>>>Делаю какой-нибудь реалистичны автотренажер или игру для машин, есть в стандартной библиотеке класс автомобиль, мотор и т.п.? G>>Мы тут вроде как корпоративные приложения рассматриваем, которые оперируют данными в бд в многпользовательском режиме. S>Какая разница, софт есть софт.
У Эрика Липперта — он написал гораздо больше и полезнее, чем Фаулер, Эванс и Вернон вместе взятые и вообще крутой программист и инженер — есть потрясающая серия статей Wizards and Warriors, которую я даже перевел на хабре
Программа должна поддерживать согласованное состояние перед лицом попыток пользователя (клиента) изменить это состояние
Когда у нас программа работает на компьютере пользователя, в одном процессе (адресном пространстве) и её состояние существует столько, сколько существует процесс, то требования будут одни. Если состояние программы хранится во внешнем хранилище, к которому надо обращаться по ненадежной сети, причем обращаться могут несколько пользователей из разных экземпляров программы, то требования получатся совершенно другие. И подходы к проектированию и реализации программы будут разные.
S>It is easy to complain about software bloat, and examples of needlessly complex system abound. But your bloat may be my lifeline, and what I dismiss as superfluous may for you be essential. To paraphrase a comment by Ichbiah, the designer of Ada, small systems solve small problems. Outside of academic prototypes it is inevitable that a successful software system will grow in complexity if it is to address the variety of users’ needs and circumstances. What matters is not size but consistency: maintaining a well-defined architecture that can sustain that growth without imperiling the system’s fundamental solidity and elegance.
S>Апологет DDD какай-то такой целью и задавались. На сколько вышло --
Очень сложно проверить насколько им удалось придумать архитектуру, которая сохраняет целостность и элегантность длительное время.
S>Народ использует, конференции ежегодные проводят, значит кому-то заходит.
Это вообще не показатель. Я пережил столько хайпов в ИТ уже, и после каждого еще долго оставались толпы фанатов "кому заходит".
Тем более есть проблема: кроме Clean Architecture и DDD в медийном поле вообще не существует других подходов. У альтернативы ДДД даже названия собственного нет, она состоит из применения принципов YAGNI, KISS, DRY, top-down подхода к проектированию и разработке, частично SOLID.
Многое кстати было описано в книге Pragmatic Programmer Ханта и Томаса (2000 год), то есть за пар лет до фаулера-эванса и там нет такой категоричной упоротости на ООП. Несмотря на то, что части сведений в книге устарели я, с вашего позволения, буду называть подход — Прагматичным Программированием или Прагматичным Проектированием, сокрушённо ПП
G>>Сколько нам нужно функций, чтобы DDD с его паттернами стало давать какой-то профит? S>Какой-то дурацкий вопрос, если честно. Типа сколько нужно людей, чтобы лампочку вкрутить. Вы какую-то цифру ждете? S>Она, скорее всего, у каждого будет своя.
Любую теорию, например теорию о полезности DDD, можно считать научной если существует хотя бы один эксперимент, который может теорию опровергнуть, даже если он еще не проведен. Это называется критерий фальсифицируемости поппера.
А если такого эксперимента не существует, то это уже не теория, а вера.
Я посмотрел историю избранных другими моих сообщений. Я холиварю против DDD с 2009 года (видимо сразу после того как книгу прочитал), с тех пор НИ ОДНОГО ПРИМЕРА, демонстрирующего превосходства DDD над ПП в рамках этого форума. Я даже для прикола брал ndddsample и переписывал на код без DDD — получалось компактнее при том же функционале. Жалко код уже утерян.
Re[22]: Что если не разделять строго dto, entity, bo...
G>Я не утрирую, с 2002 по 2017 год было всего два визионера про DDD, и одна достойная книга про DDD, не на Java, и Фаулер, который активно это все пиарил в своем блоге.
А сколько визионеров надо, что технология взлетела? У ООП много было визионеров, тоже 2-3 человека.
По DDD уже много лет конференции проводят -- https://www.youtube.com/@ddd_eu
G>Поэтому я, возможно, чуть лучше разбираюсь в DDD. Кстати Фаулера я прочитал в 2008, а Эванса в 2009, и еще тогда многие подходы мне показались сомнительными.
Я же не спорю с этим.
S>>Я просто не считаю правильным отмахивать от DDD, как о бесполезной штуке. Оно большое, и люди частями или целиком его вполне успешно применяют. G>А чем измеряется успех? В том что программа работает? В том что заказчик платит денег? Может это успех вопреки? Может без DDD денег было бы больше, а программа правильнее?
Ну какая-то статистика и выборка же есть, этим не одна компания занимается. Метрики такие, например, что сложный софт развивается.
Т.е. заказчик деньги платит не зря.
G>Без сравнения в равных условиях мы не узнаем.
Ну такой себе странный аргумент. Лишних денег ни у кого нету. Разве что у крупняка типа ibm, которые могут себе позволить несколько назависимых отделов
для решения одной проблемы.
S>>Что в этом плохого и кто с этим спорит? В DDD есть паттерн Repository, как раз и отвечает за сохранение главных S>>доменных сущностей, наверное и таблицы соотв. должны были быть. G>Ты не на тот вопрос отвечаешь. Вопрос такой: является ли набор классов без логики, с которыми работает ORM, "моделью предметной области" в понимании ДДД (по книгам)? Я могу однозначно сказать что нет.
Без логики не является, и? ORM это не тот уровень, на котором стоит обсуждать DDD. Он там спрятан за паnтерном Repository.
G>>>А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи? S>>Никто не сказал, просто это, кхм, странно. Задача софта эмулировать соотв. процессы. Как можно эмулировать что-то без соотв. сущностей? G>Еще раз. DDD как набор паттернов, говорит нам: G>- Domain Model это набор классов с данными поведением, которые соответствуют существительным в едином языке, выработанным между бизнесом и командой разработки G>- Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов
Там вроде, все строится вокруг взаимодействия AggregateRoot'ов, которые несколько больше чем просто "набор классов с данными поведением".
G>Я сейчас не буду говорить о том, насколько корректно так проектировать программы, но без этого DDD не будет считаться DDD.
Я пока понять не могу, что в этом плохого?
G>>>И кто сказал что наличие "объектов доменной модели" автоматически приводит к хорошему решению задачи?
S>>Никто не сказал. Но вот вопрос -- что лучше, плохо написанная программа, которая прилично решает соотв. проблему предметной S>>области, или хорошо написанная программа, которая плохо решает заявленную проблему? Вы лично за какую бы программу заплатили бы S>>деньги? G>Я не очень понимаю критериев оценки "хорошо или плохо". Программа может проблему решать или не решать. Мне как пользователю совершенно без разницы есть там "модель предметной области" или нет. Если две программы одинаково решают мою (не какой-то абстрактной предметной области) проблему, то выберу ту, которая дешевле по совокупной стоимости владения.
Это уход от ответа на конкретный вопрос. Речь не про одинаково. Программа написана хорошо, но не покрывает большую часть use-case'ов или
делает это криво. У другой все наоборот. Какой программист больше заработает денег?
S>>Я вообще не вижу противоречия между хорошим кодом и объектами доменной модели. Это прям какая-то странная дихотомия. G>Я тоже не вижу. Качество программы и наличие в ней domain model — вещи ортогональные, то есть независимые друг от друга.
Ну т.е. можно использовать excel в качестве бд, написан хорошо, данные хранить может. Или все же возьмем что-то другое для
данной задачи?
G>>>Является "оперированием объектами доменной модели"? S>>Скорее оперирование представлением в бд. G>То есть не соответствует DDD никак, да еще и ужасную вещь делает с точки зрения Clean Architecture — прибивает бизнес-логику к инфраструктуре. G>Причем этот код решает задачу "сделать отгрузку товаров со склада X", которую крайне сложно описать в DDD, особенно чтобы была изоляция. Внезапно еще и "отгрузка" никак не фигурирует в моделях БД.
Этот код может и ракету в космос запустить, дальше что?
S>>Какая разница, софт есть софт. G>У Эрика Липперта — он написал гораздо больше и полезнее, чем Фаулер, Эванс и Вернон вместе взятые и вообще крутой программист и инженер — есть потрясающая серия статей Wizards and Warriors, которую я даже перевел на хабре G>В пятой части он сформулировал тезис: G>
G>Программа должна поддерживать согласованное состояние перед лицом попыток пользователя (клиента) изменить это состояние
G>Когда у нас программа работает на компьютере пользователя, в одном процессе (адресном пространстве) и её состояние существует столько, сколько существует процесс, то требования будут одни. Если состояние программы хранится во внешнем хранилище, к которому надо обращаться по ненадежной сети, причем обращаться могут несколько пользователей из разных экземпляров программы, то требования получатся совершенно другие. И подходы к проектированию и реализации программы будут разные.
Инвариант класса называется, которое Б. Мейер лет 40 назад ввел в обиход. При чем здесь бд или сеть?
S>>It is easy to complain about software bloat, and examples of needlessly complex system abound. But your bloat may be my lifeline, and what I dismiss as superfluous may for you be essential. To paraphrase a comment by Ichbiah, the designer of Ada, small systems solve small problems. Outside of academic prototypes it is inevitable that a successful software system will grow in complexity if it is to address the variety of users’ needs and circumstances. What matters is not size but consistency: maintaining a well-defined architecture that can sustain that growth without imperiling the system’s fundamental solidity and elegance.
S>>Апологет DDD какай-то такой целью и задавались. На сколько вышло -- G>Очень сложно проверить насколько им удалось придумать архитектуру, которая сохраняет целостность и элегантность длительное время.
S>>Народ использует, конференции ежегодные проводят, значит кому-то заходит. G>Это вообще не показатель. Я пережил столько хайпов в ИТ уже, и после каждого еще долго оставались толпы фанатов "кому заходит". G>Тем более есть проблема: кроме Clean Architecture и DDD в медийном поле вообще не существует других подходов. У альтернативы ДДД даже названия собственного нет, она состоит из применения принципов YAGNI, KISS, DRY, top-down подхода к проектированию и разработке, частично SOLID. G>Многое кстати было описано в книге Pragmatic Programmer Ханта и Томаса (2000 год), то есть за пар лет до фаулера-эванса и там нет такой категоричной упоротости на ООП. Несмотря на то, что части сведений в книге устарели я, с вашего позволения, буду называть подход — Прагматичным Программированием или Прагматичным Проектированием, сокрушённо ПП
G>>>Сколько нам нужно функций, чтобы DDD с его паттернами стало давать какой-то профит? S>>Какой-то дурацкий вопрос, если честно. Типа сколько нужно людей, чтобы лампочку вкрутить. Вы какую-то цифру ждете? S>>Она, скорее всего, у каждого будет своя. G>Любую теорию, например теорию о полезности DDD, можно считать научной если существует хотя бы один эксперимент, который может теорию опровергнуть, даже если он еще не проведен. Это называется критерий фальсифицируемости поппера. G>А если такого эксперимента не существует, то это уже не теория, а вера.
Я не понимаю о чем идет речь и к чему эти странные вопросы и ответы с отсылками на Поппера. Возьмите какой-нибудь проект по DDD
и подсчитай в нем ф-ии.
Если так подходить, то сколько надо строк кода, чтобы ООП давал выхлоп? Может < писать на Си или ФЯ? Но почему-то для простейших задачи
на сотни строк кода все равно используют ООП. Странно, правда?
G>Я посмотрел историю избранных другими моих сообщений. Я холиварю против DDD с 2009 года (видимо сразу после того как книгу прочитал), с тех пор НИ ОДНОГО ПРИМЕРА, демонстрирующего превосходства DDD над ПП в рамках этого форума. Я даже для прикола брал ndddsample и переписывал на код без DDD — получалось компактнее при том же функционале. Жалко код уже утерян.
Ну нету здесь таких, ищите на хабре, например или на SO.
Кодом людям нужно помогать!
Re[23]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Я не утрирую, с 2002 по 2017 год было всего два визионера про DDD, и одна достойная книга про DDD, не на Java, и Фаулер, который активно это все пиарил в своем блоге.
S>А сколько визионеров надо, что технология взлетела? У ООП много было визионеров, тоже 2-3 человека.
Считаем:
1) Создатели языка Simula, где впервые появилось слово class — Оле-Йохан Даль и Кристен Нюгор, оба профессора
2) Алан Кей, который придумал сам термин ООП и язык Smalltalk, который под воздействием Simula получил понятия "класс" и "объект"
3) Бьёрн Страуструп, который идею классов и объектов натянул на С++, дав начало большей части современных ОО-яызыков
Каждый из них в отдельности имеет больше достижений, написал больше статей и больше создал кода, чем все авторы по DDDвместе взятые.
S>По DDD уже много лет конференции проводят -- https://www.youtube.com/@ddd_eu
Это вообще не показатель. Люди астрологией и гомеопатией занимаются, гораздо больше лет конференции проводят. Программисты тоже подвержены влиянию всяких лженаук.
S>>>Я просто не считаю правильным отмахивать от DDD, как о бесполезной штуке. Оно большое, и люди частями или целиком его вполне успешно применяют. G>>А чем измеряется успех? В том что программа работает? В том что заказчик платит денег? Может это успех вопреки? Может без DDD денег было бы больше, а программа правильнее? S>Ну какая-то статистика и выборка же есть, этим не одна компания занимается. Метрики такие, например, что сложный софт развивается. S>Т.е. заказчик деньги платит не зря.
Повторить аргумент про лженауки?
G>>Без сравнения в равных условиях мы не узнаем. S>Ну такой себе странный аргумент. Лишних денег ни у кого нету. Разве что у крупняка типа ibm, которые могут себе позволить несколько назависимых отделов S>для решения одной проблемы.
То есть просто вера, что DDD помогает? Верить не мешает. Но для участия в научном споре одной веры недостаточно.
S>>>Что в этом плохого и кто с этим спорит? В DDD есть паттерн Repository, как раз и отвечает за сохранение главных S>>>доменных сущностей, наверное и таблицы соотв. должны были быть. G>>Ты не на тот вопрос отвечаешь. Вопрос такой: является ли набор классов без логики, с которыми работает ORM, "моделью предметной области" в понимании ДДД (по книгам)? Я могу однозначно сказать что нет. S>Без логики не является, и? ORM это не тот уровень, на котором стоит обсуждать DDD.
Почему? Меня интересует только подход к проектированию и написанию кода. Если DDD не про это, то я не понимаю о чем говорить.
S>Он там спрятан за паnтерном Repository.
И какой интерфейс выставляет этот Repository?
G>>>>А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи? S>>>Никто не сказал, просто это, кхм, странно. Задача софта эмулировать соотв. процессы. Как можно эмулировать что-то без соотв. сущностей? G>>Еще раз. DDD как набор паттернов, говорит нам: G>>- Domain Model это набор классов с данными поведением, которые соответствуют существительным в едином языке, выработанным между бизнесом и командой разработки G>>- Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов S>Там вроде, все строится вокруг взаимодействия AggregateRoot'ов, которые несколько больше чем просто "набор классов с данными поведением".
Если для реализации поведения вам нужны Order, Line и Product, то они попадут в один агрегат.
G>>Я сейчас не буду говорить о том, насколько корректно так проектировать программы, но без этого DDD не будет считаться DDD. S>Я пока понять не могу, что в этом плохого?
Если программа НЕ будет соответствовать паттернам DDD она будет лучше, чем если будет им соответствовать.
S>Это уход от ответа на конкретный вопрос. Речь не про одинаково. Программа написана хорошо, но не покрывает большую часть use-case'ов или делает это криво. У другой все наоборот.
То есть одна программа не решает проблему пользователя, а другая решает.
Только от наличия "модели предметной области" это не зависит. Может быть модель и не решать проблему, а может не быть и решать.
S>Какой программист больше заработает денег?
Зависит от разницы в цене и насколько пользователь готов пожертвовать решением за эту разницу
S>>>Я вообще не вижу противоречия между хорошим кодом и объектами доменной модели. Это прям какая-то странная дихотомия. G>>Я тоже не вижу. Качество программы и наличие в ней domain model — вещи ортогональные, то есть независимые друг от друга.
S>Ну т.е. можно использовать excel в качестве бд, написан хорошо, данные хранить может. Или все же возьмем что-то другое для данной задачи?
Ты про мой пример? Там конечно эксель не подойдет, ибо нужны ACID транзакции, которые работают конкурентно. Эта задача решается в РСУБД из коробки, даже писать ничего не надо.
Для других задач может и эксель подойти, но он не обеспечивает sql-совместимого интерфейса и не может использоваться с существующими библиотеками, поэтом маловероятно.
G>>>>Является "оперированием объектами доменной модели"? S>>>Скорее оперирование представлением в бд. G>>То есть не соответствует DDD никак, да еще и ужасную вещь делает с точки зрения Clean Architecture — прибивает бизнес-логику к инфраструктуре. G>>Причем этот код решает задачу "сделать отгрузку товаров со склада X", которую крайне сложно описать в DDD, особенно чтобы была изоляция. Внезапно еще и "отгрузка" никак не фигурирует в моделях БД. S>Этот код может и ракету в космос запустить, дальше что?
Интересное утверждение. Каким образом он может ракету запустить?
G>>Когда у нас программа работает на компьютере пользователя, в одном процессе (адресном пространстве) и её состояние существует столько, сколько существует процесс, то требования будут одни. Если состояние программы хранится во внешнем хранилище, к которому надо обращаться по ненадежной сети, причем обращаться могут несколько пользователей из разных экземпляров программы, то требования получатся совершенно другие. И подходы к проектированию и реализации программы будут разные. S>Инвариант класса называется, которое Б. Мейер лет 40 назад ввел в обиход. При чем здесь бд или сеть?
Инвариантность класса не помогает обеспечить целостность состояния во внешнем хранилище.
G>>Любую теорию, например теорию о полезности DDD, можно считать научной если существует хотя бы один эксперимент, который может теорию опровергнуть, даже если он еще не проведен. Это называется критерий фальсифицируемости поппера. G>>А если такого эксперимента не существует, то это уже не теория, а вера. S>Я не понимаю о чем идет речь и к чему эти странные вопросы и ответы с отсылками на Поппера. Возьмите какой-нибудь проект по DDD и подсчитай в нем ф-ии.
И как это поможет доказать что DDD имеет какие-то преимущества?
S>Если так подходить, то сколько надо строк кода, чтобы ООП давал выхлоп?
вот минимальный пример:
abstract class CollectionBase<T>
{
public int Count { get; private set; }
protected virtual void AddCore(T item)
public void Add(T item)
{
AddCore(item);
Count+=1;
}
protected virtual T GetCore(int index);
public T Get(int index)
{
ArgumentOutOfRangeException.ThrowIfGreaterThanOrEqual(index, Count);
ArgumentOutOfRangeException.ThrowIfNegative(index);
return GetCore(index);
}
}
Тут и наследование, и инкапсуляция, и полиморфизм, и OCP, и LSP.
Попытка получить от кода те же свойства без наследования, инкапсуляции и полиморфизма ни к чему хорошему не приведут.
А если взять чуть побольше пример, как в GoF про паттерн Composite, то ООП то там еще лучше получается.
S>Может < писать на Си или ФЯ? Но почему-то для простейших задачи на сотни строк кода все равно используют ООП. Странно, правда?
Мне кажется что осмысленно говорить, что кто-то использует ООП, только когда есть наследование, инкапсуляция и полиморфизм.
Я видел много кода на C#, который с точностью до синтаксиса и названия библиотек\неймспейсово\классов\методов можно переписать на Rust. Использует ли такой код на C# ООП? Я считаю что нет.
Здравствуйте, gandjustas, Вы писали:
S>>А сколько визионеров надо, что технология взлетела? У ООП много было визионеров, тоже 2-3 человека. G>Считаем: G>1) Создатели языка Simula, где впервые появилось слово class — Оле-Йохан Даль и Кристен Нюгор, оба профессора G>2) Алан Кей, который придумал сам термин ООП и язык Smalltalk, который под воздействием Simula получил понятия "класс" и "объект" G>3) Бьёрн Страуструп, который идею классов и объектов натянул на С++, дав начало большей части современных ОО-яызыков G>Каждый из них в отдельности имеет больше достижений, написал больше статей и больше создал кода, чем все авторы по DDDвместе взятые.
Все это так, но речь не об этом. Все это ученые и компиляторо писатели. А Эрик Эванс вроде разрабатывал бизнес приложения,
и вроде (но не точно) работал в ibm. Мой вопрос был про кол-во людей, что много людей для того, чтобы технология взлетела
и не требуется. Сравнивать их не имеет смысл. У DDD роль гораздо меньше.
S>>По DDD уже много лет конференции проводят -- https://www.youtube.com/@ddd_eu G>Это вообще не показатель. Люди астрологией и гомеопатией занимаются, гораздо больше лет конференции проводят. Программисты тоже подвержены влиянию всяких лженаук.
Ну не скажите, там иногда читают очень достойные доклады. Вот например: https://www.youtube.com/watch?v=KTy4rqgPOjg
S>>Ну какая-то статистика и выборка же есть, этим не одна компания занимается. Метрики такие, например, что сложный софт развивается. S>>Т.е. заказчик деньги платит не зря. G>Повторить аргумент про лженауки?
В чем проблема найти компании и продукты у которых работает DDD? Спросите нейронку какую-нибудь. Наверняка что-то есть из докладов
по ссылке выше.
S>>Ну такой себе странный аргумент. Лишних денег ни у кого нету. Разве что у крупняка типа ibm, которые могут себе позволить несколько назависимых отделов S>>для решения одной проблемы. G>То есть просто вера, что DDD помогает? Верить не мешает. Но для участия в научном споре одной веры недостаточно.
А в ООП тоже верят? Ведь есть проекты для которых он избыточен, но все равно будет написано с 95% на каком-нибудь ООП языке.
S>>Без логики не является, и? ORM это не тот уровень, на котором стоит обсуждать DDD. G>Почему? Меня интересует только подход к проектированию и написанию кода. Если DDD не про это, то я не понимаю о чем говорить.
Он не про ORM и таблицы в бд.
S>>Он там спрятан за паnтерном Repository. G>И какой интерфейс выставляет этот Repository?
Можно нагуглить.
G>>>- Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов S>>Там вроде, все строится вокруг взаимодействия AggregateRoot'ов, которые несколько больше чем просто "набор классов с данными поведением". G>Если для реализации поведения вам нужны Order, Line и Product, то они попадут в один агрегат.
Вероятно и у приложения будет один Bounded Context и один микросервис. Что не так?
S>>Я пока понять не могу, что в этом плохого? G>Если программа НЕ будет соответствовать паттернам DDD она будет лучше, чем если будет им соответствовать.
Зависит от сложности. Ну найдите людей у которых все по DDD и поговорите с ними. Писать калькулятор по DDD странно, но какой-нибудь
банковский софт, где требования регулярно меняются вполне может быть ок. Как обычно -- it depends.
S>>Какой программист больше заработает денег? G>Зависит от разницы в цене и насколько пользователь готов пожертвовать решением за эту разницу
Едва ли будет ценовая разница, край несколько 10$. Можно считать, что цена одинакова.
S>>Инвариант класса называется, которое Б. Мейер лет 40 назад ввел в обиход. При чем здесь бд или сеть? G>Инвариантность класса не помогает обеспечить целостность состояния во внешнем хранилище.
Если сохранять класс, когда у него все ок с инвариантами, то почему нет? Для пользователя класса у него всегда должны
быть инварианты, пользователь затем может этот класс сохранить.
S>>Я не понимаю о чем идет речь и к чему эти странные вопросы и ответы с отсылками на Поппера. Возьмите какой-нибудь проект по DDD и подсчитай в нем ф-ии. G>И как это поможет доказать что DDD имеет какие-то преимущества?
А как это может доказать обратное? Зачем вообще что-либо подсчитывать?
S>>Если так подходить, то сколько надо строк кода, чтобы ООП давал выхлоп?
G>вот минимальный пример: G>
G>abstract class CollectionBase<T>
G>{
G> public int Count { get; private set; }
G> protected virtual void AddCore(T item)
G> public void Add(T item)
G> {
G> AddCore(item);
G> Count+=1;
G> }
G> protected virtual T GetCore(int index);
G> public T Get(int index)
G> {
G> ArgumentOutOfRangeException.ThrowIfGreaterThanOrEqual(index, Count);
G> ArgumentOutOfRangeException.ThrowIfNegative(index);
G> return GetCore(index);
G> }
G>}
G>
G>Тут и наследование, и инкапсуляция, и полиморфизм, и OCP, и LSP. G>Попытка получить от кода те же свойства без наследования, инкапсуляции и полиморфизма ни к чему хорошему не приведут.
А как люди с коллекциями на Си работали и работают?
S>>Может < писать на Си или ФЯ? Но почему-то для простейших задачи на сотни строк кода все равно используют ООП. Странно, правда? G>Мне кажется что осмысленно говорить, что кто-то использует ООП, только когда есть наследование, инкапсуляция и полиморфизм. G>Я видел много кода на C#, который с точностью до синтаксиса и названия библиотек\неймспейсово\классов\методов можно переписать на Rust. Использует ли такой код на C# ООП? Я считаю что нет.
Тем не менее пишут же зачем-то на C#.
Кодом людям нужно помогать!
Re[25]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Все это так, но речь не об этом. Все это ученые и компиляторо писатели. А Эрик Эванс вроде разрабатывал бизнес приложения, и вроде (но не точно) работал в ibm.
Честно говоря я вообще не знаю чем ванс занимался до написания книги и есть и значимые проекты в его истории. После он начал заниматься консалтингом.
S>Мой вопрос был про кол-во людей, что много людей для того, чтобы технология взлетела и не требуется. Сравнивать их не имеет смысл. У DDD роль гораздо меньше.
Вроде ты сам пытался сравнить DDD и ООП.
S>>>По DDD уже много лет конференции проводят -- https://www.youtube.com/@ddd_eu G>>Это вообще не показатель. Люди астрологией и гомеопатией занимаются, гораздо больше лет конференции проводят. Программисты тоже подвержены влиянию всяких лженаук. S>Ну не скажите, там иногда читают очень достойные доклады. Вот например: S>https://www.youtube.com/watch?v=KTy4rqgPOjg
Не понял что в этом докладе интересного. Целый час только ради одного слайда с одной мыслью
Pain = Strength * Volatility * Distance.
Reduce one of them to 0 to minimize the pain of necessary coupling.
S>>>Ну какая-то статистика и выборка же есть, этим не одна компания занимается. Метрики такие, например, что сложный софт развивается. S>>>Т.е. заказчик деньги платит не зря. G>>Повторить аргумент про лженауки?
S>В чем проблема найти компании и продукты у которых работает DDD? Спросите нейронку какую-нибудь. Наверняка что-то есть из докладов по ссылке выше.
Еще раз повторить аргумент про лженауки? У кого-то и астрология "работает".
Единственный способ доказать что что-то работает — провести эксперимент. Для ДДД это простой эксперимент — берем любой код с DDD, делаем эквивалентный без DDD и сравниваем объективные показатели — объем кода, количество связей между классами итд.
Важно взять именно работающий код, решающий задачу от начала до конца.
S>>>Ну такой себе странный аргумент. Лишних денег ни у кого нету. Разве что у крупняка типа ibm, которые могут себе позволить несколько назависимых отделов S>>>для решения одной проблемы. G>>То есть просто вера, что DDD помогает? Верить не мешает. Но для участия в научном споре одной веры недостаточно. S>А в ООП тоже верят? Ведь есть проекты для которых он избыточен, но все равно будет написано с 95% на каком-нибудь ООП языке.
Некоторые не верят, но что это меняет? Современные языки используют ОО-парадигму и часто базовые библиотеки реализованы как библиотеки классов. То есть ты любом случае будешь использовать ООП, даже если сам не придерживаешься ОО-парадигмы.
S>>>Без логики не является, и? ORM это не тот уровень, на котором стоит обсуждать DDD. G>>Почему? Меня интересует только подход к проектированию и написанию кода. Если DDD не про это, то я не понимаю о чем говорить. S>Он не про ORM и таблицы в бд.
А про что?
Меня интересует подход к проектированию от начала до конца, а не просто в какой-то части, делая вид что других не существует.
G>>>>- Вся бизнес-логика (Core Domain) должна быть описана как взаимодействие этих объектов S>>>Там вроде, все строится вокруг взаимодействия AggregateRoot'ов, которые несколько больше чем просто "набор классов с данными поведением". G>>Если для реализации поведения вам нужны Order, Line и Product, то они попадут в один агрегат. S>Вероятно и у приложения будет один Bounded Context и один микросервис. Что не так?
Если order, line и product в одном агрегате, где root это order, то как получить список "лидеры продаж" с топ 30 товаров за месяц.
S>>>Я пока понять не могу, что в этом плохого? G>>Если программа НЕ будет соответствовать паттернам DDD она будет лучше, чем если будет им соответствовать. S>Зависит от сложности. Ну найдите людей у которых все по DDD и поговорите с ними. Писать калькулятор по DDD странно, но какой-нибудь банковский софт, где требования регулярно меняются вполне может быть ок. Как обычно -- it depends.
См выше про эксперимент. Мнение интересует в последнюю очередь.
S>>>Инвариант класса называется, которое Б. Мейер лет 40 назад ввел в обиход. При чем здесь бд или сеть? G>>Инвариантность класса не помогает обеспечить целостность состояния во внешнем хранилище. S>Если сохранять класс, когда у него все ок с инвариантами, то почему нет?
Потому что в рамках одного класса нельзя сделать контроль остатков.
S>Для пользователя класса у него всегда должны быть инварианты, пользователь затем может этот класс сохранить.
Как описать инвариант: остаток товаров на складе должен быть не меньше суммы зарезервированных?
S>>>Я не понимаю о чем идет речь и к чему эти странные вопросы и ответы с отсылками на Поппера. Возьмите какой-нибудь проект по DDD и подсчитай в нем ф-ии. G>>И как это поможет доказать что DDD имеет какие-то преимущества? S>А как это может доказать обратное? Зачем вообще что-либо подсчитывать?
Затем что нужны объективные измеримые показатели преимуществ того или иного подхода: объем, цикломатическая сложность, вложенность вызовов. Иначе это вера, а не инженерный подход.
S>А как люди с коллекциями на Си работали и работают?
Плохо, у C до сих пор нет стандартной библиотеки коллекций, в каждой прикладной библиотеки свои коллекции, которые могут быть несовместимы между ними.
S>Тем не менее пишут же зачем-то на C#.
Потому C# и дотнет предоставляет много готовых согласованных между собой библиотек для решения прикладных задач.
Re[26]: Что если не разделять строго dto, entity, bo...
Здравствуйте, gandjustas, Вы писали:
S>>Все это так, но речь не об этом. Все это ученые и компиляторо писатели. А Эрик Эванс вроде разрабатывал бизнес приложения, и вроде (но не точно) работал в ibm. G>Честно говоря я вообще не знаю чем ванс занимался до написания книги и есть и значимые проекты в его истории. После он начал заниматься консалтингом.
Я тоже не знаю. Но он как и Фаулер или дядя Боб -- что-то поделали в самом начале, потом решили лопаты продавать книги писать.
S>>Мой вопрос был про кол-во людей, что много людей для того, чтобы технология взлетела и не требуется. Сравнивать их не имеет смысл. У DDD роль гораздо меньше. G>Вроде ты сам пытался сравнить DDD и ООП.
Неправда. Я сравнивал кол-во апологетов ООП и ДДД. Намек был на то, что и там и там их было немного. Более того, сравнивать их лично не имеет
никакого смысла -- одни делали новую технологию, другие -- методологию.
S>>Ну не скажите, там иногда читают очень достойные доклады. Вот например: S>>https://www.youtube.com/watch?v=KTy4rqgPOjg G>Не понял что в этом докладе интересного. Целый час только ради одного слайда с одной мыслью G>
G>Pain = Strength * Volatility * Distance.
G>Reduce one of them to 0 to minimize the pain of necessary coupling.
Мне понравился, добавил в избранное на пересмотреть. Там много вещей проговаривает помимо этой формулы.
S>>В чем проблема найти компании и продукты у которых работает DDD? Спросите нейронку какую-нибудь. Наверняка что-то есть из докладов по ссылке выше. G>Еще раз повторить аргумент про лженауки? У кого-то и астрология "работает". G>Единственный способ доказать что что-то работает — провести эксперимент. Для ДДД это простой эксперимент — берем любой код с DDD, делаем эквивалентный без DDD и сравниваем объективные показатели — объем кода, количество связей между классами итд. G>Важно взять именно работающий код, решающий задачу от начала до конца.
Мне это не интересно. Вам интересно, вы и делайте. Я хочу донести мысль, что огульно выкидывать ДДД не стоит -- для кого-то на каких-то проектов
он работает. Я работал в компании, которая распиливала монолит на микросервисы по ДДД. Использовали стратегические паттерны. Оправдано или нет -- не знаю, но вроде как-то работало. Опять же ДДД был не в полный рост, а что-то заимствовалось.
S>>А в ООП тоже верят? Ведь есть проекты для которых он избыточен, но все равно будет написано с 95% на каком-нибудь ООП языке. G>Некоторые не верят, но что это меняет? Современные языки используют ОО-парадигму и часто базовые библиотеки реализованы как библиотеки классов. То есть ты любом случае будешь использовать ООП, даже если сам не придерживаешься ОО-парадигмы.
Некоторые не верят в ДДД, но что это меняет.
S>>Он не про ORM и таблицы в бд. G>А про что?
101 раз говорю, что там все эти детали скрыты за паттерном Репозиторий. ДДД, кажется, не об этом.
G>Меня интересует подход к проектированию от начала до конца, а не просто в какой-то части, делая вид что других не существует.
Это подход к проектировании на основе проблем бизнеса, а не про орм или таблицы.
S>>Вероятно и у приложения будет один Bounded Context и один микросервис. Что не так? G>Если order, line и product в одном агрегате, где root это order, то как получить список "лидеры продаж" с топ 30 товаров за месяц.
Какой-то метод добавить в репозиторий, наверное.
S>>Зависит от сложности. Ну найдите людей у которых все по DDD и поговорите с ними. Писать калькулятор по DDD странно, но какой-нибудь банковский софт, где требования регулярно меняются вполне может быть ок. Как обычно -- it depends. G>См выше про эксперимент. Мнение интересует в последнюю очередь.
Сдается мне, на ООП языках вы стали писать без всяких экспериментов. На основе чьего-то мнения, скорее всего. И, наверное, до сих пор
полет нормальный.
S>>Если сохранять класс, когда у него все ок с инвариантами, то почему нет? G>Потому что в рамках одного класса нельзя сделать контроль остатков.
Почему?
S>>Для пользователя класса у него всегда должны быть инварианты, пользователь затем может этот класс сохранить. G>Как описать инвариант: остаток товаров на складе должен быть не меньше суммы зарезервированных?
Вычитать соотв. поля из бд, взяв соотв. лок предварительно, посчитать и в зависимости от, продолжить работу.
S>>А как это может доказать обратное? Зачем вообще что-либо подсчитывать? G>Затем что нужны объективные измеримые показатели преимуществ того или иного подхода: объем, цикломатическая сложность, вложенность вызовов. Иначе это вера, а не инженерный подход.
См. выше про ООП -- что такое проделывали?
Еще раз -- я не агитирую за ДДД, я против огульного откидывания подходов, мол "не нравится", "не встречал" и т.п. Это субъективщина.
Наверняка можно найти человека с обратным опытом.
Кодом людям нужно помогать!
Re[27]: Что если не разделять строго dto, entity, bo...
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Все это так, но речь не об этом. Все это ученые и компиляторо писатели. А Эрик Эванс вроде разрабатывал бизнес приложения, и вроде (но не точно) работал в ibm. G>>Честно говоря я вообще не знаю чем ванс занимался до написания книги и есть и значимые проекты в его истории. После он начал заниматься консалтингом.
S>Я тоже не знаю. Но он как и Фаулер или дядя Боб -- что-то поделали в самом начале, потом решили лопаты продавать книги писать.
Товарищ Мартин свой опыт описывает во множестве книг, например он участвовал в разработке Rational Rose в IBM, где видимо и упорролся в "компонентность", что легло в основу его книги clean architecture. Фаулер не был выдающимся инженером, но он был "computer scientist" — изучал существующие методики, и придумывал новые, о чем очень много писал статей в доинтернетную эпоху. Он стоял у истоков Agile вместе с Беком и фактически ввел в обиход термин "рефакторинг".
А что касается Эванса — я вообще не нашел историю чем он занимался до книги и каких-то достижений после публикации тоже нет. Других книг он не выпускал.
Мне кажется что товарищ эванс вообще является подставным лицом, и DDD придумал Фаулер, но по причине неполного содержания книги, несвойственного Фаулеру, выпустил не под своим именем, а нашел соавтора.
S>>>В чем проблема найти компании и продукты у которых работает DDD? Спросите нейронку какую-нибудь. Наверняка что-то есть из докладов по ссылке выше. G>>Еще раз повторить аргумент про лженауки? У кого-то и астрология "работает". G>>Единственный способ доказать что что-то работает — провести эксперимент. Для ДДД это простой эксперимент — берем любой код с DDD, делаем эквивалентный без DDD и сравниваем объективные показатели — объем кода, количество связей между классами итд. G>>Важно взять именно работающий код, решающий задачу от начала до конца.
S>Мне это не интересно. Вам интересно, вы и делайте.
S>Я хочу донести мысль, что огульно выкидывать ДДД не стоит -- для кого-то на каких-то проектов он работает.
Это опять слепая вера. Если хотите сказать что DDD работает лучше чем нажимать рандомные кнопки на клавиатуре, то конечно работает. Как и любая методика проектирования и любые паттерны. Если мы говорим о применении конкретных паттернов, то появляются вопросы эффективности, но которые уже 20 лет нет ответа.
S>Я работал в компании, которая распиливала монолит на микросервисы по ДДД. Использовали стратегические паттерны.
Какие паттерны?
S>>>Он не про ORM и таблицы в бд. G>>А про что? S>101 раз говорю, что там все эти детали скрыты за паттерном Репозиторий. ДДД, кажется, не об этом.
А о чем тогда? Ну это смешно: как только в обсуждении DDD доходит до деталей, то "DDD не об этом". Что DDD в любой программе касается 10% не самого важного кода. Поэтому чтобы такие спекуляции исключить я и предлагаю взять пример, который от начала до конца работает.
G>>Меня интересует подход к проектированию от начала до конца, а не просто в какой-то части, делая вид что других не существует. S>Это подход к проектировании на основе проблем бизнеса, а не про орм или таблицы.
В результате ведь получается код, который рабоает с таблицами в БД и, вероятнее всего, с помощью ORM. Или нет?
S>>>Вероятно и у приложения будет один Bounded Context и один микросервис. Что не так? G>>Если order, line и product в одном агрегате, где root это order, то как получить список "лидеры продаж" с топ 30 товаров за месяц. S>Какой-то метод добавить в репозиторий, наверное.
Это тот самый репозитрий, который скрывает детали? То есть важнейшее требования — это "детали", которые надо "скрывать"?
И кто вызывать будет этот репозиторий?
S>>>Зависит от сложности. Ну найдите людей у которых все по DDD и поговорите с ними. Писать калькулятор по DDD странно, но какой-нибудь банковский софт, где требования регулярно меняются вполне может быть ок. Как обычно -- it depends. G>>См выше про эксперимент. Мнение интересует в последнюю очередь.
S>Сдается мне, на ООП языках вы стали писать без всяких экспериментов. На основе чьего-то мнения, скорее всего. И, наверное, до сих пор полет нормальный.
Я писать на ОО языках начал потому что выбора не было. Сейчас сложно найти мейнстримный язык без ООП, а когда я начинал таких вообще не было.
S>>>Если сохранять класс, когда у него все ок с инвариантами, то почему нет? G>>Потому что в рамках одного класса нельзя сделать контроль остатков. S>Почему?
По факту. Работа с объектами в памяти не обеспечивает изоляцию транзакций, когда есть более одного экземпляра процесса.
S>>>Для пользователя класса у него всегда должны быть инварианты, пользователь затем может этот класс сохранить. G>>Как описать инвариант: остаток товаров на складе должен быть не меньше суммы зарезервированных? S>Вычитать соотв. поля из бд, взяв соотв. лок предварительно, посчитать и в зависимости от, продолжить работу.
Два пользователя параллельно пытаются зарезервировать товар.
Один процесс считает данные из базы и считает предварительно. У него ок.
Второй процесс (на другом сервере) параллельно также считывает данные из базы и у него тоже ок.
Оба процесса создают резрвы товаров и сумма резервов получается больше остатка.
S>>>А как это может доказать обратное? Зачем вообще что-либо подсчитывать? G>>Затем что нужны объективные измеримые показатели преимуществ того или иного подхода: объем, цикломатическая сложность, вложенность вызовов. Иначе это вера, а не инженерный подход. S>См. выше про ООП -- что такое проделывали?
Конечно, я даже пример минимальный скидывал, который иллюстрирует преимущества. Любые подходы без ООП увеличивают объемы дублирующегося кода кода, при той же функцинальности.
S>Еще раз -- я не агитирую за ДДД, я против огульного откидывания подходов, мол "не нравится", "не встречал" и т.п. Это субъективщина. S>Наверняка можно найти человека с обратным опытом.
Так давайте найдем, пусть пример покажет. Мы же не только что прочитали про DDD, напомню что я уже 16ый год участвую в эти дискуссиях и пока НИ РАЗУ не увидел примера приложения, сделанного 100% по DDD, чтобы оно не содержало дублирования, множества лишних связей, проблем быстродействия и ошибок несогласованности данных.
Хорошее проектирование это не только здесь и сейчас, за что вы топите, но прежде всего и адеватный горизонт планирования. 
