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

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

G>>Что там является "моделью предметной области", в чем её ценность, и как она влияет на остальные части кода?
S>Ну как минимум https://github.com/gandjustas/habr-post-stock-api/blob/main/Model.cs
То есть "модель предметной области" это типизированное описание схемы БД, так?
Апологеты DDD как раз с этим спорят.




S>>>А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями?
G>>1) Уменьшает дублирование кода
G>>2) Уменьшает количество связей и сайд-эффектов
G>>3) Уменьшает цепочку вызовов и количество промежуточных слоев между вызовов и действием
G>>4) Увеличивает быстродействие
G>>5) Уменьшает неявную передачу данных и изменение стояния
G>>Это все вещи связанные, но в некоторых местах могут противоречить друг другу, поэтому хороший код это баланс.

S>Ну т.е. код ради кода, понятно. Ну вот есть хороший код, который плохо решает поставленную задачу, поскольку автор толком не разобрался в предметной области. Ну и какой прок от этой программы кроме эстетики кода?
А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи?
И кто сказал что наличие "объектов доменной модели" автоматически приводит к хорошему решению задачи?


S>Ну и самый главный вопрос, а как всему вышеперечисленному мешает оперирование объектами доменной модели?
Никак не мешает и никак не помогает. Хотя зависит от того, что входит в понятие "оперирование объектами доменной модели", так как это может давать ограничения
Например код вида

ctx.Stock.Where(s => s.Wharehouse == id).ExecuteUpdate(x => x.SetProperty(s => s.Quantity, s => s.Quantity - s.Reserved).x.SetProperty(s => s.Reserved, 0))

Является "оперированием объектами доменной модели"?

S>>>По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде.
G>>Вы как-то слишком широко применяете слово "абстракция". Когда вы создаете класс с набором свойств это не абстракция. Реализация интерфейса это тоже не абстракция. Абстракция это то, что использует такие классы или интерфейсы. А писать такой код нет необходимости. Большинство полезных абстракций уже есть в библиотеках, зачастую стандартных.

S>Делаю какой-нибудь реалистичны автотренажер или игру для машин, есть в стандартной библиотеке класс автомобиль, мотор и т.п.?
Мы тут вроде как корпоративные приложения рассматриваем, которые оперируют данными в бд в многпользовательском режиме.
Думаю если бы мы рассматривали однопользовательскую 3д игру (видимо под ней понимается автотренажер), то там были бы объекты движка, которые представляют из себя "объекты на сцене", с "геомертрией", "текстурами" итд
Нужно ли из них делать классы вроде "автомобиль", "мотор" — я не уверен.

G>>>>Могу показать примеры хорошего структурированного кода, где нет ничего, что можно было было назвать "моделью предметной области". Опять-таки можно сказать что это простые примеры, но я не видел сложных примеров с ДДД, где везде хороший структурированный код.
S>>>Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области".
G>>Начнем с простого, позже смогу вырезать кусок из реального проекта.
G>>Недавно делал пример для статьи на Хабре https://github.com/gandjustas/habr-post-stock-api, АПИшка для резервации заказов, работает с базой, содержит очень важную для бизнеса логику. Это как маленький кусок большого приложения

S>Ну мы ведем речь про явно более крупные приложения, а не про crud на 3 операции.
Вспоминаем закон Галла

Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде

Вот простая система есть, мы начнем дополнять функциями, а модель БД — сущностями\таблицами
Если функции пухнут — делаем Extract Method.
Если несколько методов имеют один и тот же набор параметров, то делаем класс с этими параметрами в конструкторе и переносим вызовы внутрь него.

Сколько нам нужно функций, чтобы DDD с его паттернами стало давать какой-то профит?


G>>Там даже есть абстракция — очередь запросов (она не шибко полезная в целом)
S>Зачем, лукавое это? А что стандартная библиотека, кстати, не помогла?
Помогла, в посте написано, что так делать не надо.

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

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

G>>Что там является "моделью предметной области", в чем её ценность, и как она влияет на остальные части кода?
S>Ну как минимум https://github.com/gandjustas/habr-post-stock-api/blob/main/Model.cs
То есть "модель предметной области" это типизированное описание схемы БД, так?
Апологеты DDD как раз с этим спорят.




