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

L>>Однако, по-моему, "hiding of state-process" как-то не очень вяжется с "ООП — оно целиком про поведение".
L>>Или я неправильно понимаю эту фразу?
S>Всё прекрасно вяжется. Просто состояние в ООП вторично, оно нужно только для обеспечения поведения.

Эта формулировка все-таки существенно отличается от "ООП — оно целиком про поведение".

S>И всё, о чём говорит Кей применительно к состоянию — это ограничение доступа к нему. Узнать состояние объекта можно только через его поведение.

И это как-то отличается от того, как трактуют ООП "Эвансы, Фаулеры, Бучи"? Кей в приведенной фразе не говорит ничего кардинально отличающегося, про инкапсуляцию не пишет разве ленивый.

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

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

S>>В конце главы 4 Э. ссылается на фразу Ф.
S>>

If the architecture isolates the domain-related code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then that architecture can probably support domain-driven design

S>>Это как раз об архитектурах, которые probably могут поддержать DDD. Необходимым условием обозначена изоляция доменного кода от остальной системы, что вряд ли можно сказать об анемике в общем случае.

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

G>Например код выборки для отображения "топ5 покупаемых товаров за месяц" в интернет-магазине является доменным? Например Domain Expert сказал что наличие такого виджета на сайте является критичным. А как его сделать lossely coupled, но достаточно эффективным?
Полагаю что в общем случае TOP 5 не является доменным без какой-то специфики вычисления для товаров в магазине, точно так же как .OrderBy(...).Take(5). Однако, если Domain Expert пожелает выполнять какую-то работу с доменом при покупке товара из TOP 5, то домену придется иметь дело с rest of the system, в случае если за top 5 будет отвечать что-то вне домена. При наличии в домене соответствующей абстракции можно добиться loose coupling. И эта абстракция будет уже "впереди" домена. Достигнув некоторой критической массы абстракций "впереди" домена, будет уже не вполне DDD.

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

G>>Например код выборки для отображения "топ5 покупаемых товаров за месяц" в интернет-магазине является доменным? Например Domain Expert сказал что наличие такого виджета на сайте является критичным. А как его сделать lossely coupled, но достаточно эффективным?
S>Полагаю что в общем случае TOP 5 не является доменным без какой-то специфики вычисления для товаров в магазине, точно так же как .OrderBy(...).Take(5).

Domain — A sphere of knowledge, influence, or activity.

Отсюда

В данном случае есть knowledge о необходимости получать рейтинг покупаемости товаров за период.

S>Однако, если Domain Expert пожелает выполнять какую-то работу с доменом при покупке товара из TOP 5, то домену придется иметь дело с rest of the system, в случае если за top 5 будет отвечать что-то вне домена. При наличии в домене соответствующей абстракции можно добиться loose coupling. И эта абстракция будет уже "впереди" домена. Достигнув некоторой критической массы абстракций "впереди" домена, будет уже не вполне DDD.

То есть получается что почти все нетривиальные выборки данных будут не-DDD, даже если именно они являются основными задачами с точки зрения Domain Expert.

Возьмем бухгалтерию. Там есть сущности — "проводки", "первичные документы" итп, и есть выборки — "балансы", "обороты", "остатки", которые являются основными задачами для эксперта (бухгалтера).

Получается что полноценный DDD невозможен в такой задаче?
Тогда в чем вообще суть DDD? Для чего он нужен? Чем он помогает?

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

L>Эта формулировка все-таки существенно отличается от "ООП — оно целиком про поведение".
Ну так я и не статью в рецензируемый журнал пишу.

L>И это как-то отличается от того, как трактуют ООП "Эвансы, Фаулеры, Бучи"? Кей в приведенной фразе не говорит ничего кардинально отличающегося, про инкапсуляцию не пишет разве ленивый.
Для начала, это отличается от того, как трактуют ООП те, кто трактует Эвансов, Фаулеров, и Бучей, в стиле приведённого вами "определения" ООП.
Потому, что несмотря на математическую эквивалентность утверждений "объекты — это данные с приделанным к ним поведением", и "объекты — это поведение, использующее внутренние данные", подходы в результате они дают совершенно разные.
Я напомню проигнорированный вами аргумент про то, что попытки начать конструировать Круги и Эллипсы от данных приводит к значительным затруднениям при попытке приделать к ним осмысленное поведение.
Зато если начать с требуемого поведения, то не слишком трудно понять, какие данные могут ему потребоваться.

