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

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

Меня этот пример почему то не удивляет

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

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

Это и есть ДДД.

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

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

Наоборот — ты пошел проектировать функции и не стал разбираться.

Вникать в бизнес это значит искать разницу в функциях заявки и заказа.

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

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

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

I>Наоборот — ты пошел проектировать функции и не стал разбираться.
Ты неправ.

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

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

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

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

I>Это и есть ДДД.

Смотря что считать DDD. Сами DDDисты очень ортодоксальны, они считают что труЪ DDD есть только когда в наличии DDD-pattern language, вплоть до CQRS, когда есть ubiquitous language, на котором непременно говорят все итд

Если ты понимаешь под DDD что-то другое, приведи здесь свое понимание.

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

Ув Ikemefula, если вам посраться — вы ошиблись веткой, если интересует ответ — во-первых, аргументируем свои утверждения: с "это херня, я щитаю" спорить не буду за полной бессмысленностью. Во-вторых, читаем то, что написано выше и не придираемся к словам. Я отвечу конеш, но следующие посты в таком же духе буду игнорировать, не обижайтесь.

I>Было бы неплохо увидеть, что по твоему "прибито гвоздями" и "неприбито гвоздями".
Читаем тему.

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

I>С чего это вдруг ?
Вы напишите, что вам непонятно/не нравится, не ленитесь

S>>3. Ограничив модель областью, в которой работает заказчик, мы одновременно получаем и стабильную и объективную информацию для принятия решений...
I>И как это относится к обсуждаемому вопросу ? Модель всегда ограничивается областью с которо работает заказчик.
Намекаю: слово "ограничиваем" имеет несколько значений. Здесь речь идёт о том, что мы не вносим в модель ничего, кроме знаний об области, в которой работает заказчик.

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

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

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

I>Второй вопрос — как эту функцию прибить гвоздями к модели ?
I>Третий вопрос — как это функцию неприбить гвоздями к модели ?
Чтобы предметно ответить, надо разбираться в теме. Если тыкать пальцем в небо: в первом случаев модель вносятся излишние подробности, например, правила поиска товара. Во-втором — нет.

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

I>>Наоборот — ты пошел проектировать функции и не стал разбираться.
G>Ты неправ.

Цитирую "Хотя я зря это делал, надо было выяснять функции а не структуру."

Вот это и значит, что разбираться ты не стал а пошел натягивать функции на структуру.

I>>Вникать в бизнес это значит искать разницу в функциях заявки и заказа.
G>Ну так я и нашел... то что в их структуре никакой разницы, только в операциях, хотя мне еще понадобилось в этом убедить заказчика.

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

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

G>Смотря что считать DDD. Сами DDDисты очень ортодоксальны, они считают что труЪ DDD есть только когда в наличии DDD-pattern language, вплоть до CQRS, когда есть ubiquitous language, на котором непременно говорят все итд

Эвас это тру-ДДД или нет ? Он как то не настаивает на CQRS. Этот вот ubiquitous language сильно упрощает жизнь, т.к. все нестыковки в терминологии проявляются в виде багов и недоделок в коде. Более того, эти нестыковки это основная преграда при проектировании, вот этот самый её и устраняет.

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

S>Ув Ikemefula, если вам посраться — вы ошиблись веткой, если интересует ответ — во-первых, аргументируем свои утверждения: с "это херня, я щитаю" спорить не буду за полной бессмысленностью.

А мог бы ты взять да процитировать, где ты углядел "это херня, я щитаю" в моем ответе ? Просто мне интересно, какие именно фразы тебе не понравились.

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

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

I>>Было бы неплохо увидеть, что по твоему "прибито гвоздями" и "неприбито гвоздями".
S>Читаем тему.
S>

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

I>>С чего это вдруг ?
S>Вы напишите, что вам непонятно/не нравится, не ленитесь

Мне непонятно, откуда ты взял "При этом ответственность за неверные требования неявным образом перекладывается на заказчика".

I>>И как это относится к обсуждаемому вопросу ? Модель всегда ограничивается областью с которо работает заказчик.
S>Намекаю: слово "ограничиваем" имеет несколько значений. Здесь речь идёт о том, что мы не вносим в модель ничего, кроме знаний об области, в которой работает заказчик.

