Вроде как по теории лучше разрабатывать программу, используя Domain-Driven-Design.
О необходимости Domain-model написано много книг.
На применение Domain-model заточены архитектуры типа "Чистая архитектура", "Гексагональная архитектура".

Как я понимаю, Domain-model работает с Сущностями и коллекциями сущностей.
Для хранения этих сущностей Domain-model использует Repository.

При этом часто встречаются задачи, когда нужно отобразить на форме список записей.
Удобным способом для этого являются объекты типа DataGridView, которые есть во многих средах разработки, особенно для десктопных приложений.
Однако, объекты типа DataGridView работают с табличными данными, и не умеют работать с коллекциями объектов.

Я просмотрел много обучающих примеров по DDD, и ни в одном из них нету работы с табличными данными.
И получается, что по сути использование DataGridView — противоречит DDD?
Так ли это? Действительно ли DDD и DataGridView не совместимы?

Можно ли придумать какой-то способ их совместного применения? Не нарушая при этом принципов DDD?

Хотелось бы написать хорошую программу, чтобы "ядром" этой программы являлась Domain-model, но чтобы при этом в пользовательском интерфейсе данные отображались с помощью DataGridView.
Если это возможно, то какая должна быть архитектура?
Как при этом должны взаимодействовать между собой слои программы?

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



Z>Я просмотрел много обучающих примеров по DDD, и ни в одном из них нету работы с табличными данными.
Z>И получается, что по сути использование DataGridView — противоречит DDD?
Z>Так ли это? Действительно ли DDD и DataGridView не совместимы?


Отчего же нет? вот https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/how-to-bind-objects-to-windows-forms-datagridview-controls?view=netframeworkdesktop-4.8

какой принцип тут нарушен?

Р>Отчего же нет? вот https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/how-to-bind-objects-to-windows-forms-datagridview-controls?view=netframeworkdesktop-4.8

Р>какой принцип тут нарушен?

Тут нарушать нечего. В этом простом примере нету ни бизнес-слоя, ни репозитория.
Давайте рассмотрим аналогичный пример, только который работает с базой данных.
Из базы данных Репозиторий извлекает данные в какой-нибудь RecordSet. А дальше что с ним делать, чтобы он попал в форму?

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


Z>Вроде как по теории лучше разрабатывать программу, используя Domain-Driven-Design.
Нет такой теории, это обман.

Z>О необходимости Domain-model написано много книг.
Это не делает подход правильным

Z>На применение Domain-model заточены архитектуры типа "Чистая архитектура", "Гексагональная архитектура".
Это тоже

Z>Как я понимаю, Domain-model работает с Сущностями и коллекциями сущностей.
Z>Для хранения этих сущностей Domain-model использует Repository.


Z>При этом часто встречаются задачи, когда нужно отобразить на форме список записей.
Z>Удобным способом для этого являются объекты типа DataGridView, которые есть во многих средах разработки, особенно для десктопных приложений.
Z>Однако, объекты типа DataGridView работают с табличными данными, и не умеют работать с коллекциями объектов.
Значит domain model не нужен, если задачи удобнее решать без него.

Z>Я просмотрел много обучающих примеров по DDD, и ни в одном из них нету работы с табличными данными.
Z>И получается, что по сути использование DataGridView — противоречит DDD?
Z>Так ли это? Действительно ли DDD и DataGridView не совместимы?
DDD (а именно паттерны) не совместимы со здравым смыслом.

Z>Можно ли придумать какой-то способ их совместного применения? Не нарушая при этом принципов DDD?
Нет

Z>Хотелось бы написать хорошую программу, чтобы "ядром" этой программы являлась Domain-model, но чтобы при этом в пользовательском интерфейсе данные отображались с помощью DataGridView.
Z>Если это возможно, то какая должна быть архитектура?
Z>Как при этом должны взаимодействовать между собой слои программы?
Только отказаться от DDD в тех местах где нужен грид.


На самом деле современные компоненты вполне успешно работают и с репозиториями, и с жирными моделями и прочими радостями из DDD, но без них все равно легче.

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


Р>>Отчего же нет? вот https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/how-to-bind-objects-to-windows-forms-datagridview-controls?view=netframeworkdesktop-4.8

Р>>какой принцип тут нарушен?

Z>Тут нарушать нечего. В этом простом примере нету ни бизнес-слоя, ни репозитория.
Z>Давайте рассмотрим аналогичный пример, только который работает с базой данных.
Z>Из базы данных Репозиторий извлекает данные в какой-нибудь RecordSet. А дальше что с ним делать, чтобы он попал в форму?