Когда я проектирую решение какой-то задачи в стиле ООП, я определяю поведение. Черновик модели можно построить, вообще не упоминая данные никак. В терминах одного лишь поведения. Именно в этом смысле ООП "целиком про поведение".
Вот у нас один объект что-то послал другому, вот как другой обязан отреагировать. Какие там у них внутри поля, отнаследована ли структура Круга от Эллипса или наоборот — всё это малосущественные в ООП детали.
Именно это отличает ООП от, скажем, реляционной алгебры, где как раз поведения, в общем-то, нет. Зато на передний план выпячены данные.

G>Возьмем бухгалтерию. Там есть сущности — "проводки", "первичные документы" итп, и есть выборки — "балансы", "обороты", "остатки", которые являются основными задачами для эксперта (бухгалтера).

G>Получается что полноценный DDD невозможен в такой задаче?

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

G>Тогда в чем вообще суть DDD? Для чего он нужен? Чем он помогает?

DDD помогает структурировать приложение и вынести логику отдельным слоем. плюс доменный язык.

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

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

S>>Полагаю что в общем случае TOP 5 не является доменным без какой-то специфики вычисления для товаров в магазине, точно так же как .OrderBy(...).Take(5).

G>

G>Domain — A sphere of knowledge, influence, or activity.

G>Отсюда

G>В данном случае есть knowledge о необходимости получать рейтинг покупаемости товаров за период.
В таком случае никаких проблем с изоляцией domain от rest system в отношении TOP5 нет.

Но я бы TOP5 отнес к

Model — A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.

Отсюда

S>>Однако, если Domain Expert пожелает выполнять какую-то работу с доменом при покупке товара из TOP 5, то домену придется иметь дело с rest of the system, в случае если за top 5 будет отвечать что-то вне домена. При наличии в домене соответствующей абстракции можно добиться loose coupling. И эта абстракция будет уже "впереди" домена. Достигнув некоторой критической массы абстракций "впереди" домена, будет уже не вполне DDD.

G>То есть получается что почти все нетривиальные выборки данных будут не-DDD, даже если именно они являются основными задачами с точки зрения Domain Expert.
Это зависит от отношения к классификации. Как отступая от тру ООП в сторону процедурщины при создании сервиса (Эванс об этом пишет), мы остаемся в рамках ООП, так и при выпячивании абстракций впереди domain, можно считать что остаемся в рамках DDD. Как я понимаю, Ф. наличие таких абстракций нисколько не напрягает.

G>Возьмем бухгалтерию. Там есть сущности — "проводки", "первичные документы" итп, и есть выборки — "балансы", "обороты", "остатки", которые являются основными задачами для эксперта (бухгалтера).

G>Получается что полноценный DDD невозможен в такой задаче?
ненене. Невозможно решить эту задачу в рамках только лишь domain. Но позволяя domain дергать за абстракции, реализованные в rest system, можно решить эту задачу в DDD духе. То что я называю это не вполне DDD — это проблемы моего восприятия. Рулит-то все-таки domain, но он уже не первичен, т.к. не впереди. В итоге driven, но не driven...

G>Тогда в чем вообще суть DDD? Для чего он нужен? Чем он помогает?

Domain-driven design not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

http://domaindrivendesign.org/node/120
Как я понимаю, DDD это еще один способ не свалить все в одну кучу. Причем неважно, поклонник DDD или нет, если в голову приходят мысли не завязывать сильно (tight) domain на инфраструктуру, то это уже вполне себе DDD.

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

