Z>>Если Domain-Driven-Design — это обман, тогда что является правдой?
G>Практика — критерий истины. Все что помогает писать быстрее, писать меньше и совершать меньше ошибок — это хорошо, если не помогает — плохо.

Любая практика обощается, и таким образом формируется научное знание.
Вы можете привести ссылки\источники о подходах к посторению архитектуры, отличной от DDD?

Z>>Я прочитал несколько книг про DDD, вроде бы там все соответствует здравому смыслу.
G>Даже у Эванса с этим проблемы

Кокнретнее можете сказать в каких местах?
И желательно с указанием аргументов, а также других способов решения архитектурных проблем, более эффективных чем решения Эванса.
Иначе это пустые слова.

Z>>Можете порекомендовать что можно прочитать, чтобы увидеть нарушение здравого смысла в DDD?
G>Документации по использованию DataGridView не достаточно?
G>Почитайте еще про реляционную алгебру и оптимизацию запросов.

DataGridView, реляционная алгебра и оптимизация запросов никак не связаны и не касаются DDD.
Откуда там про нарушение зравого смысла в DDD?

G>Значит не нужна. Работайте только с табличными данными. Современные orm позволяют это делать типизированно и обращаться к любому срезу

У меня есть среда разработки (платформа), которая работает с реляционной БД.
Поменять ее я не могу. Надо построить хорошую архитекуру программы, кторая должна быть реализована на этой платформе, без ORM.
Можете порекомендовать какие-нибудь источники о построении хорошей архитектуры, отличной от DDD?

Р>где это сказано? Домен это сущность и операции над сущностями. Отображение это внешний слой. домен про него ничего не знает.

Не понял вопроса.

Еще раз сформулирую постановку проблемы.
Слой работы с БД возвращает табличные данные.
Слой Репозитория получает от БД табличыные данные и делает из табличных данных Сущности.
Слой Домена получается от Репозитория Сущности и Коллекции сущностей и работает с ними.

Слой Пользовательского интерфейса (UI) хочет получить табличные данные, он работает с Доменом. Но у Домена нету табличных данных. Домен может вернуть либо Сущсности либо ДТО.
Откуда UI возьмет эти табличные данные?

Здравствуйте, zelenprog, Вы писали:

Z>Еще раз сформулирую постановку проблемы.

Z>Слой Пользовательского интерфейса (UI) хочет получить табличные данные, он работает с Доменом. Но у Домена нету табличных данных. Домен может вернуть либо Сущсности либо ДТО.
Z>Откуда UI возьмет эти табличные данные?

Напишите для DataGridView источник данных — адаптер, который с одной стороны смотрит на сущности в репозитории, а с другой стороны выдаёт табличное представление этих сущностей. Вроде очевидно?

Z>>Слой Пользовательского интерфейса (UI) хочет получить табличные данные, он работает с Доменом. Но у Домена нету табличных данных. Домен может вернуть либо Сущсности либо ДТО.
Z>>Откуда UI возьмет эти табличные данные?

R>Напишите для DataGridView источник данных — адаптер, который с одной стороны смотрит на сущности в репозитории, а с другой стороны выдаёт табличное представление этих сущностей. Вроде очевидно?

Мне кажется, Пользовательский интерфейс (DataGridView) не должен обращаться к Репозиторию даже через Адаптер.
Пользовательский интерфейс работает ведь только с Бизнес-логикой.

Кроме того, даже если сделать такой Адаптер, то получится такой алгоритм обработки запроса табличных данных от UI:
— слой DB читает табличные данные, и отдает их Репозиторию
— Репозиторий делает из табличных данных Коллекцию
— Адаптер делает из Коллекции табличные данные
— UI получает табличные данные от Адаптера.

То есть выполняется двойное преобразование "табличные данные" — "коллекция" — "табличные данные".
Разве это хорошо?

Здравствуйте, zelenprog, Вы писали:


R>>Напишите для DataGridView источник данных — адаптер, который с одной стороны смотрит на сущности в репозитории, а с другой стороны выдаёт табличное представление этих сущностей. Вроде очевидно?

Z>Мне кажется, Пользовательский интерфейс (DataGridView) не должен обращаться к Репозиторию даже через Адаптер.
Z>Пользовательский интерфейс работает ведь только с Бизнес-логикой.

Бизнес-логика — это код типа "если клиент взял кредит и не вернул, новый кредит не выдавать". Как показывать список клиентов (списком, табличкой, деревом, в форме стихотворения), каким цветом подсвечивать клиентов, не вернувших кредит (коричневым, красным) — это всё не бизнес логика, а просто представление.

Z>Кроме того, даже если сделать такой Адаптер, то получится такой алгоритм обработки запроса табличных данных от UI:
Z>- слой DB читает табличные данные, и отдает их Репозиторию
Z>- Репозиторий делает из табличных данных Коллекцию
Z>- Адаптер делает из Коллекции табличные данные
Z>- UI получает табличные данные от Адаптера.

Z>То есть выполняется двойное преобразование "табличные данные" — "коллекция" — "табличные данные".
Z>Разве это хорошо?

А в чём проблема?

Здравствуйте, zelenprog, Вы писали:

Z>>>Если Domain-Driven-Design — это обман, тогда что является правдой?
G>>Практика — критерий истины. Все что помогает писать быстрее, писать меньше и совершать меньше ошибок — это хорошо, если не помогает — плохо.

Z>Любая практика обощается, и таким образом формируется научное знание.
Спорное заявление.
Во-первых задачи разные: системное ПО, геймдев, корпоративные приложения, хайлоад сайты, мобилки, встраиваемый софт, САПР и АСУТП — разные задачи, разные технологии, и, соответственно, разные архитектуры.
Во-вторых технологии меняются. Если раньше запросы к базе выпиливали ручками, то теперь все делается через ORM. Для UI сначала был MVС, потом MVP, потом MVVM, а сейчас уже не знаю что.

Z>Вы можете привести ссылки\источники о подходах к посторению архитектуры, отличной от DDD?
По причинам указанным выше одной книни на все времена и все задачи быть не может.
Есть общие принципы архитектуры программ, которые или вообще не меняются или меняются редко.

Базовые принципы можно почерпнуть из книг:
1) "Pragmatic Programmer" Ханта и Томаса (не все релевантно, так как многое опирается на уже устаревшие технологии)
2) "Жемчужины программирования" Бентли
3) SICP первые 3 главы (можно и все, но порвет мозг)

Подход к процессу проектирования описан в книгах:
4) "Мифический человеко-месяц" Брукса
5) "Design of Design" Брукса (сложная книга)

Стандартные приемы в книгах:
6) Паттерны проектирования Банды Четрех
7) Рефакторинг Фаулера
8) Refactoring to Pattern Дж. Криевски (без этой книги предыдущие две не сильно нужны)
9) Code complete МакКоннелла (много буллшита, не стоит все принимать на веру)
10) Clean Code Роберта Мартина (много буллшита, не стоит все принимать на веру)

Для корпоративных и веб-приложений могут пригодится следующие книги:
11) "Базы данных, полный курс" Гарсиа-Молина
12) RFC 9110 HTTP Semantics https://www.rfc-editor.org/rfc/rfc9110
12) "Программирование высоконагруженных систем" Клеппмана

И обязательно, перед тем как делать что-то: читать документацию и примеры к фреймворку, на котором вы будете работать, документация к СУБД, с которой вы будете работать и вообще документацию всех программ и компонентов, с которыми вам надо будет взаимодействовать.

Только после всего выше можно прочитать фаулера и эванса.


Z>>>Я прочитал несколько книг про DDD, вроде бы там все соответствует здравому смыслу.
G>>Даже у Эванса с этим проблемы

Z>Кокнретнее можете сказать в каких местах?
Например в месте где указана мотивация к паттерну Aggregate Root.

