Как стать автором
Обновить

Комментарии 61

Что такое DDD, можно объяснить даже ребёнку (или маркетологу)
Маркетологу объяснить это как раз не сложно. Гораздо сложнее объяснить что это такое программисту.
Гораздо сложнее объяснить что это такое программисту

Еще сложнее после объяснения удержать
НЛО прилетело и опубликовало эту надпись здесь
Да, в подходе DDD считается, что чем меньше «переводов» и чем лучше разработчик сам понимает зачем он пилит ту или иную фичу, тем качественнее продукт на выходе.
НЛО прилетело и опубликовало эту надпись здесь
В моей трактовке любая передача информации от человека человеку сопряжена с потерями. Если можно обойтись без — лучше обойтись.

Но сам по себе DDD не исключает архитекторов и аналитиков (как и дизайнеров с тестировщиками). Но не снимает с разработчика почетной обязанности погружаться в домен и бизнес.
НЛО прилетело и опубликовало эту надпись здесь

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


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

НЛО прилетело и опубликовало эту надпись здесь
На жизни разработчиков сказываются те бенефиты, которые они получают по месту работы. Все методики разработки направлены на улучшение бизнеса. DDD — это следующий этап после приближения разработки к собственно продукту. То есть нужно сначала разобраться, зачем разработчику знать то, над чем он работает.
НЛО прилетело и опубликовало эту надпись здесь
мидл и ниже, уже настолько у них низкое воздействие на результат
Так приближение к бизнесу подразумевает повышение воздействия.
пожинать плоды будет уже кто-то другой
Вы акционер или совладелец бизнеса? Я говорю про обычных программистов на зарплате.
усилия на нерелевантные знания
Чтобы продавать себя дороже. Не так уж много знаний и так или иначе придётся в них вникать (программирование — перевод из человеческого на формальный язык), а эффект намного больше, чем от изучения очередного фреймворка (который скорее всего не пригодится). Ну и в любом случае переводить из языка бизнеса в формальный кому-то нужно. Пусть при ваших процессах идея DDD будет тогда не для вас, а для ваших сеньоров, например.
лично тебе это фактически не приносит прибыли
Любой положительный эффект для бизнеса — это растущая ценность и для специалиста. Именно за это бизнес платит деньги людям.
НЛО прилетело и опубликовало эту надпись здесь
вы за мир во всём мире, примерно похоже по глубине и информативности
Я за мир в своём кармане и говорю о том, что меня спрашивают на собеседованиях и чем я стараюсь себя продать. The Best Code is No Code At All, без привычки вникать в бизнес-процессы можно только по чьей-то указке послушно закрывать разжеванные тикеты, надеясь на то, что все требования уже формализованы и написаны. Но это не особо ценится. Разработчик > кодер.
Так и есть, при устройстве в IT отдел кондитеской фабрике у вас в резюме будет «в деталях овладел техпроцессом производства синтетической резины». Это позволит себя продать дороже.

Примерно так, только другими словами. Например, за 3 месяца погрузившись в детали предметной области (техпроцессом производства синтетической резины), нашёл места легко поддающиеся автоматизации, подготовил MVP для этого, после демонстрации которого отвечал за техническую часть его дальнейшего развития. Внедрение продукта позволило снизить время производства очередной партии на 10%, а фонд оплаты труда на 50.

НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь

Разніе компании есть, некоторые поощряют подобную инициативность, некоторые руководители предпочитают, чтобы к ним приходили не с проблемами, а с решениями.

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

Что-то мне подсказывает, что вы неправильно понимаете, что такое DDD. Оно не о том, чтобы программист делал что-то, что не входит в его обязанности.

НЛО прилетело и опубликовало эту надпись здесь
разговаривать с бизнесом на одном языке

Грубо говоря, это означает, что если в бизнесе используется термин "клиент", то в коде эту сущность надо называть "Client", а не "User". Если в бизнесе есть некоторый процесс, который имеет устойчивое название, в коде должен быть метод с аналогичным названием и содержанием, а не Button1Click какой-нибудь. От этого уже идет все остальное.

НЛО прилетело и опубликовало эту надпись здесь
а потому что кто-то, почему то, решил что это будет вот так

Да, и модель должна это отражать. Потому что она модель, она для этого и делается.


Зачем использовать кривые термины если можно выпрямить.