G>>Возьмем бухгалтерию. Там есть сущности — "проводки", "первичные документы" итп, и есть выборки — "балансы", "обороты", "остатки", которые являются основными задачами для эксперта (бухгалтера).

G>>Получается что полноценный DDD невозможен в такой задаче?

E>выборки нужны эксперту, но не системе. для системы они вообще ничего не значат и на логику, в данном случае, никакого воздействия не оказывают.
E>выборка — это не логика.
Скажу по секрету: 98% работы enterprise application — выборки. Тогда "логика" — оставшиеся 2%, и нафига спрашивается ради двух процентов весь огород?

G>>Тогда в чем вообще суть DDD? Для чего он нужен? Чем он помогает?
E>DDD помогает структурировать приложение и вынести логику отдельным слоем.
Конкретнее, примеры. Как будет выглядеть отдельный слой? Какие в нем будут классы?

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

E>>выборки нужны эксперту, но не системе. для системы они вообще ничего не значат и на логику, в данном случае, никакого воздействия не оказывают.
E>>выборка — это не логика.
G>Скажу по секрету: 98% работы enterprise application — выборки. Тогда "логика" — оставшиеся 2%, и нафига спрашивается ради двух процентов весь огород?

98% работы приложения, возможно, но не логики. соответственно, весь огород ради 100% логики, но не выборок.

E>>DDD помогает структурировать приложение и вынести логику отдельным слоем.
G>Конкретнее, примеры. Как будет выглядеть отдельный слой? Какие в нем будут классы?

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

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

эксперты говорят на языке объектов. это с реляционной точки зрения "остатки" — выборка. для эксперта — это 1 отчёт по остаткам.

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

G>>То есть получается что почти все нетривиальные выборки данных будут не-DDD, даже если именно они являются основными задачами с точки зрения Domain Expert.
S>Это зависит от отношения к классификации. Как отступая от тру ООП в сторону процедурщины при создании сервиса (Эванс об этом пишет), мы остаемся в рамках ООП, так и при выпячивании абстракций впереди domain, можно считать что остаемся в рамках DDD. Как я понимаю, Ф. наличие таких абстракций нисколько не напрягает.

Отношение к классификации как раз очень хорошо видно если почитать материалы на дважды упомянутом сайте. Почти все сводится к тому что сервисы (то есть инкапсулированное поведение без данных) — плохо, а rich-сущности — хорошо. Хотя в терминологии действительно все гладко, там четко не указано как строить модель, там лишь указано что она должна соответствовать домену. Хотя если посмотреть DDD_шный pattern language, то он как раз основывается на rich model.

G>>Возьмем бухгалтерию. Там есть сущности — "проводки", "первичные документы" итп, и есть выборки — "балансы", "обороты", "остатки", которые являются основными задачами для эксперта (бухгалтера).

G>>Получается что полноценный DDD невозможен в такой задаче?
S>ненене. Невозможно решить эту задачу в рамках только лишь domain. Но позволяя domain дергать за абстракции, реализованные в rest system, можно решить эту задачу в DDD духе. То что я называю это не вполне DDD — это проблемы моего восприятия. Рулит-то все-таки domain, но он уже не первичен, т.к. не впереди. В итоге driven, но не driven...
я **й че понял

G>>Тогда в чем вообще суть DDD? Для чего он нужен? Чем он помогает?
S>

S>Domain-driven design not a technology or a methodology. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

S>http://domaindrivendesign.org/node/120
S>Как я понимаю, DDD это еще один способ не свалить все в одну кучу. Причем неважно, поклонник DDD или нет, если в голову приходят мысли не завязывать сильно (tight) domain на инфраструктуру, то это уже вполне себе DDD.
Domain нельзя завязать на инфраструктуру, а domain model вроде как можно и тогда это будет не DDD.

НО. Что такое domain model и что такое инфраструктура. Берем например задачу смешанного документооборота (который полубумажный, как в большинстве госструктур), основная сущность у нас это "карточка документа". Эксперты изначально работают с некоторыми "каталогами", которые 1-в-1 отображаются на хранилище данных.
Так вот использование транзакций хранилища в БЛ будет ли смешением или нет?
А если оно выполняется атрибутами на методах?