Так в примере как-раз и показано, что делать что бы он попал в форму.
Вариант 1 — создать на основе вашего RecordSet экземпляр BindingSource и передать его в DataGrid.
Вариант 2 — реализовать свою прослойку Адаптер между гридом и Репозиторием. Почитайте https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.datagridview.datasource?view=windowsdesktop-7.0#system-windows-forms-datagridview-datasource , какие интерфейсы для источников данных он поддерживает. Насколько я помню, больше всего возможностей будет если реализовать IBindingListView, но могу ошибаться.
Вариант 3 — сразу репозиторий реализовывать как IBindingListView или другой интерфейс поддерживаемый DataGrid. Но тут повышается связанность и в будущем может быть сложнее в поддержке, чем Адаптер.

BVA>Так в примере как-раз и показано, что делать что бы он попал в форму.

В примере показаны технические детали использования DataGridView.

Как формируются данные в слое бизнес-логики и затем передаются в DataGridView — этого нету в примере.

BVA>Вариант 1 — создать на основе вашего RecordSet экземпляр BindingSource ...
BVA>Вариант 2 — реализовать свою прослойку Адаптер между гридом и Репозиторием ...
BVA>Вариант 3 — сразу репозиторий реализовывать как IBindingListView или другой интерфейс поддерживаемый DataGrid...

Все эти варианты не используют бинес-логику.
А меня интересует именно как бизнес-логика получает данные от Репозитория, обрабатывает их, и возвращает в слой интерфейса для отображения.
По правилам, бизнес-логика не работает ни с RecordSet-ами ни с BindingSource-ами, ни с другими табличными данными. Она работает только со своими бизнес-сущностями.

Как тогда она сможет вернуть какой-то BindingSource, если она с ним в принципе не работает?

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

Z>>О необходимости Domain-model написано много книг.
G>Это не делает подход правильным

Z>>На применение Domain-model заточены архитектуры типа "Чистая архитектура", "Гексагональная архитектура".
G>Это тоже

G>DDD (а именно паттерны) не совместимы со здравым смыслом.

Как-то у вас все пессимистично получается.
Если Domain-Driven-Design — это обман, тогда что является правдой?

Я прочитал несколько книг про DDD, вроде бы там все соответствует здравому смыслу.
Можете порекомендовать что можно прочитать, чтобы увидеть нарушение здравого смысла в DDD?

Z>>При этом часто встречаются задачи, когда нужно отобразить на форме список записей.
Z>>Удобным способом для этого являются объекты типа DataGridView, которые есть во многих средах разработки, особенно для десктопных приложений.
Z>>Однако, объекты типа DataGridView работают с табличными данными, и не умеют работать с коллекциями объектов.
G>Значит domain model не нужен, если задачи удобнее решать без него.

На самом деле нужна работа и с отдельными бизнес-сущностями и с табличными данными, в которых представлены эти бизнес-сущности.
Получается, что domain model нам нужна.
Вопрос только в том, как ее совместить с работой с табличными данными.

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


Р>>Отчего же нет? вот https://learn.microsoft.com/en-us/dotnet/desktop/winforms/controls/how-to-bind-objects-to-windows-forms-datagridview-controls?view=netframeworkdesktop-4.8

Р>>какой принцип тут нарушен?

Z>Тут нарушать нечего. В этом простом примере нету ни бизнес-слоя, ни репозитория.
Z>Давайте рассмотрим аналогичный пример, только который работает с базой данных.
Z>Из базы данных Репозиторий извлекает данные в какой-нибудь RecordSet. А дальше что с ним делать, чтобы он попал в форму?
Можно реализовать шаблон
https://rsdn.org/article/patterns/ModelViewPresenter.xml

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

form.SetRecords(rs);

Р>Можно реализовать шаблон
Р>https://rsdn.org/article/patterns/ModelViewPresenter.xml

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

Р>

Р>form.SetRecords(rs);
Р>

Да, я читал эту статью.
Только я там не нашел работы с табличными данными.

Главный вопрос — откуда в Модели появятся эти табличные данные?
Модель — это ведь должна быть бизнес-логика. А по правилам DDD бизнес-логика работает только с бизнес-сущностями, а не с табличными данными.

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

Z>Главный вопрос — откуда в Модели появятся эти табличные данные?
Z>Модель — это ведь должна быть бизнес-логика. А по правилам DDD бизнес-логика работает только с бизнес-сущностями, а не с табличными данными.
Правила DDD мешают работать — вот и конфликт со здравым смыслом.
Чем быстрее DDD с пляжа, тем меньше сущностей мешает работать.

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


Z>Вроде как по теории лучше разрабатывать программу, используя Domain-Driven-Design.
Z>О необходимости Domain-model написано много книг.
Z>На применение Domain-model заточены архитектуры типа "Чистая архитектура", "Гексагональная архитектура".

Z>Как я понимаю, Domain-model работает с Сущностями и коллекциями сущностей.
Z>Для хранения этих сущностей Domain-model использует Repository.

Z>При этом часто встречаются задачи, когда нужно отобразить на форме список записей.
Z>Удобным способом для этого являются объекты типа DataGridView, которые есть во многих средах разработки, особенно для десктопных приложений.
Z>Однако, объекты типа DataGridView работают с табличными данными, и не умеют работать с коллекциями объектов.

