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

A> И структура БД не должна делать свой отпечаток ни на модели, ни на языке — обратный процесс естественен. Это моя центральная мысль, которую я хотел озвучить.
Это прямо-таки какой-то нездоровый эскапизм... =)
Во-первых, лично я не вижу здесь ничего естественного, а во-вторых мы, к сожалению, живем не в идеальном мире, где можно было бы просто игнорировать вещи которые не укладываются в нашу прекрасную модель.
База, просто самим своим существованием, будет влиять на модель. Надо уже признать этот факт и жить с ним, а не пытаться его игнорировать. К сожалению, на данном этапе развития цивилизации, корректное и эффективное хранение состояния требует определенных усилий и накладывает ряд ограничений и "накладывает свой отпечаток" на модель.
И усилия направленные на попытку игнорировать этот факт, достойны гораздо лучшего приминения.

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

S>

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

S>Смотрите сами: (1)мы не отвечаем за оценку требований, (2)не можем оценить их влияние на дизайн, (2)не можем сказать, насколько мы верно описали требования — всё это говорит нам заказчик. Вы по-прежнему считаете, что ответственность лежит исключительно на разработчиках?

Я не согласен с п. 1, 2 и 3 и хотелось бы узнать, откуда ты их получил.

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

S>Наконец, модель предметной области может вообще не затрагивать модель данных как таковую — берём моделирование физических процессов или управление бизнес-процессами: главная сложность не в структуре данных, а в нюансах обработки.

Т.е. эти нюансы обработки и есть часть модели предметной области ? По моему ты говоришь про операции, которые суть БЛ.

I>>Т.е. модель предметной области это структурная модель + логическая + функциональная.
S>Эт замечательно, что просто. И как же вы отделяете стабильную информацию от нестабильной?

Используя знания о предметной области.

I>>Т.е. ответ на то, куда поместить метод, дает SOLID, а не рассуждения о тонкостях логистики у различных заказчиков.
S>То есть вы отказываетесь от формальной логики в пользу ad hoc-эмпирики?

Я пока не увидел демонстрации твоей формальной логики

I>>Вообще говоря относится непосредственно — это логистика склада.
S>Я выше привёл вам абсолютно легальный способ организовать работу без накручивания излишнего функционала — поиск по накладной. Под одним и тем же баззвордом могут скррывааться очень разные вещи.

Логистика склада от этого не перестает быть логистикой.

I>>А почему её надо вынести на уровень BL — очень просто. У этой функции очень много зависимостей. Ни в один класс модели данных она просто не влезет. Всё. Все остальное — от лукавого.
S>Ок. Если бы она _сейчас_ влазила — внесли бы? Если да — что делали бы потом?

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

I>>Я так и думал Эванс вроде ясно пишет — правила оные являются частью модели предметной области, но не являются частью модели данных. У него целый пример про это есть.
S>То что вы привели — это нифига не правила, а очень неудобный способ потратить время сотрудника.

Не понял, что ты хотел сказать

>Итак, что вы будете делать, если в будущем будет решено ввести журнал поставок или интегрироваться с бухгалтерией, где всё записано(с)?

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

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

S>Вам придётся выкинуть большой кусок логики, вследствие этого поменяется ваша модель. Дальше — нехитрый выбор:
S>- Оставить код как есть. Модель у вас теперь бесполезна, т.к. не соответствует реальному коду
S>- Перелопачивать архитектуру системы.

Конечно. Потому и нужно допрашивать экспертов. Т.е. оценивать влияние требований на дизайн — про это ты сказал "не можем оценить их влияние на дизайн"

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

IB>База, просто самим своим существованием, будет влиять на модель. Надо уже признать этот факт и жить с ним, а не пытаться его игнорировать. К сожалению, на данном этапе развития цивилизации, корректное и эффективное хранение состояния требует определенных усилий и накладывает ряд ограничений и "накладывает свой отпечаток" на модель.
IB>И усилия направленные на попытку игнорировать этот факт, достойны гораздо лучшего приминения.