Какая степень "привязки" domain model к инфраструктуре критична для DDD?

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

E>>>выборки нужны эксперту, но не системе. для системы они вообще ничего не значат и на логику, в данном случае, никакого воздействия не оказывают.
E>>>выборка — это не логика.
G>>Скажу по секрету: 98% работы enterprise application — выборки. Тогда "логика" — оставшиеся 2%, и нафига спрашивается ради двух процентов весь огород?

E>98% работы приложения, возможно, но не логики. соответственно, весь огород ради 100% логики, но не выборок.
То есть логика это то что не выборки? Но её действительно мало в среднем приложении.

E>>>DDD помогает структурировать приложение и вынести логику отдельным слоем.
G>>Конкретнее, примеры. Как будет выглядеть отдельный слой? Какие в нем будут классы?
E>вам не кажется что вы от всех слишком много требуете?
E>примеры есть в книги Эванса. но каждый волен делать так, как считает нужным.
Примеры в книге эванса я видел и многократно приводил недостатки которые они в себе несут. На что мне отвечали что ценой этих проблем появляются какие-то преимущества. Но никто не смогу показать код, который наглядно эти преимущества демонстрирует.

E>>>плюс доменный язык.
G>>А вот тут вы сами себе противоречите, потому что эксперты как раз говорят на языке выборок, срезов атрибутов, а не целостных сущностей. Особенно явно это прослеживается в бухгалтерии.
E>эксперты говорят на языке объектов.
Где вы таких экспертов нашли? У меня куча бухгалтеров среди родственников и все говорят про обороты, остатки, балансы, сметы итд.

E>это с реляционной точки зрения "остатки" — выборка. для эксперта — это 1 отчёт по остаткам.
И что из этого объект? И как ты будешь создавать классы в программе чтобы они отражали то что говорит эксперт?

E>>98% работы приложения, возможно, но не логики. соответственно, весь огород ради 100% логики, но не выборок.
G>То есть логика это то что не выборки? Но её действительно мало в среднем приложении.

значит в приложении действительно мало логики.

E>>вам не кажется что вы от всех слишком много требуете?
E>>примеры есть в книги Эванса. но каждый волен делать так, как считает нужным.
G>Примеры в книге эванса я видел и многократно приводил недостатки которые они в себе несут. На что мне отвечали что ценой этих проблем появляются какие-то преимущества. Но никто не смогу показать код, который наглядно эти преимущества демонстрирует.

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

E>>эксперты говорят на языке объектов.
G>Где вы таких экспертов нашли? У меня куча бухгалтеров среди родственников и все говорят про обороты, остатки, балансы, сметы итд.

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

E>>это с реляционной точки зрения "остатки" — выборка. для эксперта — это 1 отчёт по остаткам.
G>И что из этого объект? И как ты будешь создавать классы в программе чтобы они отражали то что говорит эксперт?

эти классы будут не более чем DTO, без какой либо логики, так любимый и почетаемый тобой тип.

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

E>>>98% работы приложения, возможно, но не логики. соответственно, весь огород ради 100% логики, но не выборок.
G>>То есть логика это то что не выборки? Но её действительно мало в среднем приложении.
E>значит в приложении действительно мало логики.
А как быть с приложениями, где для некоторого изменения данных требуется выборка?
Например, для принятия решения какую делать скидку клиенту требуется посчитать сумму купленных им товаров без скидки за последний месяц.
Опять интересует как такое делать в рамках DDD, но при этом сохраняя высокую эффективность кода.


E>>>вам не кажется что вы от всех слишком много требуете?
E>>>примеры есть в книги Эванса. но каждый волен делать так, как считает нужным.
G>>Примеры в книге эванса я видел и многократно приводил недостатки которые они в себе несут. На что мне отвечали что ценой этих проблем появляются какие-то преимущества. Но никто не смогу показать код, который наглядно эти преимущества демонстрирует.