Z>И желательно с указанием аргументов, а также других способов решения архитектурных проблем, более эффективных чем решения Эванса.
Аргумент простой — не за чем тянуть весь aggregate root если тебе нужно только два поля. Уже после написания книги придумали даже read-модели, чтобы от этой проблемы избавиться. А можно не создавать жирную модель, aggregate roots и проблемы не будет вовсе.

Z>Иначе это пустые слова.
"Пустые слова" это хорошее описание попыток "придумать" архитектуру приложений.
Почитайте еще "Жизнь внутри пузыря" Ашманова, он там по полочкам разложил модную в то время "Общую шину", сейчас он бы мог написать почти то же самое про микросервисную архитектуру, большие данные и блокчейн.


Z>>>Можете порекомендовать что можно прочитать, чтобы увидеть нарушение здравого смысла в DDD?
G>>Документации по использованию DataGridView не достаточно?
G>>Почитайте еще про реляционную алгебру и оптимизацию запросов.

Z>DataGridView, реляционная алгебра и оптимизация запросов никак не связаны и не касаются DDD.
Z>Откуда там про нарушение зравого смысла в DDD?
DDD прямо отрицает РА и язык запросов. Предлагает делать вам структуру классов, делая вид что они все в памяти приложения находятся, а потом делать aggregate root, которые реально в память загружают подграф объектов, чтобы с ним работать.
В таком случае не то что об оптимизации запросов, о скорости какой-либо речи не идет.


G>>Значит не нужна. Работайте только с табличными данными. Современные orm позволяют это делать типизированно и обращаться к любому срезу

Z>У меня есть среда разработки (платформа), которая работает с реляционной БД.
Это какая?

Z>Поменять ее я не могу. Надо построить хорошую архитекуру программы, кторая должна быть реализована на этой платформе, без ORM.
В плафторме можно сделать запрос к БД? Если можно, то просто напишите код, который нужный запрос делает. Потом напишите код, который делает второй нужный запрос, далее третий и так далее.
Когда увидите что части кода повторяются — делайте рефакторинг, выносите части в общие функции. Далее функции, которые работают вместе выделяйте, в классы.
А вообще к любой "платформе" должен идти подробный гайд как писать код на этой платформе.

Z>Можете порекомендовать какие-нибудь источники о построении хорошей архитектуры, отличной от DDD?
Выше список, которого вам хватит надолго.

Здравствуйте, zelenprog, Вы писали:

Р>>где это сказано? Домен это сущность и операции над сущностями. Отображение это внешний слой. домен про него ничего не знает.

Z>Не понял вопроса.

Z>Еще раз сформулирую постановку проблемы.
Z>Слой работы с БД возвращает табличные данные.
Z>Слой Репозитория получает от БД табличыные данные и делает из табличных данных Сущности.
Z>Слой Домена получается от Репозитория Сущности и Коллекции сущностей и работает с ними.

Z>Слой Пользовательского интерфейса (UI) хочет получить табличные данные, он работает с Доменом. Но у Домена нету табличных данных. Домен может вернуть либо Сущсности либо ДТО.
Z>Откуда UI возьмет эти табличные данные?

у домена должна быть операция(функция) преобразующая сущность в удобное для UI представление.

Вот рабочий пример: https://github.com/AntyaDev/Talks/blob/8397dfc85e5763c7f2349fae210b767af75bec10/2017/tdd_on_F%23/src/Basket.Domain/Domain.fs#L102

Здравствуйте, zelenprog, Вы писали:

Р>>где это сказано? Домен это сущность и операции над сущностями. Отображение это внешний слой. домен про него ничего не знает.

Z>Не понял вопроса.

Z>Еще раз сформулирую постановку проблемы.
Z>Слой работы с БД возвращает табличные данные.
Z>Слой Репозитория получает от БД табличыные данные и делает из табличных данных Сущности.
Z>Слой Домена получается от Репозитория Сущности и Коллекции сущностей и работает с ними.