Грубо говоря, на дизайн оказывает влияние как наличие базы, так и её отсутствие

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

S>>Смотрите сами: (1)мы не отвечаем за оценку требований, (2)не можем оценить их влияние на дизайн, (2)не можем сказать, насколько мы верно описали требования — всё это говорит нам заказчик. Вы по-прежнему считаете, что ответственность лежит исключительно на разработчиках?


I>Например, получая требования от заказчика, тебе придется их оценить, как минимум сказать что задача разрешима. Оценку влияния на дизайн тоже приходится делать

Да, но мы вынуждены строить все рассуждения на предположениях и (в лучшем случае) на знании о прошлых проблемах и способах их решения. И потом наш дизайгн красиво рушится аля карточный домик от очередного невовремя поступившего требования. Заказчик _физически_ не способен озвучить все требования к софту, на каждой итерации из требований можно получить только часть знания о том, как всё должно быть сделано. Причём требования включают в себя главным образом описание интерфейса программы (не UI, а интерфейса вообще) и ничего не говорят о внутренностях проблемы и о самой её сути. Поэтому, пока мы основываемся исключительно на требованиях, у нас нет и не будет возможности объективно оценить правильность выбора архитектуры. Зато всегда есть отмазка "ну не могли же мы знать, что". Про это и шла речь, когда я говорил о неявном перекладывании ответственности на заказчика.

---

S>>Наконец, модель предметной области может вообще не затрагивать модель данных как таковую — берём моделирование физических процессов или управление бизнес-процессами: главная сложность не в структуре данных, а в нюансах обработки.

I>Т.е. эти нюансы обработки и есть часть модели предметной области ? По моему ты говоришь про операции, которые суть БЛ.

О таа. Постоянная тяготения, методика выполнения нагрузочных рассчётов или уравнения Больцмана-Швагенбауэра — это определённо суть БЛ. Вокруг — не матрица, а реальный мир, в котором _очень_ много вещей существует вне зависимости от ваших желаний, или бизнес-логики заказчика. Вы конечно можете автоматизаровать нечто, оторванное от реальности, только ничего полезного из этого не выйдет.


I>>>Т.е. модель предметной области это структурная модель + логическая + функциональная.
S>>Эт замечательно, что просто. И как же вы отделяете стабильную информацию от нестабильной?
I>Используя знания о предметной области.
Ну здраствуйте И чем же отличается модель предметной области от знаний о предметной области?

---

I>>>Вообще говоря относится непосредственно — это логистика склада.
S>>Я выше привёл вам абсолютно легальный способ организовать работу без накручивания излишнего функционала — поиск по накладной. Под одним и тем же баззвордом могут скррывааться очень разные вещи.
I>Логистика склада от этого не перестает быть логистикой.

Шикарно! Под одним и тем же термином у вас скрывается множество различных подходов к решению проблемы, но это — фигня. Главное, что логистика остаётся логистикой.

I>>>А почему её надо вынести на уровень BL — очень просто. У этой функции очень много зависимостей. Ни в один класс модели данных она просто не влезет. Всё. Все остальное — от лукавого.
S>>Ок. Если бы она _сейчас_ влазила — внесли бы? Если да — что делали бы потом?

I>Необязательно. Всегда нужно иметь чуть больше информации, чем нужно прямо сейчас. Сведения про журнал или бухгалтерию, из твоего примера ниже, и есть такая информация.
Пардон, а откуда вы эту информацию возьмёте? Из знаний о предметной области? Привет — у вас уже появилась та самая модель, только в неявном виде.

I>>>Я так и думал Эванс вроде ясно пишет — правила оные являются частью модели предметной области, но не являются частью модели данных. У него целый пример про это есть.
S>>То что вы привели — это нифига не правила, а очень неудобный способ потратить время сотрудника.
I>Не понял, что ты хотел сказать

Ваш подход:

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

Мой:

А что, мы не записываем никаких данных о поставках? Если записываем — в чём проблема найти соответствующую поставку по накладной?

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