E>если для тебя DDD это сплошные недостатки, то возможно ты не понял то, что хотел передать Эванс, и значит оно тебе не нужно.
E>не забивай этим голову.
Да вот как раз интересно что же хотел передать Эванс. Ты сможешь объяснить?

E>>>эксперты говорят на языке объектов.
G>>Где вы таких экспертов нашли? У меня куча бухгалтеров среди родственников и все говорят про обороты, остатки, балансы, сметы итд.

E>это и есть предметы разговора, которые можно включить в язык, при необходимости, если над ними происходят какие-то действия. если они нужны только конечному пользователю, то в таком виде они могут не рассматриваются при построении доменной модели.
таким образом ты теряешь Ubiquitous Language, про который как раз пишет эванс.

E>>>это с реляционной точки зрения "остатки" — выборка. для эксперта — это 1 отчёт по остаткам.
G>>И что из этого объект? И как ты будешь создавать классы в программе чтобы они отражали то что говорит эксперт?

E>эти классы будут не более чем DTO, без какой либо логики, так любимый и почетаемый тобой тип.
А причем тут DTO если тебе нужна выборка? Ну сделать класс "баланс" у тебя от этого будет считаться баланс? Вот именно это ведь именно это интересует. Как ты сделаешь расчет баланса в DDD?

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

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

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

G>Отношение к классификации как раз очень хорошо видно если почитать материалы на дважды упомянутом сайте. Почти все сводится к тому что сервисы (то есть инкапсулированное поведение без данных) — плохо, а rich-сущности — хорошо. Хотя в терминологии действительно все гладко, там четко не указано как строить модель, там лишь указано что она должна соответствовать домену. Хотя если посмотреть DDD_шный pattern language, то он как раз основывается на rich model.
Да, рич там любят. Но если все-таки мы возьмем типичный DDD и логику из рич сущностей перетащим в сервисы домена (именно домена), то это формально все еще будет DDD. Атипичный, но DDD.

G>>>Возьмем бухгалтерию. Там есть сущности — "проводки", "первичные документы" итп, и есть выборки — "балансы", "обороты", "остатки", которые являются основными задачами для эксперта (бухгалтера).

G>>>Получается что полноценный DDD невозможен в такой задаче?
S>>ненене. Невозможно решить эту задачу в рамках только лишь domain. Но позволяя domain дергать за абстракции, реализованные в rest system, можно решить эту задачу в DDD духе. То что я называю это не вполне DDD — это проблемы моего восприятия. Рулит-то все-таки domain, но он уже не первичен, т.к. не впереди. В итоге driven, но не driven...
G> я **й че понял
Неважно. Если проводка как сущность/сервис домена будет использовать абстракцию для получения необходимых ей данных — то формально DDD ни что не противоречит.

S>>Как я понимаю, DDD это еще один способ не свалить все в одну кучу. Причем неважно, поклонник DDD или нет, если в голову приходят мысли не завязывать сильно (tight) domain на инфраструктуру, то это уже вполне себе DDD.
G>Domain нельзя завязать на инфраструктуру, а domain model вроде как можно и тогда это будет не DDD.
Формально зависит от weak/strong coupling.

G>НО. Что такое domain model и что такое инфраструктура. Берем например задачу смешанного документооборота (который полубумажный, как в большинстве госструктур), основная сущность у нас это "карточка документа". Эксперты изначально работают с некоторыми "каталогами", которые 1-в-1 отображаются на хранилище данных.
G>Так вот использование транзакций хранилища в БЛ будет ли смешением или нет?
Если отнести транзакцию хранилища к Model и выделить абстракцию, то смешения не будет. Если абстракцию не выделить — то будет смешение. Грань тонка, но тут у поклонников DDD больше значит не формальность, а взгляд на вещи.

G>А если оно выполняется атрибутами на методах?
X3

G>Какая степень "привязки" domain model к инфраструктуре критична для DDD?
DDD это способ мышления. Как и OOP. Критичным является отношение разработчика к вопросу.
Т.е. количественные оценки тут уместны ровно так же как и в случае определения степени OOP-шности.