Z>Слой Пользовательского интерфейса (UI) хочет получить табличные данные, он работает с Доменом. Но у Домена нету табличных данных. Домен может вернуть либо Сущсности либо ДТО.
Z>Откуда UI возьмет эти табличные данные?
да, и что есть табличные данные?
datagridview обычно либо работает с любым типом списков, либо предоставляет интерфейс для коллекции. есть конечно нюансы в зависимости от используемых технологий.
в C# например, нужно чтобы это объекты предоставляли свойства, простые публичные поля насколько помню он не воспринимает, что в winforms, что в wpf.
в java swing там просто представляется класс которой по индексу возвращает значения столбцов. но сам класс в качестве источника данных может использовать любой контейнер,
от массива до чего угодно.
Покажите возможности своего грида, может будет яснее в чем затык.

Здравствуйте, gandjustas, Вы писали:

G>А вообще эти идеи универсальны. Даже в физике есть закон неубывания энтропии (меры хаоса).

Универсальны, да.

Хорошие идеи все универсальны. Я вообще удивляюсь, что простую идею следовать понятиям пользователя раскрутили до методологии (и заодно запутали). В наше-то время это называлось попросту "умеет в ООП"/"умеет в структуры".

A>>Поэтому не нужна никакая методология "в которой название классов, методов и переменных надо специально называть НЕ так как они называются в предметной области". Достаточно не следовать методологии, в которой за этим надо следить. Остальное случится само.
G>Это как? рандомно нажимать символы на клавиатуре пока тесты не станут зелеными? Или вы думаете что до эванса с фаулером никто не догадался давать имена в коде терминами предметной области?

Тут у нас какое-то недопонимание, видимо. Я пишу, что если не выжигать калёным железом все эти -Helper, Utils:: и т.д., они нарастают и зОхватывают проект. Вопрос "как" в связи с этим кажется мне немного надуманным Как-как, от нежелания/неумения думать и проектировать. К которому примешиваются нежелание признавать ошибки ("зря мы тут сделали фабрику-синглтон, Петрович!") и шкурные интересы сохранить код запутанным.

Кстати, пока читал про ДДД, наткнулся на анекдот. На конференции гость просит поднять руки тех, кто практикует ДДД. А потом просит опустить тех, у кого есть хоть один класс, заканчивающийся на Helper.

Ещё ситуацию осложняет то, что тут нет и не может быть чисто формальных критериев. Например, MRITask может быть полезной вещью, если докторишки действительно мыслят в таких терминах. А может и наоборот.

G>Интересно, если бы была та же самая мешанина, но методом "просветить" в классе MRI — стало бы лучше? Или опять рассуждения на уровне "если все понятно и хорошо работает, то это DDD, а если нет, то нет"?

Она бы перестала быть мешаниной. Можно было бы посмотреть на перечень методов, и узнать, что аппарат умеет делать по нашей просьбе. Умеет он просветить или нет, и как это правильно называется. Так достаточно конкретно?

G>Найди в интернете нетривиальные примеры кода, которые заявляют что они по DDD и там ты обязательно найдешь helper\manager\service классы. Более того у эванса описан "паттерн" domain service, который как раз призван ответить на вопрос куда поместить логику, оперирующую более чем двумя сущностями.

Он зарегистрировал торговую марку "DDD"? Если нет, какая разница, что он там пишет. Следовать надо здравому смыслу, а не авторитетам. Пока я читал про то, что структура классов должна отражать предметную область, я был согласен. Как речь зашла про агрегаты, так симпатии у меня поубавилось.

Только не надо говорить, что это рассуждения общего уровня. Это вполне себе конкретика. Есть порыться в анналах РСДН, тут полно споров на эту тему. Например, если в бухгалтерии всё сделано на проводках (не на хранении состояния), надо или нет писать класс счёта, который суммировал бы операции.

Р>у домена должна быть операция(функция) преобразующая сущность в удобное для UI представление.