---

>>Итак, что вы будете делать, если в будущем будет решено ввести журнал поставок или интегрироваться с бухгалтерией, где всё записано(с)?

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

Вот про это я и говорил — вместо того, чтобы провести анализ требований на их соответствие формальной и верифицированной модели, вы, если повезёт, _можете предположить_.

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

I>Конечно. Потому и нужно допрашивать экспертов. Т.е. оценивать влияние требований на дизайн — про это ты сказал "не можем оценить их влияние на дизайн"
Превед! А как вы оформляете то знание, что получено от экспертов? Как проверяете полученную информацию на согласованность?

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

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

I>>Например, получая требования от заказчика, тебе придется их оценить, как минимум сказать что задача разрешима. Оценку влияния на дизайн тоже приходится делать

S>Да, но мы вынуждены строить все рассуждения на предположениях и (в лучшем случае) на знании о прошлых проблемах и способах их решения. И потом наш дизайгн красиво рушится аля карточный домик от очередного невовремя поступившего требования. Заказчик _физически_ не способен озвучить все требования к софту, на каждой итерации из требований можно получить только часть знания о том, как всё должно быть сделано. Причём требования включают в себя главным образом описание интерфейса программы (не UI, а интерфейса вообще) и ничего не говорят о внутренностях проблемы и о самой её сути. Поэтому, пока мы основываемся исключительно на требованиях, у нас нет и не будет возможности объективно оценить правильность выбора архитектуры. Зато всегда есть отмазка "ну не могли же мы знать, что". Про это и шла речь, когда я говорил о неявном перекладывании ответственности на заказчика.

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

Т.е. это не типичный случай в разработке, а просто уход от ответственности.

I>>Т.е. эти нюансы обработки и есть часть модели предметной области ? По моему ты говоришь про операции, которые суть БЛ.

S>О таа. Постоянная тяготения, методика выполнения нагрузочных рассчётов или уравнения Больцмана-Швагенбауэра — это определённо суть БЛ. Вокруг — не матрица, а реальный мир, в котором _очень_ много вещей существует вне зависимости от ваших желаний, или бизнес-логики заказчика.

Пусть существует.

I>>Используя знания о предметной области.
S>Ну здраствуйте И чем же отличается модель предметной области от знаний о предметной области?

Исключительно объемом, т.е. степенью детализации, т.к. знания о предметной области всего лишь модель.

I>>Логистика склада от этого не перестает быть логистикой.

S>Шикарно! Под одним и тем же термином у вас скрывается множество различных подходов к решению проблемы, но это — фигня. Главное, что логистика остаётся логистикой.

Я говорю про то, что твое разделение искусственное. Отталкиваться нужно не от того, специфична ли операция для бизнеса кастомера или нет.

Если операция специфична для бизнеса кастомера — это БЛ.

Если не специфична, а есть общий случай для всех приложений в этой области — это все равно будет БЛ.

I>>Необязательно. Всегда нужно иметь чуть больше информации, чем нужно прямо сейчас. Сведения про журнал или бухгалтерию, из твоего примера ниже, и есть такая информация.
S>Пардон, а откуда вы эту информацию возьмёте? Из знаний о предметной области? Привет — у вас уже появилась та самая модель, только в неявном виде.

В том то и дело и я уже не раз говорил про это. Только кастомер раскрыл рот — нужно строить модель

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

S>Ваш подход:
S>

S>Вот простая задача — есть склад, есть поставки, есть заказы, скидки и есть возвраты. при возврате товара надо вычислить 1 сумму возвращаемых денег с учетом всех возможных скидок и округлений 2 найти именно ту поставку с которой единица товара прибыла на склад

Здесь нет подхода, здесь описание входа и выхода найти функци

S>Мой:
S>

S>А что, мы не записываем никаких данных о поставках? Если записываем — в чём проблема найти соответствующую поставку по накладной?

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