Я работал в одном НИИ, так там куча народу считает что использует C++ когда переименовывают *.c в *.cpp и заменяют malloc на new. Когда их спрашиваешь, на чем вы программируете — они хором безаппеляционно заявляют что на C++. Я с ними не согласен, но это сугубо мои проблемы.

E>>>>98% работы приложения, возможно, но не логики. соответственно, весь огород ради 100% логики, но не выборок.
G>>>То есть логика это то что не выборки? Но её действительно мало в среднем приложении.
E>>значит в приложении действительно мало логики.
G>А как быть с приложениями, где для некоторого изменения данных требуется выборка?
G>Например, для принятия решения какую делать скидку клиенту требуется посчитать сумму купленных им товаров без скидки за последний месяц.
G>Опять интересует как такое делать в рамках DDD, но при этом сохраняя высокую эффективность кода.

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

E>>если для тебя DDD это сплошные недостатки, то возможно ты не понял то, что хотел передать Эванс, и значит оно тебе не нужно.
E>>не забивай этим голову.
G>Да вот как раз интересно что же хотел передать Эванс. Ты сможешь объяснить?

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

E>>>>эксперты говорят на языке объектов.
G>>>Где вы таких экспертов нашли? У меня куча бухгалтеров среди родственников и все говорят про обороты, остатки, балансы, сметы итд.
E>>это и есть предметы разговора, которые можно включить в язык, при необходимости, если над ними происходят какие-то действия. если они нужны только конечному пользователю, то в таком виде они могут не рассматриваются при построении доменной модели.
G>таким образом ты теряешь Ubiquitous Language, про который как раз пишет эванс.

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

E>>эти классы будут не более чем DTO, без какой либо логики, так любимый и почетаемый тобой тип.
G>А причем тут DTO если тебе нужна выборка? Ну сделать класс "баланс" у тебя от этого будет считаться баланс? Вот именно это ведь именно это интересует. Как ты сделаешь расчет баланса в DDD?

баланс это выборка? выборка.
значит будет 1 метод у какого-то абстрактного класса, который сделает select, вызовет хранимую или сделает выборку с помощью linq, и вернет результат. DDD тут совершенно не причем.

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

E>>>>>98% работы приложения, возможно, но не логики. соответственно, весь огород ради 100% логики, но не выборок.
G>>>>То есть логика это то что не выборки? Но её действительно мало в среднем приложении.
E>>>значит в приложении действительно мало логики.
G>>А как быть с приложениями, где для некоторого изменения данных требуется выборка?
G>>Например, для принятия решения какую делать скидку клиенту требуется посчитать сумму купленных им товаров без скидки за последний месяц.
G>>Опять интересует как такое делать в рамках DDD, но при этом сохраняя высокую эффективность кода.

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


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

E>>>>>эксперты говорят на языке объектов.
G>>>>Где вы таких экспертов нашли? У меня куча бухгалтеров среди родственников и все говорят про обороты, остатки, балансы, сметы итд.
E>>>это и есть предметы разговора, которые можно включить в язык, при необходимости, если над ними происходят какие-то действия. если они нужны только конечному пользователю, то в таком виде они могут не рассматриваются при построении доменной модели.
G>>таким образом ты теряешь Ubiquitous Language, про который как раз пишет эванс.

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

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

E>>>эти классы будут не более чем DTO, без какой либо логики, так любимый и почетаемый тобой тип.
G>>А причем тут DTO если тебе нужна выборка? Ну сделать класс "баланс" у тебя от этого будет считаться баланс? Вот именно это ведь именно это интересует. Как ты сделаешь расчет баланса в DDD?

E>баланс это выборка? выборка.
E>значит будет 1 метод у какого-то абстрактного класса, который сделает select, вызовет хранимую или сделает выборку с помощью linq, и вернет результат. DDD тут совершенно не причем.
То есть DDD не при чем основной части домена? Тогда в чем ценность DDD?

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

получили общую сумму покупок за последний месяц и передали доменной модели.
так же эту сумму можно получить из объекта самого покупателя.
всё зависит от организации модели.