Нельзя так делать.
Домен не должен ничего знать про UI и представление, и про типы данных, которые используются в UI.
Значит, он и преобразовать ничего не может.
Домен возвращает данные в "своих" данных, а преобразованием к виду UI занимается View (или Презентер или еще что-то).

Здравствуйте, zelenprog, Вы писали:


Р>>у домена должна быть операция(функция) преобразующая сущность в удобное для UI представление.

Z>Нельзя так делать.
Z>Домен не должен ничего знать про UI и представление, и про типы данных, которые используются в UI.
Z>Значит, он и преобразовать ничего не может.
Z>Домен возвращает данные в "своих" данных, а преобразованием к виду UI занимается View (или Презентер или еще что-то).
он и не знает, только предоставляет view. Я пример вам привел, можно конечно и так, суть ddd это не меняет.
что с вашим датагридом, какой-то он особенный

Здравствуйте, Alekzander, Вы писали:


A>Тут у нас какое-то недопонимание, видимо. Я пишу, что если не выжигать калёным железом все эти -Helper, Utils:: и т.д., они нарастают и зОхватывают проект. Вопрос "как" в связи с этим кажется мне немного надуманным Как-как, от нежелания/неумения думать и проектировать. К которому примешиваются нежелание признавать ошибки ("зря мы тут сделали фабрику-синглтон, Петрович!") и шкурные интересы сохранить код запутанным.
Вопрос в именовании или в самом наличии таких классов-сервисов, используемых только для реализации конкретного сценария?



G>>Интересно, если бы была та же самая мешанина, но методом "просветить" в классе MRI — стало бы лучше? Или опять рассуждения на уровне "если все понятно и хорошо работает, то это DDD, а если нет, то нет"?
A>Она бы перестала быть мешаниной.
За счет именования?

A>Можно было бы посмотреть на перечень методов, и узнать, что аппарат умеет делать по нашей просьбе. Умеет он просветить или нет, и как это правильно называется. Так достаточно конкретно?
Как наличие классов и методов с определенными названиями связано с запутанностью кода?
Что-то мне кажется что примерно никак.

G>>Найди в интернете нетривиальные примеры кода, которые заявляют что они по DDD и там ты обязательно найдешь helper\manager\service классы. Более того у эванса описан "паттерн" domain service, который как раз призван ответить на вопрос куда поместить логику, оперирующую более чем двумя сущностями.
A>Он зарегистрировал торговую марку "DDD"? Если нет, какая разница, что он там пишет.
Если его цитируют, то разница есть, и довольно большая. Вопрос юридической принадлежности "DDD" тут ортогонален.

A>Следовать надо здравому смыслу, а не авторитетам.
Это универсальный совет, только здравый смысл это самая тонкая материя во вселенной. Здравый смысл должен из практики происходить, а не из популярной литературы или видео.

A>Пока я читал про то, что структура классов должна отражать предметную область, я был согласен. Как речь зашла про агрегаты, так симпатии у меня поубавилось.
Да и "структура должна отражать предметную область" далеко не для всех задач подойдет.
Недавно переводит статьи Липперта на эту тему https://habr.com/ru/articles/710748/
Он не такой авторитет как фаулер с эвансами, толстых книг, которые читали все программисты не писал, но разбирается в архитектуре не хуже их вместе взятых.

Здравствуйте, gandjustas, Вы писали:

G>Вопрос в именовании или в самом наличии таких классов-сервисов, используемых только для реализации конкретного сценария?

Я не любитель философии в стиле сам знаешь кого, но по-другому на твой вопрос не ответишь. Надеюсь, я буду услышан и понят правильно.

Люди понимают, что глупо обсуждать детали вечного двигателя (есть закон сохранения). Люди понимают, что нельзя собрать универсальный вычислитель на регэксах (регэксы не Тьюринг-полные). А вот про такие вопросы люди не понимают. Но я объясню. Есть творческие процессы, справиться с которыми могут только люди и сильный ИИ (когда мы его построим, а будет это нескоро). И никакой шахер-махер вокруг них не поможет, как не поможет он обойти фундаментальные запреты в других научных областях.