Ты просто другими словами переформулировал Но в целом, с учетом твоего ответа про возвраты, я, вероятно, понял что ты имел ввиду.

S>Не, я даже не знаю как вежливо это откомментить Ну не принято в нормальной дискуссии подменять определения своими и доводить всё до абсурда. Модель данных — это более узкая и более приземлённая штука.

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

У меня это просто — модель предметной области это модель данных, констраинты(полиси, правила и тд) и операции над ними. Операции == BL.

Т.е. модель предметной области это структурная модель + логическая + функциональная.

И совершенно очевидно, что это вовсе не значит, что методы BL будут в самой модели данных. Куда их поместить, подскажет SOLID.

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

Вообще говоря относится непосредственно — это логистика склада.

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

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

I>>Второй вопрос — как эту функцию прибить гвоздями к модели ?
I>>Третий вопрос — как это функцию неприбить гвоздями к модели ?
S>Чтобы предметно ответить, надо разбираться в теме. Если тыкать пальцем в небо: в первом случаев модель вносятся излишние подробности, например, правила поиска товара. Во-втором — нет.

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

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

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


G>А и не надо все пихать в базу в принципе. Даже в модель не надо. Большинство проверок являются не инвариантами вообще говоря, а предусловиями для некоторых операций. Операция меняются, а инварианты нет. Предусловия не нужно заносить в базу, а инварианты можно.
это ты предложил проверку заполнения поля оформить в качестве check constraints. Или мы друг друга не поняли?

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

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

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

G>>А как же DDD? и ubiquitous language? Получается то с заказчиком общаемся на одном языке, а внутри команды разработки — на другом.
G>>Это ты говоришь как раз про анти-DDD, когда существует преобразование между "бизнесом" и "архитектурой\дизайном", причем далеко не всегда биективное.
G>>DDD пытаешься привести все к одному знаменателю.
A>Возможно я неправильно выразился, сделать по своему в данном случае — это значит решить использовать одну таблицу или две. На язык общения это никак не повлияет. В данном случае это чисто технический вопрос организации репозитория.
Дополню немного... язык здесь будет выражен в объектах (заявка и заказ), а как они будут маппиться в базу — это отдельный вопрос

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

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

G>>А как же DDD? и ubiquitous language? Получается то с заказчиком общаемся на одном языке, а внутри команды разработки — на другом.
G>>Это ты говоришь как раз про анти-DDD, когда существует преобразование между "бизнесом" и "архитектурой\дизайном", причем далеко не всегда биективное.
G>>DDD пытаешься привести все к одному знаменателю.
A>Возможно я неправильно выразился, сделать по своему в данном случае — это значит решить использовать одну таблицу или две. На язык общения это никак не повлияет. В данном случае это чисто технический вопрос организации репозитория.
Это не только технический вопрос. Если у нас есть ubiquitous language то все (подчеркиваю ВСЕ) общение между заказчиками и разработчиками происходит на этом языке, и если в языке две сущности, то разработчик, который недавно влился в команду, и не будет знать по какой причине у нас будет один репозиторий на две сущности. То есть неявно будет присутствовать преобразование межу этим ubiquitous language и тем что делают программисты.


G>>А и не надо все пихать в базу в принципе. Даже в модель не надо. Большинство проверок являются не инвариантами вообще говоря, а предусловиями для некоторых операций. Операция меняются, а инварианты нет. Предусловия не нужно заносить в базу, а инварианты можно.
A>это ты предложил проверку заполнения поля оформить в качестве check constraints. Или мы друг друга не поняли?
Не поняли, чтобы понять надо ответить зачем нужна проверка заполнения формы?
Сразу будет понятно что стоит можно (не значит что нужно) в check пихать, а что нельзя.

G>>Только заранее ты не можешь определить глубину вникания, особенно если бизнес нетривальный, а задача может оказаться вполне поверхностной.
A>я и не спорю, везде нужно искать оптимальные варианты. Единого рецепта нет. Но разбираться в бизнесе надо. Насколько тщательно и детально — смотреть по обстановке.
Вот именно, а чтобы оценить обстановку надо писать код\проектировать приложение (не модель), до той степени пока не упрешься в незнание.

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

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