E>>это бессмысленно. еще раз повторю, если ты не понял что говорит Эванс, значит оно тебе не нужно. пользуйся тем подходом, который тебе ближе, проще, удобнее.
G>Мне интересно понять что же такого говорил эванс. Преим ущества использования подхода должны быть явны и перевешивать недостатки если таковые имеются. Преимущества

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

E>>>>>>эксперты говорят на языке объектов.
G>>>>>Где вы таких экспертов нашли? У меня куча бухгалтеров среди родственников и все говорят про обороты, остатки, балансы, сметы итд.
E>>>>это и есть предметы разговора, которые можно включить в язык, при необходимости, если над ними происходят какие-то действия. если они нужны только конечному пользователю, то в таком виде они могут не рассматриваются при построении доменной модели.
G>>>таким образом ты теряешь Ubiquitous Language, про который как раз пишет эванс.

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

мы и говорим на одном языке с экспертами. о тех вещах, которые нас интересуют. и не говорим о тех, которые нас не интересуют.

E>>баланс это выборка? выборка.
E>>значит будет 1 метод у какого-то абстрактного класса, который сделает select, вызовет хранимую или сделает выборку с помощью linq, и вернет результат. DDD тут совершенно не причем.
G>То есть DDD не при чем основной части домена? Тогда в чем ценность DDD?

DDD не имеет отношения к построению отчетов, точнее даже, обычных выборок.
ты еще форматирование HTML на DDD возложи.
ценность DDD в организации и построении бизнес логики.

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

S>Но если все-таки мы возьмем типичный DDD и логику из рич сущностей перетащим в сервисы домена (именно домена), то это формально все еще будет DDD. Атипичный, но DDD.

G>>Так вот использование транзакций хранилища в БЛ будет ли смешением или нет?
S>Если отнести транзакцию хранилища к Model и выделить абстракцию, то смешения не будет. Если абстракцию не выделить — то будет смешение. Грань тонка, но тут у поклонников DDD больше значит не формальность, а взгляд на вещи.

G>>А если оно выполняется атрибутами на методах?
S>X3

G>>Какая степень "привязки" domain model к инфраструктуре критична для DDD?
S>DDD это способ мышления. Как и OOP. Критичным является отношение разработчика к вопросу.
S>Т.е. количественные оценки тут уместны ровно так же как и в случае определения степени OOP-шности.

Как раз ООП больше про инструменты, вроде классов, объектов, инкапсуляции и полиморфизма. А вот как "взгляд" на вещи ООП не прижился, сильно свое понимание у каждого. Как например что от чего наследовать в паре "круг" и "эллипс".

Что же такое DDD? Вроде не pattern language, несмотря на то что аплогеты очень активно его насаждают, вроде не дизайн, вроде не способ анализа и не методология.

S>Я работал в одном НИИ, так там куча народу считает что использует C++ когда переименовывают *.c в *.cpp и заменяют malloc на new. Когда их спрашиваешь, на чем вы программируете — они хором безаппеляционно заявляют что на C++. Я с ними не согласен, но это сугубо мои проблемы.
Да и пусть считают, они же не пытаются других учить писать на С++.

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

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

E>получили общую сумму покупок за последний месяц и передали доменной модели.
Где получили? Кто получили?

E>так же эту сумму можно получить из объекта самого покупателя.
Каким образом? Выполнить запрос к хранилищу? Покупатель будет иметь ссылку на repository?
Или ты предложишь циклом ходить по orders, загружая всю историю заказов в память? и выполняя SELECT N+1

E>всё зависит от организации модели.
Ок, покажи как эффективно организовать модель в таком случае.

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

E>>>>>>>эксперты говорят на языке объектов.
G>>>>>>Где вы таких экспертов нашли? У меня куча бухгалтеров среди родственников и все говорят про обороты, остатки, балансы, сметы итд.
E>>>>>это и есть предметы разговора, которые можно включить в язык, при необходимости, если над ними происходят какие-то действия. если они нужны только конечному пользователю, то в таком виде они могут не рассматриваются при построении доменной модели.
G>>>>таким образом ты теряешь Ubiquitous Language, про который как раз пишет эванс.

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

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