Проектирование — это творческий процесс. Его в принципе нельзя механически формализовать. Если было бы можно, уже давно бы написали алгоритм, который проектировал вместо нас. То, что я пошутил про поиск слова "helper" (и гость пошутил про это же на конференции) — так это работает только протому, что люди сами понимают, что делают каку. И добровольно её маркируют. Ещё можно писать в коде "HACK:" (очень старое соглашение), но это же не значит, что можно напустить анализатор на код, и он тебе покажет все хелперы и хаки.

А ты просишь у меня именно формального критерия. Что я тебе могу ответить? Конечно же, не в названии дело. И не в том, в каком количестве сценариев (один сценарий, два сценария, много сценариев) используется класс. А в том, что при проектировании складывается ситуация, когда функционал надо куда-то добавить, а куда — неясно. И его добавляют куда попало. Это *строгое* определение хелпера, просто оно относится к творческому процессу, а его нельзя механически раздробить на критерии. Если это удивляет, возьми второе начало термодинамики. Оно тоже строгое, но при этом весьма высокоуровневое, и не поддаётся редукции — что признают сами физики.

При этом важно то, что если подумать, всегда можно переписать код так, что хелперы исчезнут. Останутся только классы, отражающие предметную область. Функционал будет в них, и код станет гораздо лучше организован.

Остальное в этом посте строится по этой же схеме, поэтому ограничусь вышенаписанным.

G>>>Интересно, если бы была та же самая мешанина, но методом "просветить" в классе MRI — стало бы лучше? Или опять рассуждения на уровне "если все понятно и хорошо работает, то это DDD, а если нет, то нет"?
A>>Она бы перестала быть мешаниной.
G>За счет именования?

A>>Можно было бы посмотреть на перечень методов, и узнать, что аппарат умеет делать по нашей просьбе. Умеет он просветить или нет, и как это правильно называется. Так достаточно конкретно?
G>Как наличие классов и методов с определенными названиями связано с запутанностью кода?
G>Что-то мне кажется что примерно никак.

G>>>Найди в интернете нетривиальные примеры кода, которые заявляют что они по DDD и там ты обязательно найдешь helper\manager\service классы. Более того у эванса описан "паттерн" domain service, который как раз призван ответить на вопрос куда поместить логику, оперирующую более чем двумя сущностями.
A>>Он зарегистрировал торговую марку "DDD"? Если нет, какая разница, что он там пишет.
G>Если его цитируют, то разница есть, и довольно большая. Вопрос юридической принадлежности "DDD" тут ортогонален.

A>>Следовать надо здравому смыслу, а не авторитетам.
G>Это универсальный совет, только здравый смысл это самая тонкая материя во вселенной. Здравый смысл должен из практики происходить, а не из популярной литературы или видео.

***

Отдельно про это:

A>>Пока я читал про то, что структура классов должна отражать предметную область, я был согласен. Как речь зашла про агрегаты, так симпатии у меня поубавилось.
G>Да и "структура должна отражать предметную область" далеко не для всех задач подойдет.
G>Недавно переводит статьи Липперта на эту тему https://habr.com/ru/articles/710748/
G>Он не такой авторитет как фаулер с эвансами, толстых книг, которые читали все программисты не писал, но разбирается в архитектуре не хуже их вместе взятых.

Ой, как раз Липперта-то я очень сильно уважаю! Он офигенно ясно мыслит. Так что почитаю обязательно, спасибо большое! И если будет, что ответить применительно к этой теме — отпишусь.

Здравствуйте, Alekzander, Вы писали:

A>При этом важно то, что если подумать, всегда можно переписать код так, что хелперы исчезнут. Останутся только классы, отражающие предметную область. Функционал будет в них, и код станет гораздо лучше организован.
И это неправда. Если у тебя функция оперирует более чем с двумя сущностями, то велика вероятность, что ты не сможешь адекватно разместить эту функцию в одном из них. Это даже Эванс понимал и в DDD-паттерны включил domain service.
Липперт в своих статьях тоже наглядно показал ограничение ОО-дизайна.

Поэтому конечно можно объявить войну всем хелперам и считать это чем-то хорошим, но это не сделает в итоге код менее запутанным. Возможно сделает его даже более запутанным. Или просто хелперы переименуют во что-то другое.

Здравствуйте, gandjustas, Вы писали:

G>Недавно переводит статьи Липперта на эту тему https://habr.com/ru/articles/710748/
G>Он не такой авторитет как фаулер с эвансами, толстых книг, которые читали все программисты не писал, но разбирается в архитектуре не хуже их вместе взятых.

Я, наконец, прочитал эту длинную статью. Не то, чтобы я медленно читал, а просто ещё приходится отвлекаться на всякие глупости (типа работы). Плюс тебе в карму, а плюс за перевод самой статьи не могу поставить (она истекла).

Это отличная иллюстрация к тому, что я написал выше.

Дураку понятно, что в реальном проекте надо писать админку с карточками игроков и оружия, а констрейнты — кто кого может иметь и куда — считывать из файлов, приготовленных гейм-дизайнерами (как и всё остальное).

Откуда же берётся такое г-но, описанное Липпертом?

Да вот оттуда и берётся. Когда, допустим, я говорю: в хорошем коде отражается предметная область. А, допустим, ты говоришь: это бла-бла-бла, гони конкретику. Допустим, я не понимаю, что не каждый фундаментальный принцип — такой, как доменной дизайн или второе начало термодинамики — можно свести к набору более простых правил (это свойство называется "эмерджентность"), и чтобы хоть что-то тебе ответить, говорю: выпиши в блокнот игровые понятия и проследи, чтобы каждому соответствовал хоть какой-то сишарповский класс. И вот результат.

К счастью, это был просто пример. А реальный я скажу тебе, что нет таких приёмов, которые можно применять не думая, чтобы обеспечить выполнение этого принципа (почему — я уже объяснил: это запрет, налагаемый законами природы на творческие процессы). А если делать это думая, то указанный принцип должен быть воплощён в форме класса, который считывает приготовленные карточки. Потому, что именно так НА САМОМ ДЕЛЕ устроена предметная область. И несмотря на высокоуровневость этого принципа, смысл в нём есть. Например, если ты напишешь код считывания констрейнтов на оружие в отдельном хелпере — ты его нарушишь.

Здравствуйте, Alekzander, Вы писали:

A>Дураку понятно, что в реальном проекте надо писать админку с карточками игроков и оружия, а констрейнты — кто кого может иметь и куда — считывать из файлов, приготовленных гейм-дизайнерами (как и всё остальное).

A>Откуда же берётся такое г-но, описанное Липпертом?
Чую, напали на след. Скоро разберемся.

A>Да вот оттуда и берётся. Когда, допустим, я говорю: в хорошем коде отражается предметная область. А, допустим, ты говоришь: это бла-бла-бла, гони конкретику. Допустим, я не понимаю, что не каждый фундаментальный принцип — такой, как доменной дизайн или второе начало термодинамики — можно свести к набору более простых правил (это свойство называется "эмерджентность"), и чтобы хоть что-то тебе ответить, говорю: выпиши в блокнот игровые понятия и проследи, чтобы каждому соответствовал хоть какой-то сишарповский класс. И вот результат.
Отличная идея для автоматического преобразования любого говнокода + набора понятий в DDD архитектуру путем создания класса для каждого понятия.

