Заведу ветку, чтобы _один_ раз обсудить, и, наконец, закрыть (с моей стороны) эту тему.
Начнём?
Domain-driven design основывается на том, что сложность разработки программ в первую очередь определяется не средствами разработки, а сложностью самой проблемы. Эванс сформулировал идею в 2х тезисах:
1. For most software projects, the primary focus should be on the domain and domain logic.
2. Complex domain designs should be based on a model.
Мне нравятся предлагаемые Эвансом подходы:
— выделение модели предметной области в самостоятельный артефакт;
— использование общей модели для представления основных знаний об автоматизируемой предметной области;
— использование языка на основе модели везде где только можно;
— использование модели для принятия основных решений по дизайну ПО;
— использование микроитераций для уточнения и детализации модели;
— интервью со специалистами в автоматизируемой области как способ взаимной проверки модели и требований;
— активное прототипирование для уточнения и проверки модели и требований.
Осталось уточнить: что стоит вносить в модель предметной области?
Эванс определяет предметную область как
That subject area to which the user applies the program is the domain of the software.
и, чуть ниже:
Domain Layer (or Model Layer)
Responsible for representing concepts of the business, information about
the business situation, and business rules. State that reflects the business
situation is controlled and used here, even though the technical details of
storing it are delegated to the infrastructure. This layer is the heart of
business software.
Другими словами, Эванс как минимум не против того, чтобы включать бизнес-логику в состав модели. Многие авторы, например, Casey Charlton (aka Jak Charlton) вообще объявляют джихад анемик-модели:
So Entities and Value Objects Just Store Data?
Definitely not! The point of DDD is to create a rich Domain – if you only stored data in your
Entities and Value Objects, you would have an anaemic domain model – one of the primary
anti-patterns to DDD.
Лично я резко против того, чтобы вносить в модель особенности бизнес-логики заказчика. Доводы нехитрые:
1. Цель внедрения ПО — автоматизация части деятельности заказчика. На момент внедрения бизнес-логика либо отсутствует в явном виде (если заказчик не расписал основные процессы), или соответствует текущим, неавтоматизированным процессам. После внедрения может понадобиться расширить область автоматизации, или реализовать пожелания заказчика, в принципе невозможные при "ручной" обработке. С дизайном, прибитым гвоздями к предыдущей модели бизнес-логики, это будет весьма весёлым занятием.
2. Большинство из виденных методологий разработки предполагает работу с заказчиком, как с чёрным ящиком: получаем непредсказуемый набор требований, выдаём прототип, и крутимся в петле улучшений до тех пор, пока не придём к компромиссу. При этом ответственность за неверные требования неявным образом перекладывается на заказчика: "чего попросили, то и получили". Если мы не можем объективно отличить значимые требования от незначимых — как мы можем гарантировать правильность построенной модели и принятых на её основе решений?
3. Заказчик никогда не работает в вакууме. Вне зависимости от его желаний, его бизнес ограничен множеством объективно существующих правил и ограничений. И, волей-неволей, заказчик вынужден к ним приспосабливаться. Ограничив модель областью, в которой работает заказчик, мы одновременно получаем и стабильную и объективную информацию для принятия решений, и способ оценки требований заказчика с точки зрения предметной области бизнеса, и способ обезопасить себя от будущих изменений в бизнес-логике.
В итоге получается примерно следущее разделение:
— Модель предметной области определяет основной набор сущностей, инварианты и правила операций.
— Бизнес-логика манипулирует моделью предметной области.
Пожалуйста, давайте не будем засирать ветку личными разборками и оффтопом вида "для владельца трекера проектирование сетей — это не его бизнес", "нет никакой границы между бизнес-логикой и областью деятельности заказчика" и "нечего дизайнить, когда достаточно анализа требований". Заранее спасибо!
Ну что ж, давайте сюда мои ошибки и заблуждения
Re: [DDD] Вносить ли бизнес-логику в модель предметной облас
Здравствуйте, Sinix, Вы писали:
S>Заведу ветку, чтобы _один_ раз обсудить, и, наконец, закрыть (с моей стороны) эту тему.
S>Начнём?
S>Domain-driven design основывается на том, что сложность разработки программ в первую очередь определяется не средствами разработки, а сложностью самой проблемы. Эванс сформулировал идею в 2х тезисах: S>
S>1. For most software projects, the primary focus should be on the domain and domain logic.
S>2. Complex domain designs should be based on a model.
S>Мне нравятся предлагаемые Эвансом подходы: S>- выделение модели предметной области в самостоятельный артефакт; S>- использование общей модели для представления основных знаний об автоматизируемой предметной области; S>- использование языка на основе модели везде где только можно; S>- использование модели для принятия основных решений по дизайну ПО; S>- использование микроитераций для уточнения и детализации модели; S>- интервью со специалистами в автоматизируемой области как способ взаимной проверки модели и требований; S>- активное прототипирование для уточнения и проверки модели и требований.
S>
S>Осталось уточнить: что стоит вносить в модель предметной области? S>Эванс определяет предметную область как S>
S>That subject area to which the user applies the program is the domain of the software.
S>и, чуть ниже: S>
S>Domain Layer (or Model Layer)
S>Responsible for representing concepts of the business, information about
S>the business situation, and business rules. State that reflects the business
S>situation is controlled and used here, even though the technical details of
S>storing it are delegated to the infrastructure. This layer is the heart of
S>business software.
S>Другими словами, Эванс как минимум не против того, чтобы включать бизнес-логику в состав модели. Многие авторы, например, Casey Charlton (aka Jak Charlton) вообще объявляют джихад анемик-модели: S>
S>So Entities and Value Objects Just Store Data?
S>Definitely not! The point of DDD is to create a rich Domain – if you only stored data in your
S>Entities and Value Objects, you would have an anaemic domain model – one of the primary
S>anti-patterns to DDD.
S> S>Лично я резко против того, чтобы вносить в модель особенности бизнес-логики заказчика. Доводы нехитрые:
S>1. Цель внедрения ПО — автоматизация части деятельности заказчика. На момент внедрения бизнес-логика либо отсутствует в явном виде (если заказчик не расписал основные процессы), или соответствует текущим, неавтоматизированным процессам. После внедрения может понадобиться расширить область автоматизации, или реализовать пожелания заказчика, в принципе невозможные при "ручной" обработке. С дизайном, прибитым гвоздями к предыдущей модели бизнес-логики, это будет весьма весёлым занятием.
S>2. Большинство из виденных методологий разработки предполагает работу с заказчиком, как с чёрным ящиком: получаем непредсказуемый набор требований, выдаём прототип, и крутимся в петле улучшений до тех пор, пока не придём к компромиссу. При этом ответственность за неверные требования неявным образом перекладывается на заказчика: "чего попросили, то и получили". Если мы не можем объективно отличить значимые требования от незначимых — как мы можем гарантировать правильность построенной модели и принятых на её основе решений?
S>3. Заказчик никогда не работает в вакууме. Вне зависимости от его желаний, его бизнес ограничен множеством объективно существующих правил и ограничений. И, волей-неволей, заказчик вынужден к ним приспосабливаться. Ограничив модель областью, в которой работает заказчик, мы одновременно получаем и стабильную и объективную информацию для принятия решений, и способ оценки требований заказчика с точки зрения предметной области бизнеса, и способ обезопасить себя от будущих изменений в бизнес-логике.
S>В итоге получается примерно следущее разделение: S>- Модель предметной области определяет основной набор сущностей, инварианты и правила операций. S>- Бизнес-логика манипулирует моделью предметной области.
S>
S>Пожалуйста, давайте не будем засирать ветку личными разборками и оффтопом вида "для владельца трекера проектирование сетей — это не его бизнес", "нет никакой границы между бизнес-логикой и областью деятельности заказчика" и "нечего дизайнить, когда достаточно анализа требований". Заранее спасибо!
S>Ну что ж, давайте сюда мои ошибки и заблуждения
Видимо тоже скоро книги писать будешь, как фаулер или эванс. Из длинючего поста не понял как собственно писать то надо. Как указанные выше концепции отражаются в коде?
Я вот предлагаю простое решение: мухи отдельно — котлеты отдельно данные отдельно — логика отдельно. Для запросов используется передача QueryObject от DAL до PL, в обратную сторону распространяется "контекст", который включает данные о пользователе, тип операции итп. Для изменения данных вызываются методы, которые возвращают void или статусное сообщение, оркестрацией нетривиальных транзакций занимается слой между PL и BL (обычно именуемый слоем сервисов). Все cross-cutting concerns, те аспекты, пронизывающие слои приложения, вносятся только через AOP.
Сами данные начинаются моделью данных в БД в виде классов, дополняются такими же plain-объектами на более высоких слоях по необходимости.
Re: [DDD] Вносить ли бизнес-логику в модель предметной облас
Здравствуйте, Sinix, Вы писали:
S>Ну что ж, давайте сюда мои ошибки и заблуждения
Тут есть один нюанс. DDD, как следует из его определения от того же Эванса, хорошо работает только в тех случаях, когда предметная область хорошо формализована. Такие случаи конечно есть, но их можно перечесть по пальцам. Это там, где за автоматизацией следят не сами заказчики, а какая-нибудь еще внешняя организация, которая кровно заинтересована в адекватности аудита (софт для автоматизации обязанный поддержать сертификацию на соответствие бизнес-процессов каким-либо стандартам и все такое). В таких областях все модели и термины отлиты из бронзы за долго до того как была написана первая строчка кода.
А в реальности там происходит все еще круче — не софт пришется под конкретные бизнес-процессы, а эти самые процессы подгоняются под уже написанный софт, так как софт соответствует тем самым заранее написанным стандартам, а реальные процессы — фиг его знает. Очевидно это не гражданские задачи, отсюда, кстати и сложившееся мнение о том, что DDD хорошо подходит для "энтерпрайз" конструкций.
В подавляющем же большинстве реальных задач DDD в том виде, в котором его понимает большинство неофитов открывших для себя Фаулера, натыкается ровно на те проблемы, которые ты описал. Например, от трех специалистов по предметной области ты получишь примерно семь описаний того как все на самом деле работает, ни о какой общей терминологии и речи не идет даже в рамках одного отдела, не говоря уже о каком либо описании реально происходящих бизнес-процессов.
На этом этапе мы кладем Эванса под правую ножку стола, чтобы не качался, засучиваем рукава и начинаем писать как в школе учили — SOLID и все такое. А потом смотрим на результат. Если в результате получилось DDD, ну и слава байту, можно считать что свои тридцать баксов эванс честно заработал, а если нет — то это проблемы DDD, а не твоего приложения.
На мой взгляд проблема DDD в том, что это слишком "высокоуровневый" паттерн. И в силу этого, он просто не может подходить для широкого круга задач. С другой же стороны, именно эта высокоуровневость разъедает неокрепший мозг — кажется, что руководствуясь относительно простыми правилами ты в любом случае получишь идеальный софт и опять таки, если что, то всегда есть отмазка — это не ты не правильно написал, это тебе краеведы по предметной области не так объяснили.
На всякий случай, еще раз повторю свою мысль. DDD (как бы кто его не понимал) — это не то, чем нужно руководствоваться при написании и стараться этому соответствовать во что бы ни стало, DDD — это то, что может получиться (или не получиться), если следовать базовым good practice при создании приложения.
Мы уже победили, просто это еще не так заметно...
Re[2]: [DDD] Вносить ли бизнес-логику в модель предметной об
G>Видимо тоже скоро книги писать будешь, как фаулер или эванс. Из длинючего поста не понял как собственно писать то надо.
Не-не-не, не пугайте И так в один пост упихнул слишком много — читается отвратительно Если разбавить водой, чтобы легче воспринималось, вообще никто читать не будет.
G>Как указанные выше концепции отражаются в коде?
На практике DDD ортогонален технике разработки — в первую очередь он отражается на подходах к проектированию.
. Для веб-софта я боюсь советовать что-то определённое. Во-первых опыта тут несравнимо меньше. Во-вторых, для десктопа можно пожертвовать практическими соображениями ради задела на будущее. А вот и без того загруженные под завязку сервера мне жалко
G>Я вот предлагаю простое решение: мухи отдельно — котлеты отдельно данные отдельно — логика отдельно.
+100500
G>Для запросов используется передача QueryObject от DAL до PL...
Вот что-то такое для stateless-обработки и придётся делать, иначе практически никак.
Re[2]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, IB, Вы писали:
IB>Тут есть один нюанс. DDD, как следует из его определения от того же Эванса, хорошо работает только в тех случаях, когда предметная область хорошо формализована. ... А в реальности там происходит все еще круче — не софт пришется под конкретные бизнес-процессы, а эти самые процессы подгоняются под уже написанный софт, так как софт соответствует тем самым заранее написанным стандартам, а реальные процессы — фиг его знает.
Тыщщу раз да — я работаю именно в таких условиях
DDD (или то, что я понимаю под DDD) пока что не вызывает никаких проблем.
IB>Например, от трех специалистов по предметной области ты получишь примерно семь описаний того как все на самом деле работает, ни о какой общей терминологии и речи не идет даже в рамках одного отдела, не говоря уже о каком либо описании реально происходящих бизнес-процессов.
Да, мы просто не пытаемся запихнуть в модель слишком многое. И явно указываем, когда часть хотелок выглядят странными (мы не можем нормально их описать и реализовать) или явно выходят за границы деятельности заказчика. А ещё очень забавно (печально забавно) нечаянно стравливать специалистов между собой и участвовать в получившемся перетягивании каната
IB>На этом этапе мы кладем Эванса под правую ножку стола, чтобы не качался, засучиваем рукава и начинаем писать как в школе учили — SOLID и все такое.
Ну да, я тоже стараюсь относиться к Эвансу без фанатизма. DDD меня зацепило тем, что у меня сначала сложился работающий (для меня) подход к разработке, исключительно из практического опыта решения граблей, а уже затем мне попалась его книжка с практически теми же подходами.
IB>На всякий случай, еще раз повторю свою мысль. DDD (как бы кто его не понимал) — это не то, чем нужно руководствоваться при написании и стараться этому соответствовать во что бы ни стало, DDD — это то, что может получиться (или не получиться), если следовать базовым good practice при создании приложения.
Спасибо!
Re[3]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, Sinix, Вы писали:
G>>Как указанные выше концепции отражаются в коде? S>На практике DDD ортогонален технике разработки — в первую очередь он отражается на подходах к проектированию.
Это какая-то неизвестная мне практика. Вот смотрел видео с конференций, так там пропагандируют "ортодоксальный" DDD, когда необходимо использовать только DDD-шный pattern language.
Re[4]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, gandjustas, Вы писали:
G>Это какая-то неизвестная мне практика. Вот смотрел видео с конференций, так там пропагандируют "ортодоксальный" DDD, когда необходимо использовать только DDD-шный pattern language.
В таком случае, я далёк от тру-DDD Нет, язык на основе модели используется, но только потому, что так удобно. Если очередное требование плохо укладывается в модель — то это сразу видно, остаётся разобраться: либо заказчик хочет странного, либо мы накосячили с самой моделью. Таки вещи лучше обнаружить сразу, не дожидаясь, пока проблемы проявят себя во время реализации.
Киньте плиз ссылку на видео!
Re[5]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Это какая-то неизвестная мне практика. Вот смотрел видео с конференций, так там пропагандируют "ортодоксальный" DDD, когда необходимо использовать только DDD-шный pattern language.
S>В таком случае, я далёк от тру-DDD Нет, язык на основе модели используется, но только потому, что так удобно. Если очередное требование плохо укладывается в модель — то это сразу видно, остаётся разобраться: либо заказчик хочет странного, либо мы накосячили с самой моделью. Таки вещи лучше обнаружить сразу, не дожидаясь, пока проблемы проявят себя во время реализации.
S>Киньте плиз ссылку на видео!
http://domaindrivendesign.org/library/young_2010
Кстаи отдает сильным когнитивным диссонансом, проблем много, но всегда в оправдание ставится недостаточная DDDнутость решения и программистов. Хотя чем больше DDDнутости, тем больше проблем.
Re[6]: [DDD] Вносить ли бизнес-логику в модель предметной об
G>http://domaindrivendesign.org/library/young_2010 G>Кстаи отдает сильным когнитивным диссонансом, проблем много, но всегда в оправдание ставится недостаточная DDDнутость решения и программистов. Хотя чем больше DDDнутости, тем больше проблем.
Спасибо, посмотрю, хотя попытка свалить проблемы на неготовых к священной истине девелоперов уже настроила предвзято Почему-то вспомнил про старую статейку Амблера про аджиль, базы данных, и отсталых дба, неготовых к элементарному рефакторингу
Re: [DDD] Вносить ли бизнес-логику в модель предметной облас
Здравствуйте, Sinix, Вы писали:
S>Лично я резко против того, чтобы вносить в модель особенности бизнес-логики заказчика.
Я решил что для обсуждения давайте найдем общий ubiquitous language (c)
Я правильно понимаю, что под моделью вы понимаете набор классов представляющий сущности из предметной области, т.е. в "типичном бизнес-приложении" классы типа Customer, Order и т.д.?
Под "вносить в модель особенности бизнес-логики" что вы понимаете? Наделение классов-сущностей предметной области методами выполняющими определенную бизнес-логику?
Правильно ли я понимаю, что вы предлагаете классы-сущности и слой бизнес-логики разделить по разным сборкам, например в DomainModel.dll и BusinessLogic.dll ?
Если вопросы глупые, то сорри, либо я не телепат, либо опыта не хватает
S>Доводы нехитрые: S>1. Цель внедрения ПО — автоматизация части деятельности заказчика. На момент внедрения бизнес-логика либо отсутствует в явном виде (если заказчик не расписал основные процессы), или соответствует текущим, неавтоматизированным процессам. После внедрения может понадобиться расширить область автоматизации, или реализовать пожелания заказчика, в принципе невозможные при "ручной" обработке. С дизайном, прибитым гвоздями к предыдущей модели бизнес-логики, это будет весьма весёлым занятием.
Давайте пожалуйста чуть подробнее, можно с примерами. Не все тут телепаты и опытные архитекторы
S>2. Большинство из виденных методологий разработки предполагает работу с заказчиком, как с чёрным ящиком: получаем непредсказуемый набор требований, выдаём прототип, и крутимся в петле улучшений до тех пор, пока не придём к компромиссу. При этом ответственность за неверные требования неявным образом перекладывается на заказчика: "чего попросили, то и получили". Если мы не можем объективно отличить значимые требования от незначимых — как мы можем гарантировать правильность построенной модели и принятых на её основе решений?
А как этот абзац связан с вопросом внесения бизнес-логики в модель? Объясните пожалуйста.
S>3. Заказчик никогда не работает в вакууме. Вне зависимости от его желаний, его бизнес ограничен множеством объективно существующих правил и ограничений. И, волей-неволей, заказчик вынужден к ним приспосабливаться. Ограничив модель областью, в которой работает заказчик, мы одновременно получаем и стабильную и объективную информацию для принятия решений, и способ оценки требований заказчика с точки зрения предметной области бизнеса, и способ обезопасить себя от будущих изменений в бизнес-логике.
Опять же, слабо улавливаю связь абзаца с темой топика. Можно объяснить (можно с примерами) для тех кто в танке?
S>В итоге получается примерно следущее разделение: S>- Модель предметной области определяет основной набор сущностей, инварианты и правила операций. S>- Бизнес-логика манипулирует моделью предметной области.
Ну да, кажется я правильно понял (то что уточнял в начале этого поста).
Правильно ли я понимаю, что ваша тема это тоже самое что извечное Anemic domain model vs Reach domain model?
Кстати, DDD меня почему-то не впечатлило. Помню как с горящими глазами распечатал книжку Эванса, но с каждым последующим прочтенным десятком страниц огонь в глазах все потухал... Не помню в чем была причина, может быть в том, что показалось что слишком много условий накладывает подход, может быть показалось что на практике в разных местах будут всплывать проблемы и подводные камни, к сожалению не помню.. В общем по true DDD писать не стал (хотя некоторые пересечения есть), продолжил делать как делал — ведь главное, это чтобы ваш подход был удобен для вас, т.е. чтобы вам и программистам в вашей команде было удобно имплементировать бизнес-задачи, а уж как оно будет называться DDD, или Vasya Pupkin Design — это неважно.
Re[2]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, MozgC, Вы писали:
MC>Под "вносить в модель особенности бизнес-логики" что вы понимаете? Наделение классов-сущностей предметной области методами выполняющими определенную бизнес-логику?
У меня для этого есть очень хороший пример. Один раз мне заказчик рассказывал про две сущности "заявка" (так называли pre-order) и "заказ" (собственно order). Причем заказчик утверждал что это совершенно разные сущности, хотя по структуре они были идентичными, их отличал только флаг и соответственно отличались методы обработки.
В итоге мне удалось убедить заказчика что между ними принципиально разницы нет и сделали одну сущность. Хотя я зря это делал, надо было выяснять функции а не структуру.
Re[3]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, gandjustas, Вы писали:
G>В итоге мне удалось убедить заказчика что между ними принципиально разницы нет и сделали одну сущность. Хотя я зря это делал, надо было выяснять функции а не структуру.
Ну да, я бы вообще это не обсуждал с заказчиком а сделал одну сущность молча. Хотя если вы пытались лучше понять задачу, то нормально.
Re[4]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, gandjustas, Вы писали:
G>>В итоге мне удалось убедить заказчика что между ними принципиально разницы нет и сделали одну сущность. Хотя я зря это делал, надо было выяснять функции а не структуру.
MC>Ну да, я бы вообще это не обсуждал с заказчиком а сделал одну сущность молча. Хотя если вы пытались лучше понять задачу, то нормально.
Так заказчик говорит: "у нас есть заявки и заказы". Я бы сделал две сущности молча, но чутье не подвело. Хотя надо было не спрашивать чем они отличаются, а спрашивать что с ними делать надо потому что в итоге родилось два сервиса, но работали они с одними данными в одной таблице.
Re[5]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, MozgC, Вы писали:
MC>>Здравствуйте, gandjustas, Вы писали:
G>>>В итоге мне удалось убедить заказчика что между ними принципиально разницы нет и сделали одну сущность. Хотя я зря это делал, надо было выяснять функции а не структуру.
MC>>Ну да, я бы вообще это не обсуждал с заказчиком а сделал одну сущность молча. Хотя если вы пытались лучше понять задачу, то нормально. G>Так заказчик говорит: "у нас есть заявки и заказы". Я бы сделал две сущности молча, но чутье не подвело. Хотя надо было не спрашивать чем они отличаются, а спрашивать что с ними делать надо потому что в итоге родилось два сервиса, но работали они с одними данными в одной таблице.
А по-моему, одна сущность или две — совсем не очевидно... Например, заявка, как я понял, это что-то типа черновика заказа.
Работа с заявкой — это другой бизнес-процесс, нежели работа с заказом. И развитие этих процессов может быть разным. Например, при работе с заявкой могут понадобится дополнительные данные в таблице, которые нужны заказу как зайцу пятая нога. Но тут можно решить проблему доп. таблицей с этими самыми данными.
Еще один пример, допустим заказчик вам скажет: мол хочу, чтобы заявку можно было заполнить с минимумом данных. А у вас таблица одна на двоих, в заказе куча обязательных полей для заполнения. Как тут быть, чтобы обеспечить валидность данных средствами СУБД?
К чему это я? Если заказчик говорит, что есть заявки, а есть заказы — как правило это не пустой звук, и важно понять, почему он делает это разделение. То есть совершенно верно, что "надо было выяснять функции а не структуру". Сама структура может поменяться многократно по ходу детализации задачи.
Re[6]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, andry81, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, MozgC, Вы писали:
MC>>>Здравствуйте, gandjustas, Вы писали:
G>>>>В итоге мне удалось убедить заказчика что между ними принципиально разницы нет и сделали одну сущность. Хотя я зря это делал, надо было выяснять функции а не структуру.
MC>>>Ну да, я бы вообще это не обсуждал с заказчиком а сделал одну сущность молча. Хотя если вы пытались лучше понять задачу, то нормально. G>>Так заказчик говорит: "у нас есть заявки и заказы". Я бы сделал две сущности молча, но чутье не подвело. Хотя надо было не спрашивать чем они отличаются, а спрашивать что с ними делать надо потому что в итоге родилось два сервиса, но работали они с одними данными в одной таблице.
A>А по-моему, одна сущность или две — совсем не очевидно... Например, заявка, как я понял, это что-то типа черновика заказа. A>Работа с заявкой — это другой бизнес-процесс, нежели работа с заказом. И развитие этих процессов может быть разным. Например, при работе с заявкой могут понадобится дополнительные данные в таблице, которые нужны заказу как зайцу пятая нога. Но тут можно решить проблему доп. таблицей с этими самыми данными.
"Заявка" по сути являлась первоначальным состоянием заказа, которое в некоторых случаях могло быть пропущено, и действительно в процессе участвовали разные люди, использовали разные формы итп. Но не это важно, важно что заказчик был уверен что сущности разные и долго мне это пытался доказать, хотя про структуре они оказались 100% идентичными.
A>Еще один пример, допустим заказчик вам скажет: мол хочу, чтобы заявку можно было заполнить с минимумом данных. А у вас таблица одна на двоих, в заказе куча обязательных полей для заполнения. Как тут быть, чтобы обеспечить валидность данных средствами СУБД?
check constraints
A>К чему это я? Если заказчик говорит, что есть заявки, а есть заказы — как правило это не пустой звук, и важно понять, почему он делает это разделение. То есть совершенно верно, что "надо было выяснять функции а не структуру".
Тут как раз есть два подхода — вникать в бизнес (может быть очень долго), не вникать в бизнес и сначала спроектировать функции, а потом разбираться с чем они работают углубляясь в реализацию.
Я фактически пошел по первому пути.
A>Сама структура может поменяться многократно по ходу детализации задачи.
Структура поменяется даже если её выяснить заранее Только если мы прибиваем к структуре функции в стиле ООП, то менять её становится сложнее.
Re[7]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, gandjustas, Вы писали:
G>"Заявка" по сути являлась первоначальным состоянием заказа, которое в некоторых случаях могло быть пропущено, и действительно в процессе участвовали разные люди, использовали разные формы итп. Но не это важно, важно что заказчик был уверен что сущности разные и долго мне это пытался доказать, хотя про структуре они оказались 100% идентичными.
Ну я хотел сказать, что заказчика надо внимательно послушать и решить про себя как сделать по факту (на свой страх и риск естессно)
G>check constraints
а я вот таких вещей стараюсь избегать, так как (заполнять)/(не заполнять) это лишь простейший пример. Добавьте сюда более сложные хотелки и очень скоро окажется, что в рамках constraints это не реализуемо в принципе.
G>Тут как раз есть два подхода — вникать в бизнес (может быть очень долго), не вникать в бизнес и сначала спроектировать функции, а потом разбираться с чем они работают углубляясь в реализацию. G>Я фактически пошел по первому пути.
я тоже за первый путь, поскольку если делать работу хорошо, то вникать в бизнес все равно придется
G>Структура поменяется даже если её выяснить заранее Только если мы прибиваем к структуре функции в стиле ООП, то менять её становится сложнее.
это да
Re: [DDD] Вносить ли бизнес-логику в модель предметной облас
Здравствуйте, Sinix, Вы писали:
S>В итоге получается примерно следущее разделение: S>- Модель предметной области определяет основной набор сущностей, инварианты и правила операций. S>- Бизнес-логика манипулирует моделью предметной области.
такое положение вещей мне наиболее симпатично. По крайней мере в той области, где я работаю.
Есть базовые понятия, которые должны работать, даже если произойдет всемирный потоп. Утрирую немного, но в целом так.
Например, резервирование товара на складе.
А вот как будем использовать эти "кубики", и в каких целях — это уже вопрос десятый.
Например, продать товар, переместить, сфотографировать, отложить до лучших времен и т.д. и быть уверенным, что он гарантированно будет в наличии.
Но это именно мой случай. Не факт, что это будет работать везде.
Re[2]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, MozgC, Вы писали:
MC>Я правильно понимаю, что под моделью вы понимаете набор классов представляющий сущности из предметной области, т.е. в "типичном бизнес-приложении" классы типа Customer, Order и т.д.?
Нет, я же выше писал — модель выносится в самостоятельный артефакт. Как она у вас представлена, не так уж и важно, главное, чтобы модель работала — помогала принимать решения по дизайну системы. Идея старая, она практически целиком утянута с концептуальной модели из ANSI/SPARC (я не про кошмар из русской wiki, а про описание у Дейта).
Опять-таки, DDD (в моём понимании) ортогонально способу разработки. Необязательно (и зачастую глупо) трамбовать всю модель в код, главное, чтобы соблюдался баланс между практичностью и будущими граблями при расширении модели.
MC>Под "вносить в модель особенности бизнес-логики" что вы понимаете? Наделение классов-сущностей предметной области методами выполняющими определенную бизнес-логику?
Нет. Я про подход, когда в стабильные знания о предметной области мы примешиваем знания о бизнесе заказчика, и, в результате, уже не можем их разделить даже на уровне модели, не говоря уже о реализации.
А если мы опустимся чуть ниже, на уровень кода, то получится "rich model" vs "слой — модель домена" + "слой — бизнес-логика". В слое модели необязательно будут только данные и инварианты, вполне допустимо включать factory-методы и "базовые кирпичики" — допустимые операции над моделью. Я предпочитаю выносить их в отдельные классы-хелперы, но к вопросу о разделении логики и модели это относится слабо.
MC>Правильно ли я понимаю, что вы предлагаете классы-сущности и слой бизнес-логики разделить по разным сборкам, например в DomainModel.dll и BusinessLogic.dll ?
Про то, как делаем мы, я один раз написал, и теперь просто раздаю ссылку
S>>1. Цель внедрения ПО — автоматизация части деятельности заказчика. S>>3. Заказчик никогда не работает в вакууме. MC>Давайте пожалуйста чуть подробнее, можно с примерами.
Блин, разъяснения по каждому из 3х пунктов — тема на пару огроменных постов Коротко ответил тут
В этой же ветке тов. gandjustas неплохо расписал альтернативный подход к дизайну — от требований.
S>>2. Большинство из виденных методологий разработки предполагает работу с заказчиком, как с чёрным ящиком: MC>А как этот абзац связан с вопросом внесения бизнес-логики в модель? Объясните пожалуйста.
Тут неоткуда взяться знаниям о предметной области, и, следовательно, самой модели.
MC>Правильно ли я понимаю, что ваша тема это тоже самое что извечное Anemic domain model vs Reach domain model?
Не совсем — сторонники anemic и rich спорят о деталях реализации. Чтоб понятней было: мы с gandjustas регулярно цапаемся по вопросам подхода к дизайну, но оба предпочитаем использовать anemic.
MC>Кстати, DDD меня почему-то не впечатлило.
Ну... да. Меня зацепило, потому что я сначала понаступал на грабли и пришёл к похожему подходу, а уже затем абсолютно случайно наткнулся на книжку.
Re[8]: [DDD] Вносить ли бизнес-логику в модель предметной об
Здравствуйте, andry81, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>"Заявка" по сути являлась первоначальным состоянием заказа, которое в некоторых случаях могло быть пропущено, и действительно в процессе участвовали разные люди, использовали разные формы итп. Но не это важно, важно что заказчик был уверен что сущности разные и долго мне это пытался доказать, хотя про структуре они оказались 100% идентичными. A>Ну я хотел сказать, что заказчика надо внимательно послушать и решить про себя как сделать по факту (на свой страх и риск естессно)
А как же DDD? и ubiquitous language? Получается то с заказчиком общаемся на одном языке, а внутри команды разработки — на другом.
Это ты говоришь как раз про анти-DDD, когда существует преобразование между "бизнесом" и "архитектурой\дизайном", причем далеко не всегда биективное.
DDD пытаешься привести все к одному знаменателю.
G>>check constraints A>а я вот таких вещей стараюсь избегать, так как (заполнять)/(не заполнять) это лишь простейший пример. Добавьте сюда более сложные хотелки и очень скоро окажется, что в рамках constraints это не реализуемо в принципе.
А и не надо все пихать в базу в принципе. Даже в модель не надо. Большинство проверок являются не инвариантами вообще говоря, а предусловиями для некоторых операций. Операция меняются, а инварианты нет. Предусловия не нужно заносить в базу, а инварианты можно.
G>>Тут как раз есть два подхода — вникать в бизнес (может быть очень долго), не вникать в бизнес и сначала спроектировать функции, а потом разбираться с чем они работают углубляясь в реализацию. G>>Я фактически пошел по первому пути. A>я тоже за первый путь, поскольку если делать работу хорошо, то вникать в бизнес все равно придется
Только заранее ты не можешь определить глубину вникания, особенно если бизнес нетривальный, а задача может оказаться вполне поверхностной.
Re: [DDD] Вносить ли бизнес-логику в модель предметной облас
Здравствуйте, Sinix, Вы писали:
S>Другими словами, Эванс как минимум не против того, чтобы включать бизнес-логику в состав модели. Многие авторы, например, Casey Charlton (aka Jak Charlton) вообще объявляют джихад анемик-модели:
S>С дизайном, прибитым гвоздями к предыдущей модели бизнес-логики, это будет весьма весёлым занятием.
Утверждение взято с потолка. Было бы неплохо увидеть, что по твоему "прибито гвоздями" и "неприбито гвоздями". см пример в конце
S>2. Большинство из виденных методологий разработки предполагает работу с заказчиком, как с чёрным ящиком: получаем непредсказуемый набор требований, выдаём прототип, и крутимся в петле улучшений до тех пор, пока не придём к компромиссу. При этом ответственность за неверные требования неявным образом перекладывается на заказчика: "чего попросили, то и получили".
С чего это вдруг ?
S>3. Заказчик никогда не работает в вакууме. Вне зависимости от его желаний, его бизнес ограничен множеством объективно существующих правил и ограничений. И, волей-неволей, заказчик вынужден к ним приспосабливаться. Ограничив модель областью, в которой работает заказчик, мы одновременно получаем и стабильную и объективную информацию для принятия решений, и способ оценки требований заказчика с точки зрения предметной области бизнеса, и способ обезопасить себя от будущих изменений в бизнес-логике.
И как это относится к обсуждаемому вопросу ? Модель всегда ограничивается областью с которо работает заказчик.
S>В итоге получается примерно следущее разделение: S>- Модель предметной области определяет основной набор сущностей, инварианты и правила операций.
это называется модель данных
S>- Бизнес-логика манипулирует моделью предметной области.
Моделью данных она манипулирует, а не моделью предметной области.
Вот простая задача — есть склад, есть поставки, есть заказы, скидки и есть возвраты. при возврате товара надо вычислить 1 сумму возвращаемых денег с учетом всех возможных скидок и округлений 2 найти именно ту поставку с которой единица товара прибыла на склад
Функция, которое это делает, как правило в BL, чтото вроде ReturnService. Вопрос — почему эту функцию нельзя считать частью модели предметной области ?
Второй вопрос — как эту функцию прибить гвоздями к модели ?
Третий вопрос — как это функцию неприбить гвоздями к модели ?
) эту тему.
Мы уже победили, просто это еще не так заметно...
Если разбавить водой, чтобы легче воспринималось, вообще никто читать не будет.
В общем по true DDD писать не стал (хотя некоторые пересечения есть), продолжил делать как делал — ведь главное, это чтобы ваш подход был удобен для вас, т.е. чтобы вам и программистам в вашей команде было удобно имплементировать бизнес-задачи, а уж как оно будет называться DDD, или Vasya Pupkin Design — это неважно.