Z>Я просмотрел много обучающих примеров по DDD, и ни в одном из них нету работы с табличными данными.
Z>И получается, что по сути использование DataGridView — противоречит DDD?
Z>Так ли это? Действительно ли DDD и DataGridView не совместимы?

Z>Можно ли придумать какой-то способ их совместного применения? Не нарушая при этом принципов DDD?

Z>Хотелось бы написать хорошую программу, чтобы "ядром" этой программы являлась Domain-model, но чтобы при этом в пользовательском интерфейсе данные отображались с помощью DataGridView.
Z>Если это возможно, то какая должна быть архитектура?
Z>Как при этом должны взаимодействовать между собой слои программы?

Если очень нужно то можно реализовать необходимые интерфейсы источников данных для DataGridView, но скорей всего будет проще использовать wpf c паттерном mvvm, DataGrid и свою реализацию INotifyCollectionChanged.
Вот собственная реализация этого интерфейса и будет работать с репозиторием или если надо с сетью

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


Р>>Можно реализовать шаблон
Р>>https://rsdn.org/article/patterns/ModelViewPresenter.xml

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

Р>>

Р>>form.SetRecords(rs);
Р>>

Z>Да, я читал эту статью.
Z>Только я там не нашел работы с табличными данными.

Z>Главный вопрос — откуда в Модели появятся эти табличные данные?
Z>Модель — это ведь должна быть бизнес-логика. А по правилам DDD бизнес-логика работает только с бизнес-сущностями, а не с табличными данными.

вы слишком теоретизируете. Посмотрите на ютубе Антон молдован. Он много про DDD рассуждает.

Q>Вот собственная реализация этого интерфейса и будет работать с репозиторием или если надо с сетью

Это все будет работать, не задействуя бизнес-логику.

Q> Если очень нужно то можно реализовать необходимые интерфейсы источников данных для DataGridView, но скорей всего будет проще использовать wpf c паттерном mvvm, DataGrid и свою реализацию INotifyCollectionChanged.

Как я понимаю, это всё технические "примочки", которые позволяют автоматизировать синхронизацию DataGridView и источника данных.
Но у меня вопрос не в этом. Синхронизацию можно сделать и вручную — не в этом проблема.

Смысл в том, чтобы в этой цепочке (от БД до UI) была задействована бизнес-логика.
А как ее задействовать, если она не работает с табличными данными по поределению?

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

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

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

G>Нет такой теории, это обман.
G>Это не делает подход правильным
G>Значит domain model не нужен, если задачи удобнее решать без него.

После такой отповеди я впервые прочитал про ДДД (слазив в Вики). Оказывается, я всю жизнь был ярым сторонником ДДД! Вот это, по-моему, неоспоримо:

Under domain-driven design, the structure and language of software code (class names, class methods, class variables) should match the business domain.

Специалисту по домену это облегчает врубание в код. А специалисту по кодированию это облегчает знакомство с доменом. Конечно, можно без этого, но выходит дольше, дороже и хуже. Везде, где я видел нарушение ДДД, повторюсь — ВЕЗДЕ, царила одна и та же безрадостная картина: на словах мы ненавидим тех, кто запутывает код, мы за рефакторинг, за простоту и понятность, а на деле запутываем код сами, чтобы не пускать в свой огород посторонних.

Z>>Можно ли придумать какой-то способ их совместного применения? Не нарушая при этом принципов DDD?
G>Нет

А по-моему, они естественным образом сочетаются друг с другом. Ведь не разрушится же ДДД от применения РСУБД? Нет, появится новый слой универсальности. Так же и тут. Декомпозиция просто переедет с уровня "class names, class methods, class variables" на уровень колонок.

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

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

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

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


Z>На самом деле нужна работа и с отдельными бизнес-сущностями и с табличными данными, в которых представлены эти бизнес-сущности.
Z>Получается, что domain model нам нужна.
Z>Вопрос только в том, как ее совместить с работой с табличными данными.
Значит не нужна. Работайте только с табличными данными. Современные orm позволяют это делать типизированно и обращаться к любому срезу

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

A>После такой отповеди я впервые прочитал про ДДД (слазив в Вики). Оказывается, я всю жизнь был ярым сторонником ДДД! Вот это, по-моему, неоспоримо:

A>

A>Under domain-driven design, the structure and language of software code (class names, class methods, class variables) should match the business domain.

Это примерно как "за все хорошее, против всего плохого".

Я не знаю ни одной методологии, в которой название классов, методов и переменных надо специально называть НЕ так как они называются в предметной области.