G>>Смотря что считать DDD. Сами DDDисты очень ортодоксальны, они считают что труЪ DDD есть только когда в наличии DDD-pattern language, вплоть до CQRS, когда есть ubiquitous language, на котором непременно говорят все итд

I>Эвас это тру-ДДД или нет ?
Что значит "эванс"? Это паттерн, формальная методология или что? Это просто человек, который зарабатывает тем что впаривает нечто, что называется DDD.

I>Этот вот ubiquitous language сильно упрощает жизнь, т.к. все нестыковки в терминологии проявляются в виде багов и недоделок в коде. Более того, эти нестыковки это основная преграда при проектировании, вот этот самый её и устраняет.
Но путь к нему тернист и сама выработка этого языка может вылиться в обучение разработчиков или перестраивание процессов бизнеса. И то и другое может быть на порядок дороже, чем держать аналитика для преобразования из языка бизнеса в язык разработчиков.

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

G>Это не только технический вопрос. Если у нас есть ubiquitous language то все (подчеркиваю ВСЕ) общение между заказчиками и разработчиками происходит на этом языке, и если в языке две сущности, то разработчик, который недавно влился в команду, и не будет знать по какой причине у нас будет один репозиторий на две сущности. То есть неявно будет присутствовать преобразование межу этим ubiquitous language и тем что делают программисты.
Видимо у меня другое понимание общения с заказчиком. На мой взгляд, заказчику все равно, как ты будешь хранить. То есть ты должен обеспечить хранение как заявок, так и заказов с необходимой производительностью. Точка. А как их записывать и считывать — заказчику до лампочки, хоть голубиной почтой (шутка юмора, вовсе не сарказм ) Технические детали реализации заказчика не должны волновать и никаких противоречий я тут не вижу. Ты общаешься с заказчиком на его языке, с разработчиками на этом же самом языке (ведь заявки и заказы остаются в поле обсуждения всех сторон), обсуждаешь что и как (в плане бизнес-логики) должны делать эти заказы, заявки. Это все верно. Но репозиторий — это инфраструктурный уровень. И вариантов хранения этих сущностей тьма — одна таблица; по одной на каждую; три таблицы (одна с общей частью). Какой бы ты вариант не выбрал, предметная область от этого не изменится и заказчик этого даже не заметит. Но от твоего выбора будет зависеть дальнейшее развитие проекта в техническом плане (возможности внедрения будущих фич, простота поддержки и т.д.), и ты как специалист, должен сделать выбор правильно — заказчик в этом тебе не помощник.

G>Не поняли, чтобы понять надо ответить зачем нужна проверка заполнения формы?
G>Сразу будет понятно что стоит можно (не значит что нужно) в check пихать, а что нельзя.
Формы тут ни при чем. Пример был простой. Давай снова его опишу. Допустим, заказчик решит, что заявку можно заполнить с минимумом данных. Например, id клиента, который необходим в заказе, но на стадии заявки его еще нет — есть просто ФИО. Пример взят с потолка, но вполне жизненно. Но у тебя обе сущности находятся в одной таблице. Снимать обязательность заполнения id клиента заодно и в заказе тоже неправильно. Решать с помощью констрейнта — тоже криво, имхо. Напомню, этот пример был просто для демонстрации неочевидности хранения заказов и заявок именно в одной таблице, не более того... А то, я чувствую, мы отходим от темы.

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

I>А мог бы ты взять да процитировать, где ты углядел "это херня, я щитаю" в моем ответе ? Просто мне интересно, какие именно фразы тебе не понравились.
Да в каждом абзаце:

Утверждение взято с потолка.
...
С чего это вдруг ?
...
S>- Модель предметной области определяет основной набор сущностей, инварианты и правила операций.
это называется модель данных...

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

---

I>Мне непонятно, откуда ты взял "При этом ответственность за неверные требования неявным образом перекладывается на заказчика".
Ок. Цитата:

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

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

---

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

Разница примерно та же, что и между концептуальной/логическими моделями в ANSI/SPARC. Модель данных отражает только часть знаний о предметной области, причём представляет эти знания в форме, удобной для работы с данными. А модель предметной области — это знания в чистом виде: само по себе бесполезно, но с его помощью можно делать весьма полезные штуки — те же модели данных, например.

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