Затем, что если бизнес их использовать не будет, то будет непонятно, что вообще надо менять при изменении требований. Бизнес скажет, надо печатать на билете в кино ограничение по возрасту, а у вас в коде Button1Click, Button2Click, Button3Click. Какой метод будете менять? Код всех 3 изучать? А зачем, если можно сразу нормально назвать?


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

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

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


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

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

Глоссарий единого языка — один из артефактов DDD. А "учит" не совсем подходящее слово. Изучает в мере необходимой, чтобы создать модель бизнеса и представить её в коде.

А если один бизнес человек говорит client а другой user?

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

>придёт бизнес пользователь и проблеет невнятно свои желания, а DDD программист должен их схватить и на исполнение

невнятно проблеять может кто угодно на любой стадии
Ну то есть если разработчик понимает свою предметную область (бизнес домен) и может взять на себя функции аналитика то он уже умеет в DDD даже если термина такого не слыхал?

Нет. Он должен отражать своё понимание в коде, не переводить бизнес-термины в термины кодовой базы в уме, собственно выделить независимый от других слой доменной области, и т. п.

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

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


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


В пределе, наверное, бизнес-аналитик и архитектор могут "заставить" разработку идти по DDD даже без ведома разработчиков. Архитектор определит слои, бизнес-аналитик контексты и модели, а разработчики будут это имплементировать. Разве что жаловаться будут на то, что эти самодуры лезут в детали реализации, типа какая разница как у нас класс называется, если пользователь этого не знает. Или что запрещают инжектить сервис в сущность через конструктор, хотя это удобно.

запрещают инжектить сервис в сущность через конструктор
Вот это мне не удаётся хорошо обосновать. Стараюсь через Clean Architecture, но с сомнительным успехом. Еще через глобальное состояние и «чистоту» эффектов, но через это по-видимому я вообще только себе могу что-то доказать. В материалах по DDD разве есть что-то про это? По-моему нет.

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


Остаются бизнес-сервисы, сервисы предметной области. Тут подход другой: мы моделируем сущность, она имеет жизненный цикл и создаётся, конструируется только один раз. То есть ее конструктор должен вызываться только один раз. Если про rest-like веб API говорить, то где-то в обработчике соответствующего POST метода. Если про UI, то где-то в обработчик кнопок new/create/etc.


Используемый ORM/ODM/… или даже язык в целом, может не допускать такой сценарий и придётся использовать какой-то именованный конструктор/фабричный метод/фабрику, но вот семантика должна сохраниться, то есть инжектить сервисы через конструктор даже под их капотом всё равно нельзя, по-моему. У класса сущности должна быть одна ответственность — моделировать сущность предметной области. Если и надо что-то инжектить в сущность, то из-за эфемерной природы программных сервисов (их в базу не сохранишь), то через double dispatch

Если и надо что-то инжектить в сущность, то из-за эфемерной природы программных сервисов (их в базу не сохранишь), то через double dispatch
То есть инжектить сторонние зависимости через сигнатуру метода сущности? Тогда остаётся вопрос, в какой момент остановиться и не отработать весь процесс приложения в этом методе сущности)

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

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

Я уже где-то встречал это мнение, кажется в сообществе Doctrine так считается. Я думаю, это неправильный подход. Конструктор это по своей природе функция, которая вызывается при создании объекта в оперативной памяти некоторого процесса, для инициализации занимаемой им оперативной памяти. Это инфраструктурная вещь. Если у нас есть более высокоуровневая абстракция, если у нас одна и та же сущность может появляться в разных процессах, значит и для конструктора нужно создать более высокоуровневую абстракцию, специальный бизнес-конструктор, который и будет вызываться один раз. А не пытаться через рефлексию и аннотации имитировать то, что должно быть в конструкторе.

