Вроде как по теории лучше разрабатывать программу, используя 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. Хотя есть у меня нехорошее чувство... что любую светлую идею можно обосрать, механически разбив её на набор паттернов.

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