A>Специалисту по домену это облегчает врубание в код. А специалисту по кодированию это облегчает знакомство с доменом. Конечно, можно без этого, но выходит дольше, дороже и хуже. Везде, где я видел нарушение ДДД, повторюсь — ВЕЗДЕ, царила одна и та же безрадостная картина: на словах мы ненавидим тех, кто запутывает код, мы за рефакторинг, за простоту и понятность, а на деле запутываем код сами, чтобы не пускать в свой огород посторонних.
я видел такое безотносительно DDD. Был ужасночитаемый запутанный код как с DDD, так и без него.
Более того, по таким признакам я вообще не понимаю как отличить DDD от не-DDD. Возникает ощущение что все что хорошо работает это DDD, а что нет, то не оно.

Z>>>Можно ли придумать какой-то способ их совместного применения? Не нарушая при этом принципов DDD?
G>>Нет

A>А по-моему, они естественным образом сочетаются друг с другом. Ведь не разрушится же ДДД от применения РСУБД?
Конечно разрушится, потому что DDD это не только ubiquitous language (его и так используют все), но и набор паттернов — bounded context, repository, aggregate root, specification и еще куча более мелких, мало значимых.
На практике произвольный запрос ломает логику и архитектуру bounded context и aggregate root, а современные ORM делают ненужными и даже во многом лишними паттерны repository и specification. Даже сам подход к проектированию "жирных" объектов, содержащих как данные, так и логику ломается при попытке построить нетривиальные правила домена. Например в терминах объектной модели сложно выстроить правило: "премиальный покупатель, который является частным случаем обычного покупателя, имеет премиальную скидку, которая является частным случаем обычной скидки, на часть товаров". А в терминах запроса к БД это сделать элементарно — джоин таблиц покупателя и скидок по премиальности и джоин результата с таблицами товаров.

A>Нет, появится новый слой универсальности.
Конечно же не появится. Не получится правило из примера выше никак записать в виде "модели предметной области".

A>Так же и тут. Декомпозиция просто переедет с уровня "class names, class methods, class variables" на уровень колонок.
Я бы перестал ubiquitous language приравнивать к DDD.

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

A>>После такой отповеди я впервые прочитал про ДДД (слазив в Вики). Оказывается, я всю жизнь был ярым сторонником ДДД! Вот это, по-моему, неоспоримо:

A>>

A>>Under domain-driven design, the structure and language of software code (class names, class methods, class variables) should match the business domain.

G>Это примерно как "за все хорошее, против всего плохого".

G>Я не знаю ни одной методологии, в которой название классов, методов и переменных надо специально называть НЕ так как они называются в предметной области.

Это ж не так работает. Подробности см. у Дейла Карнеги. Никто не говорит про себя: я чмо, которое пишет запутанный код, чтобы почесать своё ЧСВ и при этом получить гарантии от увольнения. Нет. Говорят, что код — не запутанный, а "объективно сложный, с применением современных паттернов". Или ещё какую отмазку лепят. Тут ведь есть асимметрия: это чтобы держать код в понятном состоянии, надо прилагать усилия. А чтобы свалиться в свинство, достаточно этого не делать.

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

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

G>Более того, по таким признакам я вообще не понимаю как отличить DDD от не-DDD.

Сделать поиск по слову "helper"?

Z>>>>Можно ли придумать какой-то способ их совместного применения? Не нарушая при этом принципов DDD?
G>>>Нет

A>>А по-моему, они естественным образом сочетаются друг с другом. Ведь не разрушится же ДДД от применения РСУБД?
G>Конечно разрушится, потому что DDD это не только ubiquitous language (его и так используют все), но и набор паттернов — bounded context, repository, aggregate root, specification и еще куча более мелких, мало значимых.

Ладно, пойду читать. Про паттерны bounded context, repository, aggregate root и specification. Хотя есть у меня нехорошее чувство... что любую светлую идею можно обосрать, механически разбив её на набор паттернов.

А вообще, ТС задал ряд вопросов, из которых примерно понятно, над каким проектом он работает. Поэтому я исходил из соответствующих предположений. Возможно, некорректных.

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




G>>Я не знаю ни одной методологии, в которой название классов, методов и переменных надо специально называть НЕ так как они называются в предметной области.

A>Это ж не так работает. Подробности см. у Дейла Карнеги. Никто не говорит про себя: я чмо, которое пишет запутанный код, чтобы почесать своё ЧСВ и при этом получить гарантии от увольнения. Нет. Говорят, что код — не запутанный, а "объективно сложный, с применением современных паттернов". Или ещё какую отмазку лепят. Тут ведь есть асимметрия: это чтобы держать код в понятном состоянии, надо прилагать усилия. А чтобы свалиться в свинство, достаточно этого не делать.
Ты прям про DDD рассказываешь. А вообще эти идеи универсальны. Даже в физике есть закон неубывания энтропии (меры хаоса).

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


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

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

A>Ладно, пойду читать. Про паттерны bounded context, repository, aggregate root и specification. Хотя есть у меня нехорошее чувство... что любую светлую идею можно обосрать, механически разбив её на набор паттернов.
Довольно странно рассуждать о DDD, не понимая его сути. Для начала хотя бы раз эванса прочитать.

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