---

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

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

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

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

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

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

Это к вопросу о "что такое — прибивать гвоздями", если что

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

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

G>>Это не только технический вопрос. Если у нас есть ubiquitous language то все (подчеркиваю ВСЕ) общение между заказчиками и разработчиками происходит на этом языке, и если в языке две сущности, то разработчик, который недавно влился в команду, и не будет знать по какой причине у нас будет один репозиторий на две сущности. То есть неявно будет присутствовать преобразование межу этим ubiquitous language и тем что делают программисты.
A>Видимо у меня другое понимание общения с заказчиком. На мой взгляд, заказчику все равно, как ты будешь хранить. То есть ты должен обеспечить хранение как заявок, так и заказов с необходимой производительностью. Точка. А как их записывать и считывать — заказчику до лампочки, хоть голубиной почтой (шутка юмора, вовсе не сарказм ) Технические детали реализации заказчика не должны волновать и никаких противоречий я тут не вижу. Ты общаешься с заказчиком на его языке, с разработчиками на этом же самом языке (ведь заявки и заказы остаются в поле обсуждения всех сторон), обсуждаешь что и как (в плане бизнес-логики) должны делать эти заказы, заявки. Это все верно. Но репозиторий — это инфраструктурный уровень. И вариантов хранения этих сущностей тьма — одна таблица; по одной на каждую; три таблицы (одна с общей частью). Какой бы ты вариант не выбрал, предметная область от этого не изменится и заказчик этого даже не заметит. Но от твоего выбора будет зависеть дальнейшее развитие проекта в техническом плане (возможности внедрения будущих фич, простота поддержки и т.д.), и ты как специалист, должен сделать выбор правильно — заказчик в этом тебе не помощник.
Ну правильно ты говоришь, но это не ubiquitous language и не DDD. В принципе та проблема, которая у меня возникла и в DDD решается через нетривиальные маппинги и наследование, но остается проблема "смены типа", когда "предзаказ" становится "заказом".

G>>Не поняли, чтобы понять надо ответить зачем нужна проверка заполнения формы?
G>>Сразу будет понятно что стоит можно (не значит что нужно) в check пихать, а что нельзя.
A>Формы тут ни при чем. Пример был простой. Давай снова его опишу. Допустим, заказчик решит, что заявку можно заполнить с минимумом данных. Например, id клиента, который необходим в заказе, но на стадии заявки его еще нет — есть просто ФИО. Пример взят с потолка, но вполне жизненно. Но у тебя обе сущности находятся в одной таблице. Снимать обязательность заполнения id клиента заодно и в заказе тоже неправильно. Решать с помощью констрейнта — тоже криво, имхо. Напомню, этот пример был просто для демонстрации неочевидности хранения заказов и заявок именно в одной таблице, не более того... А то, я чувствую, мы отходим от темы.
Еще раз. Зачем заполнять данными? Если это будут инварианты, которые вообще всегда должны выполняться, то можно и в check засунуть, хотя я бы не стал. Если это предусловия для операций, то не их вообще в базу пихать.

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

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

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

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

G>>>А как же DDD? и ubiquitous language? Получается то с заказчиком общаемся на одном языке, а внутри команды разработки — на другом.
G>>>Это ты говоришь как раз про анти-DDD, когда существует преобразование между "бизнесом" и "архитектурой\дизайном", причем далеко не всегда биективное.
G>>>DDD пытаешься привести все к одному знаменателю.
A>>Возможно я неправильно выразился, сделать по своему в данном случае — это значит решить использовать одну таблицу или две. На язык общения это никак не повлияет. В данном случае это чисто технический вопрос организации репозитория.
A>Дополню немного... язык здесь будет выражен в объектах (заявка и заказ), а как они будут маппиться в базу — это отдельный вопрос
Ага. Если это одна сущность, то у нее поменяется флаг при переходе от "заявки" к "заказу". А вот если это сущности разные (то есть разные классы), то придется удалить один объект, создать другой, поменять все ссылки дочерних сущностей.

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