Этот элементарный функционал и есть логистика. Я привел пример операции которая является БЛ. Легко она реализуется или нет в любом случае это БЛ. Про реализаию я ровно ничего не сказал — про крутость логики и расход времени ты сам додумал. Вероятно, тебя смутило слова "скидка" "округление" ? Есть ответы и на это, они тебе нужны ?

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

S>Вот про это я и говорил — вместо того, чтобы провести анализ требований на их соответствие формальной и верифицированной модели, вы, если повезёт, _можете предположить_.

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

I>>Конечно. Потому и нужно допрашивать экспертов. Т.е. оценивать влияние требований на дизайн — про это ты сказал "не можем оценить их влияние на дизайн"
S>Превед! А как вы оформляете то знание, что получено от экспертов? Как проверяете полученную информацию на согласованность?

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

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

Я снова не понял чего ты хотел сказать. Систематизация знаний это не фокус какой нибудь, правильно ? Что ты вкладываешь в этом понятие ?

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

I>"пока мы основываемся исключительно на требованиях" — это и есть основная причина. Т.е. если девелоперы не хотят рассматривать ничего сверх того, что может сказать кастомер, то это и есть перекладывание ответственности.

I>Т.е. это не типичный случай в разработке, а просто уход от ответственности.
Таак, мы всё ближе и ближе. Что будут делать девелоперы с информацией сверх того, что сказал кастомер? Тут _уже_ появляется модель знаний — пускай и в неочищенной форме. Осталось всего-то вынести стабильную и верифицируемую часть знаний в отдельный артефакт, и я не буду жалеть, что вообще завёл этот спор.

---

S>>О таа. Постоянная тяготения, методика выполнения нагрузочных рассчётов или уравнения Больцмана-Швагенбауэра — это определённо суть БЛ. Вокруг — не матрица, а реальный мир, в котором _очень_ много вещей существует вне зависимости от ваших желаний, или бизнес-логики заказчика.

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

---

I>>>Используя знания о предметной области.
S>>Ну здраствуйте И чем же отличается модель предметной области от знаний о предметной области?
I>Исключительно объемом, т.е. степенью детализации, т.к. знания о предметной области всего лишь модель.
Вот тут я не понял — что ещё можно вносить в модель помимо знаний? Почему вы всё ещё заявляете, что у нас нет стабильной информации, раз уже признали её необходимость, пусть и в форме "знаний о предметной области"?

I>Я говорю про то, что твое разделение искусственное. Отталкиваться нужно не от того, специфична ли операция для бизнеса кастомера или нет.
Да. Надо отталкиваться от того, инвариантны ли наши знания или нет.

---

I>"провести анализ требований на их соответствие формальной и верифицированной модели" — вот про это подробнее. Шота мне кажется, что про это ты говорил "не можем".

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

I>>>Конечно. Потому и нужно допрашивать экспертов. Т.е. оценивать влияние требований на дизайн — про это ты сказал "не можем оценить их влияние на дизайн"
S>>Превед! А как вы оформляете то знание, что получено от экспертов? Как проверяете полученную информацию на согласованность?
I>А почему ты у меня спрашиваешь ? Это ж ведь ты сказал, что чего то не можешь.
Потому что мы снова и снова возвращаемся к необходимости знать чуть больше, чем говорят нам требования, и к необходимости представлять эти знания в виде отдельной модели, а не размазывать их по всему проекту.

S>Осталось уточнить: что стоит вносить в модель предметной области?

Для того чтобы получить какие-либо преимущества от использования DDD модель предметной области нужно рассматривать как неделимый синтез данных и поведения.
Альтернатива отдельного существования модели данных и поведения как правило требует несколько иных подходов чем те что предполагает DDD.

S>Лично я резко против того, чтобы вносить в модель особенности бизнес-логики заказчика. Доводы нехитрые:

S>1. Цель внедрения ПО — автоматизация части деятельности заказчика. На момент внедрения бизнес-логика либо отсутствует в явном виде (если заказчик не расписал основные процессы), или соответствует текущим, неавтоматизированным процессам. После внедрения может понадобиться расширить область автоматизации, или реализовать пожелания заказчика, в принципе невозможные при "ручной" обработке. С дизайном, прибитым гвоздями к предыдущей модели бизнес-логики, это будет весьма весёлым занятием.
S>2. Большинство из виденных методологий разработки предполагает работу с заказчиком, как с чёрным ящиком: получаем непредсказуемый набор требований, выдаём прототип, и крутимся в петле улучшений до тех пор, пока не придём к компромиссу. При этом ответственность за неверные требования неявным образом перекладывается на заказчика: "чего попросили, то и получили". Если мы не можем объективно отличить значимые требования от незначимых — как мы можем гарантировать правильность построенной модели и принятых на её основе решений?
S>3. Заказчик никогда не работает в вакууме. Вне зависимости от его желаний, его бизнес ограничен множеством объективно существующих правил и ограничений. И, волей-неволей, заказчик вынужден к ним приспосабливаться. Ограничив модель областью, в которой работает заказчик, мы одновременно получаем и стабильную и объективную информацию для принятия решений, и способ оценки требований заказчика с точки зрения предметной области бизнеса, и способ обезопасить себя от будущих изменений в бизнес-логике.

Дело в том, что абсолютизация правильности, стабильности или объективности модели не верна. Что в DDD, что в альтернативных подходах — все относительно. Строится модель которая здесь и сейчас, она с определенной степенью успешности выполняет или не выполняет возложенные на нее ожидания (например тестируемость, когнитивность, компактность, простота эволюции, итд итп).

S>В итоге получается примерно следущее разделение:
S>- Модель предметной области определяет основной набор сущностей, инварианты и правила операций.
S>- Бизнес-логика манипулирует моделью предметной области.

Ок, вопрос — и что это? Серебрянная пуля? Архитектура для 9x.xx% приложений с определенным набором требований? Описание дел в текущем проекте?

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

I>>Т.е. это не типичный случай в разработке, а просто уход от ответственности.
S>Таак, мы всё ближе и ближе. Что будут делать девелоперы с информацией сверх того, что сказал кастомер?

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

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

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

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

Эта твоя модель знаний и есть модель предметной области. Только ты почему то считаешь что оная модель может включать только стабильные знания Почему — совсем не ясно.

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

Я не понял чего ты хотел сказать

I>>Исключительно объемом, т.е. степенью детализации, т.к. знания о предметной области всего лишь модель.
S>Вот тут я не понял — что ещё можно вносить в модель помимо знаний? Почему вы всё ещё заявляете, что у нас нет стабильной информации, раз уже признали её необходимость, пусть и в форме "знаний о предметной области"?

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

Если ты, что называется в теме, то это значит, что тебе известна эта разница. Естественно, точного разделения нет и всегда может быть нечто заранее неизвестное.

I>>Я говорю про то, что твое разделение искусственное. Отталкиваться нужно не от того, специфична ли операция для бизнеса кастомера или нет.
S>Да. Надо отталкиваться от того, инвариантны ли наши знания или нет.

Это общие слова.

S>Да, не можем, до тех пор, пока мы не заведём эту модель явно, и не озаботимся регулярной её верификацией. Конечно, мы можем внести в эту модель нестабильную/или неверную информацию, но мы будем ССЗБ, т.к. рано или поздно модель рассыпется от перегруженности устаревшими сведениями и костылями для обхода неверных решений.

Все это сводится к тому, что в модели надо учитывать важное и неучитывать неважное Спасибо, капитан

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

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

В моем случае её нужно пихнуть туда же, куда и стабильные — в модель данных которая есть часть модели предметной области.

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

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

Ну так в том то и дело, что отдельная модель БЛ это теже самые знания о предметной области, только это функциональная модель предметной области.

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

S>>В итоге получается примерно следущее разделение:
S>>- Модель предметной области определяет основной набор сущностей, инварианты и правила операций.
S>>- Бизнес-логика манипулирует моделью предметной области.

AUD>Ок, вопрос — и что это? Серебрянная пуля? Архитектура для 9x.xx% приложений с определенным набором требований? Описание дел в текущем проекте?