A>Ладно, пойду читать. Про паттерны bounded context, repository, aggregate root и specification. Хотя есть у меня нехорошее чувство... что любую светлую идею можно обосрать, механически разбив её на набор паттернов.

Почитал. Мне кажется, так и случилось. Объясните мне (пожалуйста), например, откуда взялись агрегаты как способ управления связностью. Идея доменного дизайна разве не в том, чтобы код был максимально соотнесён с предметной областью? То есть, чтобы не было лишних барьеров при переходе от чтения требований к чтению кода и обратно? И если да, разве не должна в этом случае связность (как и другие характеристики) быть объективно обусловлена предметной областью? Ей не надо управлять, ведь это исказит реальные связи между объектами!

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

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

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

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

Это опять результат того, что я не очень аккуратно написал. Дело не в считывании как таковом, а в том, что связи между "воин" — "визард" — "меч" — "посох" это, с моей точки зрения, ДАННЫЕ. Они должны создаваться отдельным редактором (который я, опять же, неаккуратно назвал "админкой") и загружаться движком. Их должно быть можно менять не-программистам, не меняя код. Данные такого типа, как я слышал, называют "ресурсы". А хардкодить ресурсы в классах движка (и вообще в коде) можно только от бедности. (Если посмотреть исходники старых игр, они любили БД с игровыми данными пихать прямо в Си в виде файла с дефайнами, но тогда же и железо другое было).

С одной стороны, это, конечно, моя вина, что я криво написал. А с другой стороны, я эту идею выразил достаточно чётко, можно было бы и не придираться к отдельным словам.

Мне вообще всё равно, как устроена сериализация (объект "считыватель карточек Х"), это малозначительный аспект кода. А вот когда я вижу класс Wizard, это для меня сразу красный свет. Кстати, многие в реальности так и проектируют, судя по всему. Например, редактор карт от Heroes 3 не позволяет создавать свои мечи и посохи (у каждого шмота в этой игре есть требования к персонажу, который может им владеть, но оно вообще составное, а некоторые его части — количественные). Он позволяет только выбрать из готовой коллекции и положить в заданное место или снабдить им игрока. Это, конечно, не значит, что сама коллекция у них обязательно прописана в коде. Может, в каком-то файле с данными лежит. Но вот то, что они её не вынесли на уровень редактора, это большая архитектурная ошибка. Мы бы до сих пор играли в Heroes 3... в смысле, ещё больше Была бы куча total conversions. Всё это неплохо окупается по оконцовке.

Если же ты имел в виду просто то, что "карточка персонажа" и "карточка предмета" — не ubiquitous language для RPG, то я не соглашусь. Люди играли в РПГ задолго до компьютеров, и многие настольные версии, насколько я знаю, не просто имели карточки, а карточки там были главными объектами, не считая многогранника ("кубика"). Ещё, насколько я читал, там были "мастера игры" — выделенные люди, которые "я, таки, не играю, я, таки, счёт веду". Может быть (это не точно, надо думать), что даже можно было бы назвать какой-нибудь класс GameMaster — и это тоже был бы ubiquitous language.

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

Класс сторонней библиотеки, разумеется. Называться он будет так, как его назовут разработчики облачного SDK. Даже если ты будешь писать его сам, не надо делать вид, что это всё ещё часть "софта для МРТ".

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

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

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

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

Это означает что на каком-то подмножестве относительно простых задач это возможно, а в общем — нет. Задача, которую нарисовал липперт, вроде достаточно простая, но уже на ней возникли сложности DDD.

И если быть честным, то DDD хорошо работает, как раз на простых задачах.

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

А каких вы знаете инженеров/архитекторов, которые создали реальную рабочую систему, и которые ведут блог на тему архитектуры?
Интересно было бы почитать.

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

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

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

G>Это означает что на каком-то подмножестве относительно простых задач это возможно, а в общем — нет.

Это означает, что я не могу доказать свою правоту за неразвитостью теории проектирования (и признаю это). Больше ничего.

И надо, наверно, подчеркнуть, что я не отстаиваю DDD в том виде, в котором в неё входят все эти агрегаты и прочие перечисленные паттерны. Только самый базовый принцип — код должен формулироваться в терминах предметной области.

>Задача, которую нарисовал липперт, вроде достаточно простая, но уже на ней возникли сложности DDD.

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

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

