А не подскажет ли кто границы применимости DDD для проектов? Он хорошо ложится на проект любого масштаба или только для кровавого энтерпрайза?
Допустим для приложения типа калькулятор оно как, подойдет или слишком сложно будет? А для приложения где есть, скажем, 10-20 таблиц (сущностей) DDD
нормально будет? Или он только хорош, когда у нас есть n (например, n=100) сущностей?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте.
S>А не подскажет ли кто границы применимости DDD для проектов? Он хорошо ложится на проект любого масштаба или только для кровавого энтерпрайза? S>Допустим для приложения типа калькулятор оно как, подойдет или слишком сложно будет? А для приложения где есть, скажем, 10-20 таблиц (сущностей) DDD S>нормально будет? Или он только хорош, когда у нас есть n (например, n=100) сущностей?
Таблицы есть в базах данных, а не приложениях... DDD — это, в сущности, модель предметной области. Людям, привыкшим мыслить схемами таблиц и хранимками, в любом масштабе будет казаться ненужной хренью.
V>Таблицы есть в базах данных, а не приложениях...
Это был пример для объема приложения, объема предментно области.
V>DDD — это, в сущности, модель предметной области. Людям, привыкшим мыслить схемами таблиц и хранимками, в любом масштабе будет казаться ненужной хренью.
DDD — это не столько про классы, таблицы и размеры проекта, сколько про единый язык для заказчиков (бизнеса) и программистов (тот самый Ubiquitous Language).
Т.е. если у тебя закодирован алгоритм реализующий какой-то бизнес-процесс, ты показываешь его, скажем бухгалтеру, и он может прочитать и понять о чем идет речь — это хороший DDD.
А если у тебя там абстрактная фабрика, создающая в шаблонном методе декораторы стратегии через билдер, то это может быть вполне годный ООП-дизайн, но плохой DDD.
Здравствуйте, RushDevion, Вы писали:
RD>DDD — это не столько про классы, таблицы и размеры проекта, сколько про единый язык для заказчиков (бизнеса) и программистов (тот самый Ubiquitous Language).
Это не является чем то уникальным. Любой процесс дизайна подразумевает использование понятий предметной области. На практике это означает, что программисты используют определения которые приняты в этом бизнесе, а не наоборот.
RD>Т.е. если у тебя закодирован алгоритм реализующий какой-то бизнес-процесс, ты показываешь его, скажем бухгалтеру, и он может прочитать и понять о чем идет речь — это хороший DDD.
Вам приходилось такое делать на практике?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
RD>>Т.е. если у тебя закодирован алгоритм реализующий какой-то бизнес-процесс, ты показываешь его, скажем бухгалтеру, и он может прочитать и понять о чем идет речь — это хороший DDD. AJD>Вам приходилось такое делать на практике?
Нет, такого опыта у меня лично не было.
Однако это ровно то, что пропагандируется в DDD-шной литературе.
Т.е. вместо классической цепочки бизнес -> (хотелки, деньги) -> доменные эксперты -> аналитик -> (requirements) -> архитектор -> (design document) -> программисты -> код.
Нам предлагают посадить доменных экспертов в одну комнату с программистами и чтобы они через общение рожали shared mental model системы.
А выражением этой модели как раз и является код (или скорее псевдо-код), описывающий бизнес-процесс.
Здравствуйте, Sharov, Вы писали:
S>Для калькулятора DDD применим?
Если есть задача разработать ядро программы, независимое от деталей реализации типа UI (веб, десктоп, консоль, веб-сервис) и БД (файлы, серверы, облака), то я буду ваять в стиле похожем на DDD (на практике это обычный ООП, ведомый здравым смысолом).
Здравствуйте, Vladek, Вы писали:
V>Здравствуйте, Sharov, Вы писали:
S>>Для калькулятора DDD применим?
V>Если есть задача разработать ядро программы, независимое от деталей реализации типа UI (веб, десктоп, консоль, веб-сервис) и БД (файлы, серверы, облака), то я буду ваять в стиле похожем на DDD (на практике это обычный ООП, ведомый здравым смысолом).
Ну, не совсем, DDD идет бок о бок с понятием Onion Archicture.
В этом случае Domain Model — отдельный проект полностью описывающий функционал системы со своим набором состоянии — валидных Ok(value) и невалидных Err(message).
Все остальное при этом (IU, DAL и прочее) превращается (легким движением) в инфраструктурный(обслуживающий) код.
DDD по сути есть полная противоположность спагетти-коду.
ФП прекрасно ложится на ДДД.
pdf можно загуглить в хорошем качестве. Да и на сайте есть неплохие примеры.
Приемущества — предметную область можно облажить проперти-бейз-тестами, убедится что все функции выдают предсказуемый результат.
Если проект маленький то это имеет смысл даже больше, т.к. у вас есть шанс встать на светлую сторону.
Ведь чем больше проект тем сложнее придерживаться правильного пути. Начинают сильно мешать поставленные сроки и нечеткость ТЗ (каковая всегда имеет место быть).
Здравствуйте, Sharov, Вы писали:
S>нормально будет? Или он только хорош, когда у нас есть n (например, n=100) сущностей?
Я вообще хотел бы посмотреть на применение DDD к какому-нибудь небольшому и понятному проекту. Всё, что я видел из практики до сих пор — это кровавые слёзы, убедительно доказывающие "так делать не надо".
Вот, прямо сейчас пилю информационную архитектуру для простенькой системы онлайн-заказов. Вроде бы почти всё уже в голове сложилось, но мучают сомнения:
1. А правильно ли я всё придумал
2. Как к этому правильному прийти через DDD
Вкратце: в домене (по описаниям отдела продаж) есть
— товары
— группы товаров (товар входит в 1, 2 или 3 группы)
— реселлеры (продавцы)
— позиции прайслиста. Каждая позиция сопоставляет "базовую цену" одному товару.
— заказы. Заказ — как обычно: продавец, покупатель, 1..N позиций: (товар, количество, отпускная цена).
Наша задача — сделать правильную накрутку на базовую цену.
Работать должно примерно так:
— на все товары мы делаем фиксированную накрутку. Например, 4%. Или 7%.
— могут быть исключения для некоторых групп товаров — там, где нам поставщик даёт слишком маленькую скидку, мы хотим урезать наценку, иначе цена выходит дороже розницы
— могут быть исключения для некоторых продавцов — на их заказы мы хотим накручивать меньше.
— могут быть исключения для некоторых продавцов и товаров — по тем же причинам.
— иногда мы можем захотеть сделать скидку на конкретный заказ. Но это только если мы сами размещаем заказ от имени продавца. А когда они сами — см. требования выше.
Вот мне интересно, какие объекты будут появляться в DDD, и как они будут работать. Будет ли rich object model, или анемика?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>нормально будет? Или он только хорош, когда у нас есть n (например, n=100) сущностей? S>Я вообще хотел бы посмотреть на применение DDD к какому-нибудь небольшому и понятному проекту. Всё, что я видел из практики до сих пор — это кровавые слёзы, убедительно доказывающие "так делать не надо". S>Вот, прямо сейчас пилю информационную архитектуру для простенькой системы онлайн-заказов. Вроде бы почти всё уже в голове сложилось, но мучают сомнения: S>1. А правильно ли я всё придумал
А не проще ли взять что-то готовое и адаптировать под себя, этого добра написано-переписано+всякие crm.
Здравствуйте, Sharov, Вы писали:
S>А не проще ли взять что-то готовое и адаптировать под себя, этого добра написано-переписано+всякие crm.
Коротко: нет.
То, что мы пилим, это крошечная часть огромной системы. Которая интегрирует между собой сотни ещё более огромных систем.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>>А не проще ли взять что-то готовое и адаптировать под себя, этого добра написано-переписано+всякие crm. S>Коротко: нет. S>То, что мы пилим, это крошечная часть огромной системы. Которая интегрирует между собой сотни ещё более огромных систем.
Здравствуйте, Sinclair, Вы писали:
S>Я вообще хотел бы посмотреть на применение DDD к какому-нибудь небольшому и понятному проекту. Всё, что я видел из практики до сих пор — это кровавые слёзы, убедительно доказывающие "так делать не надо".
Да, хотелось бы увидеть презентацию архитектуры какого-нибудь продукта в котором DDD применялся бы так-то и так-то. Пока есть только куча презентаций всяких евангелистов, а не инженеров создателей реальных систем.
Опять, же все ссылаются на книгу Эванса. А кто он такой этот Эванс? Что он создал реального, кроме книги и хайпа вокруг нее?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, Sinclair, Вы писали:
S>>Я вообще хотел бы посмотреть на применение DDD к какому-нибудь небольшому и понятному проекту. Всё, что я видел из практики до сих пор — это кровавые слёзы, убедительно доказывающие "так делать не надо".
AJD>Да, хотелось бы увидеть презентацию архитектуры какого-нибудь продукта в котором DDD применялся бы так-то и так-то. Пока есть только куча презентаций всяких евангелистов, а не инженеров создателей реальных систем. AJD>Опять, же все ссылаются на книгу Эванса. А кто он такой этот Эванс? Что он создал реального, кроме книги и хайпа вокруг нее?
Я где-то видел настоящий проект на ddd, сервис заказов билетов кажется. Вообще лучше попробовать самому это методику, так быстрей можно разобраться.
Здравствуйте, takTak, Вы писали: T>рекомендую посмотреть выступления джимми богарда
Вы шутите. Смотреть видео по техническим вопросам?
Да ещё и по часу длиной? У меня нет столько свободного времени, чтобы наблюдать, как человек в течение часа рассказывает то, что я могу прочесть за 8-9 минут.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
T>>рекомендую посмотреть выступления джимми богарда S>Вы шутите. Смотреть видео по техническим вопросам? S>Да ещё и по часу длиной? У меня нет столько свободного времени, чтобы наблюдать, как человек в течение часа рассказывает то, что я могу прочесть за 8-9 минут.
так DDD- это о том, что нужно говорить с заказчиком, на общение с заказчиком часами тоже нет времени? просто тот докладчик практику применения ddd в свои проектах там и демонстрирует...
Здравствуйте, Qulac, Вы писали: Q>Я где-то видел настоящий проект на ddd, сервис заказов билетов кажется. Вообще лучше попробовать самому это методику, так быстрей можно разобраться.
Ну давайте попробуем. Я вот привёл микро-пример, который лично у меня вызывает затруднения.
Обратите внимание — я вижу пробуксовку уже на уровне informational architecture, т.е. номенклатуры видимых пользователю "штук". Понятно, что внутреннее устройство приложения может отличаться от ментальной модели, которую мы навязываем пользователю (ну, там, в визарде у пользователя возникает ощущение движения вперёд-назад, а на самом деле это один цикл message pump с какими-то if-ами внутри)
Если я правильно осознал основу DDD — это то, что иерархия классов и взаимосвязь объектов в приложении у нас в итоге совпадёт с informational architecture.
Почему затруднения? Потому, что когда я пришёл в проект, версия 1 уже была выпущена. Т.е. парни спроектировали навигацию и весь UI в соответствиями с требованиями клиентов (ну, как им казалось).
И теперь клиенты плачут и есть кактус не хотят. Вот, мне интересно — DDD помог бы тем парням, которые пилили этот кактус до меня, сделать всё верно с первого раза?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, takTak, Вы писали: T>так DDD- это о том, что нужно говорить с заказчиком, на общение с заказчиком часами тоже нет времени? просто тот докладчик практику применения ddd в свои проектах там и демонстрирует...
Я уже пообщался с заказчиком. Чтобы понять, есть ли вообще польза от учебных пособий, мне в первую очередь надо понять — есть ли примеры, похожие на мой. Если есть — то можно посмотреть, какие решения получаются, сравнить со своими, и потом уже делать backtrack к тому ходу рассуждений, который к этим решениям привёл.
В текстовом виде это понятно как делать. Как это делать с видео — непонятно совсем. Три часа подряд смотреть несмешной стендап, чтобы убедиться в том, что он не подходит — нет времени. Если бы была уверенность в том, что там есть ответы на все мои вопросы, то и четырёх часов не жалко. Но ведь нет её
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
T>>так DDD- это о том, что нужно говорить с заказчиком, на общение с заказчиком часами тоже нет времени? просто тот докладчик практику применения ddd в свои проектах там и демонстрирует... S>Я уже пообщался с заказчиком. Чтобы понять, есть ли вообще польза от учебных пособий, мне в первую очередь надо понять — есть ли примеры, похожие на мой. Если есть — то можно посмотреть, какие решения получаются, сравнить со своими, и потом уже делать backtrack к тому ходу рассуждений, который к этим решениям привёл. S>В текстовом виде это понятно как делать. Как это делать с видео — непонятно совсем. Три часа подряд смотреть несмешной стендап, чтобы убедиться в том, что он не подходит — нет времени. Если бы была уверенность в том, что там есть ответы на все мои вопросы, то и четырёх часов не жалко. Но ведь нет её
для таких целей того же чувака, который с использованием ddd работал, нанимают на пару недель или месяцев: или ты думаешь, что кто-то бесплатно будет тебе рассказывать то, что именно тебе нужно?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте.
S>А не подскажет ли кто границы применимости DDD для проектов? Он хорошо ложится на проект любого масштаба или только для кровавого энтерпрайза? S>Допустим для приложения типа калькулятор оно как, подойдет или слишком сложно будет? А для приложения где есть, скажем, 10-20 таблиц (сущностей) DDD S>нормально будет? Или он только хорош, когда у нас есть n (например, n=100) сущностей?
