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


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

1)Сразу оговорюсь, я не апологет DDD. Я ни одно книжки по DDD не прочитал, и много знаю по касательной.
Я просто не считаю правильным отмахивать от DDD, как о бесполезной штуке. Оно большое, и люди частями или
целиком его вполне успешно применяют.
2)

То есть "модель предметной области" это типизированное описание схемы БД,

Что в этом плохого и кто с этим спорит? В DDD есть паттерн Repository, как раз и отвечает за сохранение главных
доменных сущностей, наверное и таблицы соотв. должны были быть.

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

Никто не сказал, просто это, кхм, странно. Задача софта эмулировать соотв. процессы. Как можно эмулировать что-то без
соотв. сущностей?

G>И кто сказал что наличие "объектов доменной модели" автоматически приводит к хорошему решению задачи?

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

Я вообще не вижу противоречия между хорошим кодом и объектами доменной модели. Это прям какая-то странная дихотомия.

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

G>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))
G>

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

Скорее оперирование представлением в бд.

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

Я несколько фривольно обращался со словом абстракция. Я под этим больше понимал идеи доменных объектов. Я за это слово
в данном контексте не держусь. Тут речь главным образом об "объектах доменной модели".

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

Какая разница, софт есть софт.

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

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


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

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

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

Вот цитата Б. Мейера отсюда -- https://bertrandmeyer.com/2012/11/27/why-so-many-features/

It is easy to complain about software bloat, and examples of needlessly complex system abound. But your bloat may be my lifeline, and what I dismiss as superfluous may for you be essential. To paraphrase a comment by Ichbiah, the designer of Ada, small systems solve small problems. Outside of academic prototypes it is inevitable that a successful software system will grow in complexity if it is to address the variety of users’ needs and circumstances. What matters is not size but consistency: maintaining a well-defined architecture that can sustain that growth without imperiling the system’s fundamental solidity and elegance.

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

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

Какой-то дурацкий вопрос, если честно. Типа сколько нужно людей, чтобы лампочку вкрутить. Вы какую-то цифру ждете?
Она, скорее всего, у каждого будет своя.

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

Само собой, но ее одной не достаточно.