Так вот: отношения между мечом, посохом, магом и воином — это игровая логика. Она постоянно меняется — в целях достижения игрового баланса, например. Или чтобы тупо было интереснее играть. И во многих других случаях. Поэтому в реальном мире люди зачастую начинают писать одну игру, а заканчивают совсем другую. И это же распространяется и на софт класса... как он там его назвал?.. Papers and Paychecks. Просто "wizards and warriors are more fun to write about". Значицца, игровая логика в реальных проектах меняется постоянно. Как же так получается, что столь изменчивую вещь мы фиксируем настолько, что её аж должен ПРОВЕРЯТЬ КОМПИЛЯТОР, а проверок в рантайме недостаточно? Учитывая, насколько она изменчива по своей природе, её даже в рантайме проверять (выбрасывая исключения) не надо — как описали, так и описали, просто грузи, проверяй, и разрешай или запрещай персонажу взять предмет. По сути, это тоже самое, что заставить компилятор проверять, что у нас иконка прямоугольная.

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

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

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

A>Не понял вопрос. Можно процитировать код Липперта и ткнуть пальцем?
Можно, но не нужно. Это то место, где у него отношения между монстром, персонажем, оружием, локацией и фазой луны. Если об таком отношении написано в карточке, то в каком классе должно написать код чтения карточки, что бы не нарушить высокоуровневый принцип и у нас нет хелперов?

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

A>Так вот: отношения между мечом, посохом, магом и воином — это игровая логика. Она постоянно меняется — в целях достижения игрового баланса, например. Или чтобы тупо было интереснее играть. И во многих других случаях. Поэтому в реальном мире люди зачастую начинают писать одну игру, а заканчивают совсем другую. И это же распространяется и на софт класса... как он там его назвал?.. Papers and Paychecks. Просто "wizards and warriors are more fun to write about". Значицца, игровая логика в реальных проектах меняется постоянно. Как же так получается, что столь изменчивую вещь мы фиксируем настолько, что её аж должен ПРОВЕРЯТЬ КОМПИЛЯТОР, а проверок в рантайме недостаточно? Учитывая, насколько она изменчива по своей природе, её даже в рантайме проверять (выбрасывая исключения) не надо — как описали, так и описали, просто грузи, проверяй, и разрешай или запрещай персонажу взять предмет.

Логика меняется независимо от кода программы? Или все-таки логика это часть кода программы. Почему во втором случае не стараться сделать её проверяемой при компиляции?

A>По сути, это тоже самое, что заставить компилятор проверять, что у нас иконка прямоугольная.
Картинка это внешние данные, о которых компилятор не знает. Но после получения и валидации внешних данных и создания класса RectangularIcon весь остальной код может рассчитывать на то, что иконка прямоугольная. В этом и суть абстрации, ООП дает инструменты абстракции в виде классов.

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

A>>Так вот: отношения между мечом, посохом, магом и воином — это игровая логика. Она постоянно меняется — в целях достижения игрового баланса, например. Или чтобы тупо было интереснее играть. И во многих других случаях. Поэтому в реальном мире люди зачастую начинают писать одну игру, а заканчивают совсем другую. И это же распространяется и на софт класса... как он там его назвал?.. Papers and Paychecks. Просто "wizards and warriors are more fun to write about". Значицца, игровая логика в реальных проектах меняется постоянно. Как же так получается, что столь изменчивую вещь мы фиксируем настолько, что её аж должен ПРОВЕРЯТЬ КОМПИЛЯТОР, а проверок в рантайме недостаточно? Учитывая, насколько она изменчива по своей природе, её даже в рантайме проверять (выбрасывая исключения) не надо — как описали, так и описали, просто грузи, проверяй, и разрешай или запрещай персонажу взять предмет.

G>Логика меняется независимо от кода программы?

Именно так.

Представим себе, что тестировщики говорят перед релизом: какой-то слабый воин у нас получается. А маг имбовый. Если мы так всё и оставим, никто не будет играть за воина, только за мага. Дизайнеры думают: надо что-то поменять... а не разрешить ли ему брать и посох? Других отличий между ними хватает ведь. И что — им, чтобы проверить своё предположение, надо идти к программистам и просить изменений в код? Через тикеты в Джире? Представляешь, во что превратится такой процесс разработки?

Или — другой пример — как потом моддерам писать моды, если всё в код зашито? Для игр это тоже очень важно.

Слова "игровая логика" не должны сбивать с толку, потому что это с тем же успехом можно назвать "игровой дизайн".

Чтобы до этого додуматься, можно даже не работать в геймдеве, а просто поиграть в Heroes. Или в Dark Messiah of Might and Magic. Мне кажется, в этом и был корень ошибки — в магах и мечах тоже надо разбираться, прежде, чем приводить в пример. (При всём уважении!)

A>>По сути, это тоже самое, что заставить компилятор проверять, что у нас иконка прямоугольная.
G>Картинка это внешние данные, о которых компилятор не знает. Но после получения и валидации внешних данных и создания класса RectangularIcon весь остальной код может рассчитывать на то, что иконка прямоугольная. В этом и суть абстрации, ООП дает инструменты абстракции в виде классов.