E>>>баланс это выборка? выборка.
E>>>значит будет 1 метод у какого-то абстрактного класса, который сделает select, вызовет хранимую или сделает выборку с помощью linq, и вернет результат. DDD тут совершенно не причем.
G>>То есть DDD не при чем основной части домена? Тогда в чем ценность DDD?

E>DDD не имеет отношения к построению отчетов, точнее даже, обычных выборок.
То есть не имеет отношение к домену (той самой предметной области о которой тебе скажут бухгалтеры).

E>ценность DDD в организации и построении бизнес логики.
Так получение баланса и других данных для отчетов и есть та логика, которая нужна бизнесу. У тебя другое понимание бизнес-логики?

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

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

G>>>Какая степень "привязки" domain model к инфраструктуре критична для DDD?
S>>DDD это способ мышления. Как и OOP. Критичным является отношение разработчика к вопросу.
S>>Т.е. количественные оценки тут уместны ровно так же как и в случае определения степени OOP-шности.

G>Как раз ООП больше про инструменты, вроде классов, объектов, инкапсуляции и полиморфизма. А вот как "взгляд" на вещи ООП не прижился, сильно свое понимание у каждого. Как например что от чего наследовать в паре "круг" и "эллипс".
Вполне себе взгляд. Я могу взглянуть на WinAPI и посчитать "вполне себе ООП по Кею". Либо посмотреть на double и увидеть что он может принимать сообщения `+`(1), что он инкапсулирует состояние меняющееся при сообщении `=`(x).
Я не хочу спорить по этому поводу. Если сам Эванс говорит что DDD это не методология, то

G>Что же такое DDD? Вроде не pattern language, несмотря на то что аплогеты очень активно его насаждают, вроде не дизайн, вроде не способ анализа и не методология.

Пусть будет взглядом на организацию кода, а не на вещи.

S>>Я работал в одном НИИ, так там куча народу считает что использует C++ когда переименовывают *.c в *.cpp и заменяют malloc на new. Когда их спрашиваешь, на чем вы программируете — они хором безаппеляционно заявляют что на C++. Я с ними не согласен, но это сугубо мои проблемы.
G>Да и пусть считают, они же не пытаются других учить писать на С++.
Еще как пытаются учить

E>>получили общую сумму покупок за последний месяц и передали доменной модели.
G>Где получили? Кто получили?

тот, кто обращается к доменной модели.

E>>так же эту сумму можно получить из объекта самого покупателя.
G>Каким образом? Выполнить запрос к хранилищу? Покупатель будет иметь ссылку на repository?

покупатель будет сформирован с полным набором необходимых данных при помощи доменного сервиса.

G>Или ты предложишь циклом ходить по orders, загружая всю историю заказов в память? и выполняя SELECT N+1

если доменная логика потребует проходиться циклом по ордерам, то так и будет.
и да, для этого необходимое кол-во ордеров будет загружено в память.
и да, вероятно будет select n+1.
это криминально? в бизнес приложениях — нет. в высоконагруженном сайте? возможно.

E>>всё зависит от организации модели.
G>Ок, покажи как эффективно организовать модель в таком случае.

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

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

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

E>>мы и говорим на одном языке с экспертами. о тех вещах, которые нас интересуют. и не говорим о тех, которые нас не интересуют.
G>Тогда вы делаете программу, которая нужна вам, а не пользователям.
G>А обычно наоборот, слушают заказчиков\экспертов\пользователей.

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

E>>DDD не имеет отношения к построению отчетов, точнее даже, обычных выборок.
G>То есть не имеет отношение к домену (той самой предметной области о которой тебе скажут бухгалтеры).

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

E>>ценность DDD в организации и построении бизнес логики.
G>Так получение баланса и других данных для отчетов и есть та логика, которая нужна бизнесу. У тебя другое понимание бизнес-логики?

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