A>К счастью, это был просто пример. А реальный я скажу тебе, что нет таких приёмов, которые можно применять не думая, чтобы обеспечить выполнение этого принципа (почему — я уже объяснил: это запрет, налагаемый законами природы на творческие процессы). А если делать это думая, то указанный принцип должен быть воплощён в форме класса, который считывает приготовленные карточки. Потому, что именно так НА САМОМ ДЕЛЕ устроена предметная область. И несмотря на высокоуровневость этого принципа, смысл в нём есть. Например, если ты напишешь код считывания констрейнтов на оружие в отдельном хелпере — ты его нарушишь.
Хорошо, а если подумать, то где должен быть расположен код считывания карточки, выполняющей функцию мультиметода, как у Липперта? В оружии? А если в карточке полнолуние, палладин и оборотень... что ли? Нужно ли код считыванияя располагать в классе полнолуния? А код считывания карточки с полуночью в классе полуночи или в классе тыквы?

Здравствуйте, gandjustas, Вы писали:

Z>>Если Domain-Driven-Design — это обман, тогда что является правдой?
G>Практика — критерий истины. Все что помогает писать быстрее, писать меньше и совершать меньше ошибок — это хорошо, если не помогает — плохо.

Я в свое время пытался найти, чем известен или чего достиг Эванс, помимо своей книги. Ничего не смог найти. А раз так, блог инженера/архитектора создавшего реальную рабочую систему имеет в разы большую ценность.

Здравствуйте, Alekzander, Вы писали:

A>Откуда же берётся такое г-но, описанное Липпертом?

A>Да вот оттуда и берётся. Когда, допустим, я говорю: в хорошем коде отражается предметная область. А, допустим, ты говоришь: это бла-бла-бла, гони конкретику. Допустим, я не понимаю, что не каждый фундаментальный принцип — такой, как доменной дизайн или второе начало термодинамики — можно свести к набору более простых правил (это свойство называется "эмерджентность"), и чтобы хоть что-то тебе ответить, говорю: выпиши в блокнот игровые понятия и проследи, чтобы каждому соответствовал хоть какой-то сишарповский класс. И вот результат.

A>К счастью, это был просто пример. А реальный я скажу тебе, что нет таких приёмов, которые можно применять не думая, чтобы обеспечить выполнение этого принципа (почему — я уже объяснил: это запрет, налагаемый законами природы на творческие процессы). А если делать это думая, то указанный принцип должен быть воплощён в форме класса, который считывает приготовленные карточки. Потому, что именно так НА САМОМ ДЕЛЕ устроена предметная область. И несмотря на высокоуровневость этого принципа, смысл в нём есть. Например, если ты напишешь код считывания констрейнтов на оружие в отдельном хелпере — ты его нарушишь.

То есть у нас появился объект "считыватель карточек Х", где Х — термин предметной области, так? Это ведь уже не совсем ubiquitous language, про который говорит DDD.

Продолжаем мысленный эксперимент с софтом для МРТ. Предположим у нас не просто аппарат, а целая система, когда аппарат снимки на сервер сохраняет, а компьютер у врача, возможно совершенно в другому месте, отображает. Так вот по этой логике какой класс должен заниматься сохранением карточек\файлов МРТ на сервере и их считыванием на клиенте?

Здравствуйте, gandjustas, Вы писали:

A>>При этом важно то, что если подумать, всегда можно переписать код так, что хелперы исчезнут. Останутся только классы, отражающие предметную область. Функционал будет в них, и код станет гораздо лучше организован.
G>И это неправда.

Это я поленился уточнить: "эмпирическое утверждение по моим наблюдениям". У меня нет теории, из которой бы следовало, что это гарантировано возможно, а просто всегда как-то получалось. Ну и если посмотреть, например, на API крупных продуктов (всяких ОС), на стандартные библиотеки известных ЯП — то как-то и им это удаётся, что косвенно подтверждает. Это я объяснил, почему так считаю, обосновать я не могу.

Здравствуйте, samius, Вы писали:

S>Хорошо, а если подумать, то где должен быть расположен код считывания карточки, выполняющей функцию мультиметода, как у Липперта? В оружии?

Не понял вопрос. Можно процитировать код Липперта и ткнуть пальцем?