Смысл сравнения с прямоугольной иконкой в том, что программе (объективно!) абсолютно начихать на её форму. Не начихать может быть менеджеру. Он может сказать: сейчас в моде прямоугольный дизайн, и поэтому рассматривайте форму иконки как бизнес-требование. А чтобы вам было легче рассматривать, давайте заставим компилятор её проверять. Технически это можно сделать — Post Build Steps, Continuous Integration, вся фигня — но разумно ли это?

Архитектор, по идее, должен понимать, какие идеи являются контрактами, которые надо закреплять в коде, а какие — нет.

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

A>Или — другой пример — как потом моддерам писать моды, если всё в код зашито? Для игр это тоже очень важно.

Может показаться, что НА САМОМ ДЕЛЕ это не очень важно. Вот компании Blizzard так однажды и показалось — и сегодня миллионы на DotA зарабатывает Valve. Но там, насколько я в курсе, проблемы были не с архитектурой, а с тупоголовыми менеджерами. Архитектура вполне позволяла изменять игровую логику после релиза (и без доступа к исходникам).

Counter-Strike, Team Fortress — это всё тоже когда-то начиналось как моды.

Благодаря открытой архитектуре Valve снизила нагрузку на собственные Left4Dead сервера (которые чистый убыток при фиксированной цене игры), потому что в ваниль сегодня всем скучно играть. Авторы модов поднимают свои сервера, и оплачивают их с донатов.

Моды — это, на самом деле, отрасль экономики с многомиллиардными оборотами.

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

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

A>>Не понял вопрос. Можно процитировать код Липперта и ткнуть пальцем?
S>Можно, но не нужно. Это то место, где у него отношения между монстром, персонажем, оружием, локацией и фазой луны. Если об таком отношении написано в карточке, то в каком классе должно написать код чтения карточки, что бы не нарушить высокоуровневый принцип и у нас нет хелперов?

Именно чтения? В классе сериализатора (например). Естественно, внешнего по отношению к нашему проекту.

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

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

S>>Можно, но не нужно. Это то место, где у него отношения между монстром, персонажем, оружием, локацией и фазой луны. Если об таком отношении написано в карточке, то в каком классе должно написать код чтения карточки, что бы не нарушить высокоуровневый принцип и у нас нет хелперов?

A>Именно чтения? В классе сериализатора (например). Естественно, внешнего по отношению к нашему проекту.
Могло бы быть отличным ходом, если бы внешний к нашему проекту проект умел бы обращаться с логикой нашего проекта. Но боюсь, если внешний проект начнет понимать, что такое оборотень, палладин и полнолуние, то это будет не такой уж и внешний проект. Внешний проект может дать нам XML, JSON или какое-то другое представление (табличное, например), далекое от сущностей нашего высокоуровневого дизайна. Все еще кому-то надо разобрать токены (или что там) представления карточки и вкорячить их в сущности нашего проекта, если мы хотим избежать того, что бы код нашего проекат бегал бы по представлению данных внешнего по отношению к нам проекта при обработке каждого действия/взаимодействия сущностей нашего проекта.
Кроме того, мне очень не понятно, почему сильная связность с внешним проектом лучше, чем связность с внутренним хелпером. Если бы это было действительно так, то все хелперы можно было бы размазать по "внешним" проектам и типа, этот говнокод не мой говнокод, у меня все высокоуровнево.

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

S>>>Можно, но не нужно. Это то место, где у него отношения между монстром, персонажем, оружием, локацией и фазой луны. Если об таком отношении написано в карточке, то в каком классе должно написать код чтения карточки, что бы не нарушить высокоуровневый принцип и у нас нет хелперов?

A>>Именно чтения? В классе сериализатора (например). Естественно, внешнего по отношению к нашему проекту.
S>Могло бы быть отличным ходом, если бы внешний к нашему проекту проект умел бы обращаться с логикой нашего проекта. Но боюсь, если внешний проект начнет понимать, что такое оборотень, палладин и полнолуние, то это будет не такой уж и внешний проект. Внешний проект может дать нам XML, JSON или какое-то другое представление (табличное, например), далекое от сущностей нашего высокоуровневого дизайна. Все еще кому-то надо разобрать токены (или что там) представления карточки

Я же спросил: "Именно чтения?". Чтобы отделить сериализацию от разбора давно придуманы способы типа SAX или построения DOM.

Если совсем просто: для сериализатора "possible_owners" и "wizard,warrior" это просто пара строк ключ-значение. А для класса предмета — это данные, на основе которых он вычисляет bool CanObtain().

Я другого не пойму: что вы все с этой сериализацией докопались до меня? Наличие классов Wizard и Warrior — это грубейшая ошибка проектирования, вызванная бездумной, механической, неудачной попыткой следовать принципу "Designing good class hierarchies is all about capturing the semantics of the business domain in the type system", а вопросы при этом задают мне и про сериализацию.

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

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

A>Я же спросил: "Именно чтения?". Чтобы отделить сериализацию от разбора давно придуманы способы типа SAX или построения DOM.