Я вот шота тоже не понимаю чего он хотел сказать, не то свой взгляд на DDD, не то отрицание DDD, не то прояснение DDD

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

S>>Осталось уточнить: что стоит вносить в модель предметной области?

AUD>Для того чтобы получить какие-либо преимущества от использования DDD модель предметной области нужно рассматривать как неделимый синтез данных и поведения.
Речь идёт не о "разделять ли данные и поведение", а о "вносить ли в модель бизнес-специфичные штуки".

AUD>Альтернатива отдельного существования модели данных и поведения как правило требует несколько иных подходов чем те что предполагает DDD.
Как-то удаётся сочетать

AUD>Дело в том, что абсолютизация правильности, стабильности или объективности модели не верна.
Да не собираюсь претендовать на абсолютное знание Если пост производит такое впечатление — мой косяк
Идея проста и тупа до неприличия -представить проверяемые и стабильные знания в виде отдельного артефакта, не размазывая их по всему проекту, казалось бы, о чём спорить? Увы...

S>>В итоге получается примерно следущее разделение:
S>>- Модель предметной области определяет основной набор сущностей, инварианты и правила операций.
S>>- Бизнес-логика манипулирует моделью предметной области.

AUD>Ок, вопрос — и что это? Серебрянная пуля? Архитектура для 9x.xx% приложений с определенным набором требований?
Нет конечно. Максимум — творческое переложение DDD на основе практического опыта. Просто пара товарищей неоднократно пытаются мне доказать, что подобный подход не нужен (с). Только за последние 2 недели обсуждалось в 3х ветках. Чтобы получить хоть какие-то доводы и не засирать весь подфорум, завёл эту.

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

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

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


S>Ваш подход:
S>

S>Вот простая задача — есть склад, есть поставки, есть заказы, скидки и есть возвраты. при возврате товара надо вычислить 1 сумму возвращаемых денег с учетом всех возможных скидок и округлений 2 найти именно ту поставку с которой единица товара прибыла на склад

S>Мой:
S>

S>А что, мы не записываем никаких данных о поставках? Если записываем — в чём проблема найти соответствующую поставку по накладной?

+100500
В бухгалтерии как всегда рулит двойная запись, которая сохраняет вообще говоря все.

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

S>>Осталось уточнить: что стоит вносить в модель предметной области?

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

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

Я как-то устал спорить, поэтому предлагаю остаться при своих

AUD>>Альтернатива отдельного существования модели данных и поведения как правило требует несколько иных подходов чем те что предполагает DDD.
G>Конкретнее, как это выражается в коде?
В коде это как правило выражается в разнице между количеством вводимых доменных сервисов (сервисов манипулирующих entities).

AUD>>Для того чтобы получить какие-либо преимущества от использования DDD модель предметной области нужно рассматривать как неделимый синтез данных и поведения.
S>Речь идёт не о "разделять ли данные и поведение", а о "вносить ли в модель бизнес-специфичные штуки".
А модель сама по себе это не бизнес-специфичная штука?

AUD>>Дело в том, что абсолютизация правильности, стабильности или объективности модели не верна.
S>Да не собираюсь претендовать на абсолютное знание Если пост производит такое впечатление — мой косяк
S>Идея проста и тупа до неприличия -представить проверяемые и стабильные знания в виде отдельного артефакта, не размазывая их по всему проекту, казалось бы, о чём спорить? Увы...
Проверяемость и стабильность это понятные критерии, а вот "размазанность по проекту" это не тянет критерий. То есть направление твоей мысли мне понятно, что ты хочешь достичь я понял, а вот подход жесткого отделения мне не нравится.