Я исхожу из того, что код домена, написанный по DDD должен быть в целом понятен бизнесу (англоговорящему). И где-то в коде new Customer($name, $address) будет более понятно при таком подходе, чем CustomerFactory::create($name, $address). Хотя в принципе непринципиально. Можно и фабричным методом/классом, особенно в форме Customer::registerNewCustomer(($name, $address). Но вот программные зависимости, а не значения свойств сущности в конструкторе класса сущности, по-моему, зло, которого не должно быть независимо от того Doctrine это или нет. Для меня это говорит о плохой проработке модели, или о выборе непоходящего для DDD инструментария, типа использования в качестве сущности наследника какого-нибудь ACtiveRecord

Убедиться, что этот подход поможет в конкретном случае.
Но как это можно сделать не попробовав?

Изучить какие проблемы подход решает, какие приносит, и стоит ли овчинка выделки в конкретном случае. Может стоит применять его только частично или в ограниченной области системы. Например в конкретном случае вполне может оказаться, что нет смысла тащить DDD на фронт или, наоборот, на бэк. Или на БД может оказаться слишком дорого менять схему данных на каждый чих в UI

У Эванса нет бороды. У Вернона тоже.

Вот что происходит, когда люди экстраполируют на основе маленького датасета)
«Те, кто умеют — делают. Те, кто не умеют — учат.»

Интересно, как воспринимают мир программисты, которые сразу начали через DDD осваивать эту стязю?

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

DDD и Додо Пицца это весело.
Но, как известно
Talk is cheap. Show me the code.

Покажите ваши классы Price и Money!
Мы только учимся, Price у нас пока decimal(
А Андрей показал свой код на митапе.

А money, деньги, те что обычно число и валюта? Есть такой? Да и price я видел(давно правда, около 3х лет назад), и состоял он в очень странных отношениях с money. И price уже как раз entity, обычно, т.к. привязан к продукту.

Если не секрет, почему entity?
Интересно, потому-что я обычно представлял прайс в виде VO.
Или это у вас специфика модели?
Здесь действительно всё зависит от того что именно понимается под Price и под Money.
в моём понимании для торговли, вполне можно использовать следующий подход:
Money — классический ValueObject, состоящий, в простейшем случае, из количества денег (например Decimal) и валюты.
Price — Цена, цена относится к какому то товару или услуге, она может содержать в себе то, что платит покупатель (деньги — VO), ставку/сумму налогов. Выходит, что нельзя делать её в виде ValueObject при таком подходе — по той причине, что её нужно сравнивать по ссылке, а не по содержанию.
10 рублей как деньги (VO) — они везде 10 рублей и их можно «заменить одни другими»
10 рублей как цена — может содержать разные налоги, и заменять их уже нельзя.

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

Ну так разные налоги — разное содержание и вполне можно сравнивать по содержанию. Идентификатор у цены есть? Цены у двух продуктов "10 рублей, включая 2 рубля НДС" одинаковые? Если изменить у одного, должна ли меняться у другого?

Идентификатор у цены есть?

В моём понимании — нет, цена полностью определяется своим содержимым.


Цены у двух продуктов "10 рублей, включая 2 рубля НДС" одинаковые?

Да.


Если изменить у одного, должна ли меняться у другого?

Нет, конечно. С чего бы?

Я думаю вы путаете цену с деньгами. Цена содержит в себе одно или несколько полей денег, при этом:
Само наличие сущности цена, с некоторыми свойствами определяет возможность продажи.
Может быть есть более удачное название для сущности, но я пока не придумал.
Итак «набросок» цены, как один из вариантов сущности:
class Price : Entity
{
  public Money Value {get;set;}
  public Item Item {get;set;}
  public Location Location {get;set;}
  public PriceType PriceType {get;set;}
...
}

В данном примере можно задать цену для Товара, с учётом валюты, в разных Локациях (точки продаж, может быть в разных странах) а также типом цены, например для Доставки, Оптовой цены, Особого Клиента или что-то ещё.

При продаже по определённой Цене, в «таблицу проводок» или что-то подобное записывается текущее значение цены.
В таблице проводок используется понятие Денег (ValueObject)
Точно так же как и в Цене, может использоваться в расчётах Прибыли, Расходов, Доходов и т.д.

Если говорим о сущности "цена", то какие её свойства являются идентификатором, а какие состоянием?

Тогда ваша цена никкая не сущность, а простой VO, чуть более сложный чем классический Money, но всё равно VO/ Зачем вам сравнение цен по ссылке?

Зачем вам сравнение цен по ссылке?

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

Ошибся, это вопрос pil0t

Мне синяя книга показалось гораздо легче для восприятия чем красная (только начал) и зеленая. На мой взгляд, Вон Вернон чересчур сухо и академично пишет. Русскоязычный перевод это еще больше усугубляет.

У меня обратные ощущения)
Про перевод Вернона слышал плохие отзывы. Попробуй потом «еще одну красную» Принципы и паттерны. Перевели на русский, вроде неплохо.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.