S>>>А какую проблему решает хороший код, если он даже не пытается моделировать предметную область, т.е. не оперирует необходимыми абстракциями?
G>>1) Уменьшает дублирование кода
G>>2) Уменьшает количество связей и сайд-эффектов
G>>3) Уменьшает цепочку вызовов и количество промежуточных слоев между вызовов и действием
G>>4) Увеличивает быстродействие
G>>5) Уменьшает неявную передачу данных и изменение стояния
G>>Это все вещи связанные, но в некоторых местах могут противоречить друг другу, поэтому хороший код это баланс.

S>Ну т.е. код ради кода, понятно. Ну вот есть хороший код, который плохо решает поставленную задачу, поскольку автор толком не разобрался в предметной области. Ну и какой прок от этой программы кроме эстетики кода?
А кто сказал что отсутствие "объектов доменной модели" автоматически приводит к плохому решению задачи?
И кто сказал что наличие "объектов доменной модели" автоматически приводит к хорошему решению задачи?


S>Ну и самый главный вопрос, а как всему вышеперечисленному мешает оперирование объектами доменной модели?
Никак не мешает и никак не помогает. Хотя зависит от того, что входит в понятие "оперирование объектами доменной модели", так как это может давать ограничения
Например код вида

ctx.Stock.Where(s => s.Wharehouse == id).ExecuteUpdate(x => x.SetProperty(s => s.Quantity, s => s.Quantity - s.Reserved).x.SetProperty(s => s.Reserved, 0))

Является "оперированием объектами доменной модели"?

S>>>По-моему, даже на не ООП языках типа С люди стараются оперировать абстракциями в коде.
G>>Вы как-то слишком широко применяете слово "абстракция". Когда вы создаете класс с набором свойств это не абстракция. Реализация интерфейса это тоже не абстракция. Абстракция это то, что использует такие классы или интерфейсы. А писать такой код нет необходимости. Большинство полезных абстракций уже есть в библиотеках, зачастую стандартных.

S>Делаю какой-нибудь реалистичны автотренажер или игру для машин, есть в стандартной библиотеке класс автомобиль, мотор и т.п.?
Мы тут вроде как корпоративные приложения рассматриваем, которые оперируют данными в бд в многпользовательском режиме.
Думаю если бы мы рассматривали однопользовательскую 3д игру (видимо под ней понимается автотренажер), то там были бы объекты движка, которые представляют из себя "объекты на сцене", с "геомертрией", "текстурами" итд
Нужно ли из них делать классы вроде "автомобиль", "мотор" — я не уверен.

G>>>>Могу показать примеры хорошего структурированного кода, где нет ничего, что можно было было назвать "моделью предметной области". Опять-таки можно сказать что это простые примеры, но я не видел сложных примеров с ДДД, где везде хороший структурированный код.
S>>>Давайте, а то мне кажется мы говорим о разном, подразумевая "модель предметной области".
G>>Начнем с простого, позже смогу вырезать кусок из реального проекта.
G>>Недавно делал пример для статьи на Хабре https://github.com/gandjustas/habr-post-stock-api, АПИшка для резервации заказов, работает с базой, содержит очень важную для бизнеса логику. Это как маленький кусок большого приложения

S>Ну мы ведем речь про явно более крупные приложения, а не про crud на 3 операции.
Вспоминаем закон Галла

Любая работающая сложная система развивается на базе работающей простой системы. Сложные системы, созданные с нуля, никогда не будут работать в реальном мире, поскольку в процессе разработки на них не влияли факторы отбора, присущие среде

Вот простая система есть, мы начнем дополнять функциями, а модель БД — сущностями\таблицами
Если функции пухнут — делаем Extract Method.
Если несколько методов имеют один и тот же набор параметров, то делаем класс с этими параметрами в конструкторе и переносим вызовы внутрь него.

Сколько нам нужно функций, чтобы DDD с его паттернами стало давать какой-то профит?


G>>Там даже есть абстракция — очередь запросов (она не шибко полезная в целом)
S>Зачем, лукавое это?
Да, в посте написано, что так делать не надо в подавляющем большинстве случаев.

S>А что стандартная библиотека, кстати, не помогла?
Помогла