G>Ну правильно ты говоришь, но это не ubiquitous language и не DDD. В принципе та проблема, которая у меня возникла и в DDD решается через нетривиальные маппинги и наследование, но остается проблема "смены типа", когда "предзаказ" становится "заказом".
Я изначально предполагал, что это разные типы. И, честно говоря, не вижу причин использовать один тип для разных бизнес-процессов. Хотя тебе конечно же виднее. Не пронял проблемы со сменой типа, в чем она? Метод PreOrder.CreateOrder() или что-нибудь в этом роде не подходит в твоём случае?
По поводу "но это не ubiquitous language и не DDD" — смотри последний абзац.

G>Еще раз. Зачем заполнять данными? Если это будут инварианты, которые вообще всегда должны выполняться, то можно и в check засунуть, хотя я бы не стал. Если это предусловия для операций, то не их вообще в базу пихать.
G>А насчет id клиента — лучше при создании любого заказа сразу записывать клиента в базу. Адекватный пример без понимания зачем оно делается ты не придумаешь.
Я же и говорю, что пример с потолка. Можно придумать множество вариантов, когда использование одной таблицы двумя типами из разных бизнес-процессов сгенерит проблемы в будущем. Но поскольку ты общался с заказчиком, а не я, твоё решение может быть верным. Я всего лишь отметил неочевидность этой проблемы.

Предлагаю подвести итог дискуссии. Я считаю, что DDD и проектирование БД это разные процессы, но это не значит что они не влияют друг на друга. Проектируя объекты, надо выбирать разумное сочетание этих процессов. Технические сложности инфраструктуры доступа к БД должны быть решены в отдельности от домена и не загромождать код модели. Я рассматриваю БД (согласно Эвансу), как инфраструктуру записи и восстановления объектов, не более. И структура БД не должна делать свой отпечаток ни на модели, ни на языке — обратный процесс естественен. Это моя центральная мысль, которую я хотел озвучить. Можешь тоже, кстати, подвести некий итог своей точки зрения и на этом остановиться

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

G>Ага. Если это одна сущность, то у нее поменяется флаг при переходе от "заявки" к "заказу". А вот если это сущности разные (то есть разные классы), то придется удалить один объект, создать другой, поменять все ссылки дочерних сущностей.

см. моё сообщение здесь

Автор: andry81
Дата: 27.12.10

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

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

G>>Ну правильно ты говоришь, но это не ubiquitous language и не DDD. В принципе та проблема, которая у меня возникла и в DDD решается через нетривиальные маппинги и наследование, но остается проблема "смены типа", когда "предзаказ" становится "заказом".
A>Я изначально предполагал, что это разные типы.
Изначально я тоже такое предполагал, но не стал в итоге так делать.

A>Не пронял проблемы со сменой типа, в чем она? Метод PreOrder.CreateOrder() или что-нибудь в этом роде не подходит в твоём случае?
Проблема в том что "смена типа" в ЯП незаконная операция, поэтому если у тебя есть TPH для смены типа тебе надо удалить запись и добавить новую, которая отличается только значением дискриминатора. Потеря эффективности на пустом месте.

A>Предлагаю подвести итог дискуссии.
Ок.

A>Я считаю, что DDD и проектирование БД это разные процессы, но это не значит что они не влияют друг на друга.
А я считаю что проектирование ВСЕГО приложения это один процесс, вместе с хранилищем итп.

A>Проектируя объекты, надо выбирать разумное сочетание этих процессов. Технические сложности инфраструктуры доступа к БД должны быть решены в отдельности от домена и не загромождать код модели.
Да они и так решены отдельно, сейчас почти для всех языков есть ORMы. Только ORM тоже надо уметь использовать, но не убирает импенданс "Data != Objects", он пытается его скрыть (не всегда).

A>Я рассматриваю БД (согласно Эвансу), как инфраструктуру записи и восстановления объектов, не более. И структура БД не должна делать свой отпечаток ни на модели, ни на языке — обратный процесс естественен. Это моя центральная мысль, которую я хотел озвучить. Можешь тоже, кстати, подвести некий итог своей точки зрения и на этом остановиться
Это теория, а практика как раз показывает что имеет. Думаешь почему был придуман CQRS? И другие хитрости, не описанные у эванса и фаулера.