Я обычно руководствуюсь следующей идеей — часто добавляемые/изменяемые фичи должно быть легко добавлять/изменять. Но достигаю я это не за счет жесткого отделения от модели а за счет правильного следования SOLID принципам. Например следование OCP (Open/Closed Principle) (и набор известных конвенций) могут свести добавление нового куска бизнес логики к добавлению одного единственного класса (который легко тестируем как в изоляции так и интеграционно). Если же речь идет о совсем динамической и специфической бизнес логике с требованием очень частого изменения, то ее уже можно рассмотреть как внешний по отношению к модели артефакт который добавляется изменяется самими юзерами (с помощью UI или если надо DSL в других формах).

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

AUD>А модель сама по себе это не бизнес-специфичная штука?
Зависит от того, что мы туда вносим. Если ничего, кроме знаний об области деятельности заказчика — нет.

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

А жёсткое разделение — это следствие.
1. Мы получили какие-то стабильные знания, и принимаем на их основе стратегические решения. У нас появляется угроза: ошибка в нашей модели сильно влияет на код/дизайн системы.
2. Чтобы снизить тяжесть последствий, нам надо как можно раньше обнаруживать расхождение знаний с реализуемыми требованиями (и, следовательно, с кодом системы).
3. Единственное решение, которое я вижу — изолировать знания в отдельный артефакт и каким-то способом его верифицировать.
4. Для меня достаточно естественным выглядит использование наших священных знаний при анализе и описании требований. Разумеется, есть и другие способы пополнения/верификации модели — например, те же интервью со специалистами.
Не хватает слов/приходится вводить ad-hoc абстракции — у нас проблема либо с моделью, либо с требованиями.

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

AUD>Я обычно руководствуюсь следующей идеей — часто добавляемые/изменяемые фичи должно быть легко добавлять/изменять. Но достигаю я это не за счет жесткого отделения от модели а за счет правильного следования SOLID принципам.
Увы, это ad-hoc эмпирика. Она рулит при слабых зависимостях/сильной изоляции. Для data-driven софта (особенно если приходится интегрироваться с внешними системами) лучше так не делать.

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

AUD>>>Альтернатива отдельного существования модели данных и поведения как правило требует несколько иных подходов чем те что предполагает DDD.
G>>Конкретнее, как это выражается в коде?
AUD>В коде это как правило выражается в разнице между количеством вводимых доменных сервисов (сервисов манипулирующих entities).
Всего-то? От чего столько шума тогда и куча приседаний DDD?

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

AUD>Я обычно руководствуюсь следующей идеей — часто добавляемые/изменяемые фичи должно быть легко добавлять/изменять. Но достигаю я это не за счет жесткого отделения от модели а за счет правильного следования SOLID принципам. Например следование OCP (Open/Closed Principle) (и набор известных конвенций) могут свести добавление нового куска бизнес логики к добавлению одного единственного класса (который легко тестируем как в изоляции так и интеграционно).
Пример приведешь?

AUD>Если же речь идет о совсем динамической и специфической бизнес логике с требованием очень частого изменения, то ее уже можно рассмотреть как внешний по отношению к модели артефакт который добавляется изменяется самими юзерами (с помощью UI или если надо DSL в других формах).
А если БЛ требует частого изменение, но не юзерами, а программистами?

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

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

AUD>>>>Альтернатива отдельного существования модели данных и поведения как правило требует несколько иных подходов чем те что предполагает DDD.
G>>>Конкретнее, как это выражается в коде?
AUD>>В коде это как правило выражается в разнице между количеством вводимых доменных сервисов (сервисов манипулирующих entities).
G>Всего-то? От чего столько шума тогда и куча приседаний DDD?
Все как обычно — простая идея, много нюансов (не только в коде выражающихся).

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

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

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

AUD>>>>>Альтернатива отдельного существования модели данных и поведения как правило требует несколько иных подходов чем те что предполагает DDD.
G>>>>Конкретнее, как это выражается в коде?
AUD>>>В коде это как правило выражается в разнице между количеством вводимых доменных сервисов (сервисов манипулирующих entities).
G>>Всего-то? От чего столько шума тогда и куча приседаний DDD?
AUD>Все как обычно — простая идея, много нюансов (не только в коде выражающихся).

Много нюансов — значит идея не простая, а только пытается казаться простой.