A>Если совсем просто: для сериализатора "possible_owners" и "wizard,warrior" это просто пара строк ключ-значение. А для класса предмета — это данные, на основе которых он вычисляет bool CanObtain().

A>Я другого не пойму: что вы все с этой сериализацией докопались до меня? Наличие классов Wizard и Warrior — это грубейшая ошибка проектирования, вызванная бездумной, механической, неудачной попыткой следовать принципу "Designing good class hierarchies is all about capturing the semantics of the business domain in the type system", а вопросы при этом задают мне и про сериализацию.

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

S>Я пытался понять, где же должен быть расположен "код считывания констрейнтов на оружие", если расположение его в "отдельном хелпере" нарушает "высокоуровневые принципы". Ну и походу выяснил, что вместо расположения кода в хелпере высокоуровневые принципы предпочитают DOM ...

DOM — это что такое?
Document Object Model?

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

S>>Я пытался понять, где же должен быть расположен "код считывания констрейнтов на оружие", если расположение его в "отдельном хелпере" нарушает "высокоуровневые принципы". Ну и походу выяснил, что вместо расположения кода в хелпере высокоуровневые принципы предпочитают DOM ...

Z>DOM — это что такое?
Z>Document Object Model?

Да. https://stackoverflow.com/questions/6828703/what-is-the-difference-between-sax-and-dom

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

S>А если взять правильный DOM, правильный редактор ресурсов и правильного непрограммиста, то и программисты с хелперами не нужны.

Абыдно, да?

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

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

Но в глубине души люди продолжают верить в сказки, и пишут статьи про ООП и DDD с мечами и магами.

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

Z>Если это возможно, то какая должна быть архитектура?
Z>Как при этом должны взаимодействовать между собой слои программы?
https://github.com/SamuelS00/todo-list-ddd/tree/main/src/%40core/src

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

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

S>>А если взять правильный DOM, правильный редактор ресурсов и правильного непрограммиста, то и программисты с хелперами не нужны.

A>Абыдно, да?
Кому? Я не занимаюсь моделированием поведения сущностей домена, т.к. не нахожу это полезным или интересным.

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

A>Поэтому, когда тебя приглашают в игровую студию в команду движка, никто не говорит, что тебя ждёт мир мечей и магии. Тебе говорят: увидишь своё имя в титрах, бесплатные котлетки с пюрешкой, и проездной на метро.

A>Но в глубине души люди продолжают верить в сказки, и пишут статьи про ООП и DDD с мечами и магами.
Не вижу ничего плохого в сказках. Статья не стала бы лучше, если бы в ней был пример на тему Студент.Учись, Поциент.Лечись, Штраф.Оплачивайся, Кредит.Возвращайся. Сказка здесь не в том, что в предметной области появились мечи и маги. А в том, что моделирование поведения сущностей доменной области в ООП и DDD имеет какой-то практический смысл в задачах, цель которых не заключается именно в моделировании поведения.

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

S>>>А если взять правильный DOM, правильный редактор ресурсов и правильного непрограммиста, то и программисты с хелперами не нужны.

A>>Абыдно, да?
S>Кому? Я не занимаюсь моделированием поведения сущностей домена, т.к. не нахожу это полезным или интересным.

За профессию. Потому, что ты всё правильно написал: никакие программисты с хелперами тут не нужны. И без хелперов не нужны. Для выстраивания отношений персонажей и шмота в рамках игры вообще не нужны программисты.

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

A>>Поэтому, когда тебя приглашают в игровую студию в команду движка, никто не говорит, что тебя ждёт мир мечей и магии. Тебе говорят: увидишь своё имя в титрах, бесплатные котлетки с пюрешкой, и проездной на метро.

A>>Но в глубине души люди продолжают верить в сказки, и пишут статьи про ООП и DDD с мечами и магами.
S>Не вижу ничего плохого в сказках. Статья не стала бы лучше, если бы в ней был пример на тему Студент.Учись, Поциент.Лечись, Штраф.Оплачивайся, Кредит.Возвращайся. Сказка здесь не в том, что в предметной области появились мечи и маги. А в том, что моделирование поведения сущностей доменной области в ООП и DDD имеет какой-то практический смысл в задачах, цель которых не заключается именно в моделировании поведения.

Я к тому, что мечи и маги это тоже работа. И в ней тоже надо думать. И решение часто оказывается очень скучным. А если погнаться за весёлым, оно именно поэтому может оказаться неверным (как и произошло). Это случается чаще, чем многие думают. Вон по соседству тряпку полощут — двадцать ответов уже, и ни одного правильного.

P.S. Если не гнаться за весельем, это, к сожалению, тоже не гарантирует правильных ответов. Что и доказывают примеры "Студент.Учись, Поциент.Лечись, Штраф.Оплачивайся, Кредит.Возвращайся" (не зная деталей, я бы, увидев такое, решил, что с вероятностью, близкой к единице, это ошибка проектирования).