Николай Гребнев (CUSTIS) — Что такое DDD? — доклад с конференции ADD

Есть такая конференция ADD (Application Developer Days) на которой любят всякие архитектурные штуки для разработки ПО обсуждать, обычно эти штуки заканчиваются тоже на xDD — DDD, TDD, MDD и т.д.

Вот к примеру на прошлой конференции задались вопросом, а что такое DDD (Domain Driven Design)?
А Николай Гребнев из CUSTIS — встал и ответил.

Видео доклада:

Скачать видео можно здесь (0,73 Гб)

Презентация доклада:

Текст доклада

Что такое DDD (Domain Driven Design)?

Это такой набор систем, взглядов и подходов, который определяет наш способ разработки. В 2002 году Мартин Фаулер выпустил книгу «Шаблоны архитектуры корпоративных приложений». Книга является на данный момент классикой по архитектуре разработке корпоративных приложений. В частности Мартин приводит три шаблона по организации бизнес-логики в проекте:

• Сценарий транзакций
• Модуль таблицы
• Модель предметной области

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

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

Все классы обладают какими-то операциями, они что-то уже умеют, что-то в себе инкапсулируют. Как правило, они инкапсулируют работу с базой данных. В частности – могут содержать методы: добавить, удалить, получить все, и ещё какие-то. Ну и с каждой сущностью мы работаем, запрашивая из таблиц. Очевидно, связи у нас между таблицами нет, и мы как-то внутри нашей программы строим их вручную. Фактически, если кто-то работал с MS Visual Studio или вообще с технологиями MS, — это RecordSet & DataSet, до 2008 года это были основные технологии по работе с данными.
Ну и модель предметной области. Отличается от предыдущих представленных вариантов тем, что здесь мы строим полноценную модель предметной области. Которая состоит из сущностей, которые обладают поведением, которые взаимодействуют с другими сущностями, имеют явно прописанные отношения и т.п. На рисунке приведена модель предметной области автоматизации, например, библиотеки.

Модель предметной области в основном состоит из сущностей, там ещё есть много разных объектов, типа служб, объектов-значений и тому подобному. Ну а если мы говорим об объектной модели предметной области, а также получается, что в корпоративных ИС, большинство предметных областей имеют объектную структуру, то по большей части они состоят из сущностей.
Сущности это такие понятия, которые имеют идентичность. Т.е. каждый экземпляр сущности может быть идентифицирован и отличается от других, и инкапсулирует в себе состояние объекта и его поведение. Это значит, что никак внешним образом мы не можем, не сообщив объекту о том – поменять его состояние, привести его к не консистентному состоянию, или заставить его вести себя как-то так, как он вести себя не должен.
Этот шаблон является наиболее удачным, для применения в сложных ИС. Потому что он наиболее удачным образом структурирует предметную область и способствует нашему пониманию.
Как развитие этого шаблона в 2003 выходит книга Эрика Эванса «Предметно-ориентированное проектирование» (в оригинале Domain Driven Design structured complex software systems). Эта книга содержит не только описание такого шаблона, как предметной области, но и некий набор подходов, которые нам показывают, как нам с таким набором работать, построить и как нам в конце концов получить эту модель предметной области. Вот что нам говорит Эрик Эванс о DDD.
Это, во-первых, переработка знаний. Тех знаний, что у нас есть о предметной области, их нужно анализировать, из них надо выделять актуальную предметную область.
Во-вторых, это единый язык. Любая модель даёт нам некоторую терминологию, которая образует свой язык, и с которой мы можем работать, говорить на ней, писать.
И проектирование по модели (Model Driven Design). Это наиболее техническая часть DDD. Которая обозначает, что мы непосредственно нашу придуманную модель предметной области отображаем в код, именно её, а не какую-нибудь ещё.

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

Что же такое переработка знаний?

Как определяет её Эрик Эванс – это поиск абстрактных понятий, учитывающих необходимые подробности.
Необходимые для разработки нашей ИС, очевидно.
Кто выполняет эту переработку знаний?

• Специалисты предметной области
• Разработчики системы (не в смысле программисты, — аналитики, тестировщики, руководители проектов, но важно, что здесь должны присутствовать те, кто будет писать код, кто понимает, как будет выглядеть архитектура системы)

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

ПРИМЕР
Вот некий пример. Я расскажу, что такое переработка модели. Вот простейшая задача – рассчитать зарплату сотрудника в заданном месяце. Кто когда-либо с этим сталкивался, наверное, знают, что зарплата рассчитывается далеко не так просто, как хотелось бы.
Специалист предметной области нам говорит, что

Отношение количества отработанных дней к количеству рабочих дней в месяце умноженное на отношение оклада сотрудника к количеству рабочих дней в месяце

Мы строим модель

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

У нас появляется новая сущность, это какой-то ДЕНЬ, очевидно, он выделяется явно, имеет отношение с сотрудником и с месяцем, имеет у себя атрибуты «рабочийвыходной», «присутствовал».
Дальше специалист предметной области вспоминает, что у сотрудника ещё могут быть отпуска или он может быть на больничном и там всё по-другому, там другая ставка, другие проблемы.

Мы рисуем такую модель и уже здесь видно, что неправильно у нас что-то получается – очень много связей. Логично задать вопрос. А откуда мы можем узнать, что у нас сотрудник присутствовал на работе, был ли он в отпуске или на больничном. И специалист нам отвечает: «из табеля учёта рабочего времени». Он раньше его не упоминал, потому что для него это было абсолютно естественно. Это не то, что нуждается в отдельном упоминании, но вот путём переработки знаний, анализа системы, мы выявили такую сущность и соответственно модель у нас получается гораздо более понятной, когда у нас есть сотрудник, есть его табель учёта рабочего времени, который имеет следующие функции, следующие методы:

• Получить количество отработанных дней
• Получить количество дней в отпуске
• Получить количество дней на больничном и т.д.

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

Единый язык – это язык, который у нас получается в результате DDD. Это такой язык, на котором между собой общаются все участники проекта. Это не значит, что мы какую-то модель построили, потом выкинули и начинаем говорить, как попало, с какими-то новыми терминами, что-то объясняя на пальцах. Нет, у нас модель предметной области, именно в её терминах, её отношениях, в её поведении мы должны разговаривать, обсуждать структуру технических заданий и прочее. Язык строиться на модели предметной области, он должен чётко из неё следовать. И он же проверяет модель предметной области. Если модель предметной области, которую вы построили – очень-очень сложная и вам сложно это использовать в языке, вам постоянно хочется использовать другие термины и другие предложения – это значит, что у вас не правильно построена модель. Очень хороший способ проверить хорошая у вас модель или нет, это попробовать использовать её термины на русском языке. Просто разговаривать в терминах этой модели и, если у вас нет там никакого дискомфорта, значит у вас там всё хорошо. И эта модель используется во всех документах. Т.е. мы не просто так строим какие-то модели, разговариваем. Нет, именно на основании этих моделей должны строиться официальные документы, включающие ТЗ, требования, архитектуру системы и т.п. И как не странно, именно этот же язык должен использоваться в коде. Т.е. если мы при разговоре с людьми использовали эту модель в русском языке, то при разговоре с компьютером мы должны использовать эту же модель.
У нас есть модель предметной области, и она порождает терминологию. Так как она состоит из понятий, сущностей и поведений. Вот пример определения слова «терминология» из словаря.

Терминология – система терминов – слов научно-технического ЯЗЫКА, обладающих определённым, четко ограниченным значением.

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

Проектирование по модели.

Наиболее сложная часть DDD. Сложная она по техническим причинам в силу несовершенного инструментария для всего, инерции мышления и многих других причин. Вот что такое проектирование по модели (по Эрику Эвансу).
Проектирование по модели (Model Driven Development) – проектирование архитектуры, при котором соблюдаются максимально точное соответствие между некоторым подмножеством элементов программы и элементами модели.
Это значит, если у нас была модель предметной области

– и мы начинаем строить для неё программу.

И раз – получаем вот такую модель. В середине у нас происходит бизнес-логика. Мы видим, что используются совершенно разные понятия. Здесь у нас какие-то датасеты. Датаридеры, команды, коннекторы, и прочие вещи, которые в модели предметной области даже и не упоминались. Я уже не говорю, что если вы попробуете разговаривать на этом языке с людьми из предметной области, с людьми для которых вы пишете эту программу, то вам очень долго придётся объяснять, что вы имеете ввиду.
И вот здесь мы видим, что у нас модель одна, программа другая. Модель программы оперирует одними понятиями (датасет, коннекшн и т.д.), а модель предметной области – книги, авторы, издатель, читатель и т.д.
Это значит, что нашу модель предметной области надо выкинуть, она, конечно, полезной была, люди которые её строили лучше знали предметную область, но скорей всего она очень быстро потеряет свою актуальность.
Но это не так модель предметной области имеет гораздо более широкое применение. Из определения Эванса:

Model Driven Design (MDD) – это прямая проекция языка предметной области на объектно ориентированный язык программирования.

Т.е. будет неправильно, если у нас есть в модели понятие Автор, а в коде у нас это является строкой датасета, да ещё нетипизированного и в явном виде оно не присутствует.

Давайте я приведу такой пример. Построим вот такую задачу:

Зачислить сотрудника в подразделение, начиная с заданной даты.

Обычная задача для системы учёта, причём легко понять, что история по подразделениям некоторая ведётся, что нам нужно уметь получить сотрудника подразделения. У подразделения есть такая функция, как зачислить сотрудника на дату. Давайте попробуем это написать в коде, как это обычно бывает.

Я даже привожу не работу с датасетами, а вполне себе модель на основе некого ORM, который даже поддерживает Linq, но несколько отличающийся от реального. Это мог бы сделать любой, как вы понимаете, программист – взять все старые интервалы, которые хранились в базе данных, для того, чтобы зачислить сотрудников – все интервалы, начиная с определённой даты – взять и удалить. При этом смотрите, что получается. Мало того, что появляется какое-то удаление, ведь ранее не было ничего ни про какое удаление и во-вторых, у нас появляется DeparmentHistroyRepository. Ну, наверное, понятие «репозиторий» мы ещё как-то в предметную область сможем встроить, более-менее, но вот такая новая сущность, которая фактически является таблицей и хранит информацию по подразделениям – уже очень плохо ложиться на модель.
Что мы делаем дальше? Дальше нам у существующих надо завершить предыдущий период, в котором он работал и на день раньше сказать, что в подразделении сотрудник больше не работает.

Ну вот смотрите, согласитесь, что никаких таких слов, как выбрать, select, where, from, DataEnd, DepartmentHistoryRepository – вообще не было в модели предметной области. Эти понятия у нас есть только в коде и мы уже видим явные расхождения. И при этом обратите внимание, что обе этих операции в задаче вообще не присутствуют, они вызваны нашей технической необходимостью.
И наконец-то мы делаем саму задачу, это создаём саму сущность

При этом обратите внимание, что мы создаём эту сущность не у подразделения вообще, строго говоря это подразделение к себе кого-то зачисляет, а у какого-то DepartmentHistoryRepository, скорей всего, что это такое знают только программисты и то возможно не все. Дальше мы вызываем метод с другим названием – «создать новый» (CreateNew) – почему новый? Мы же ничего не создаём, мы же просто зачисляем человека.
А вот в случае Model Drive Design как это должно было бы выглядеть:

Вот, например – так. Я тут специально использовал русский язык, чтобы максимально приблизить соответствие модели предметной области, тому что мы используем в коде, насколько это возможно. Дальше если даже есть там какая-то логика, она должна быть инкапсулированной в этот метод и разработана подробней. Тогда, когда мы весь код пишем в таком стиле. Во-первых, его легко может прочитать человек, даже плохо знакомый с языком программирования, — там будет более-менее по-русски написано. В отличие от русского языка, отличие C# в том, что скобочки, запятые и точки и т.д. заменяются на различные междометья, предлоги и прочие связующие слова.
Я надеюсь, я в кратце смог описать, что такое DDD. Напомню, что это переработка знаний, когда мы разрабатываем предметную область – это единый язык, на котором мы все всегда должны между собой общаться. И моделирование на основе предметной области, обозначающее то, что мы модель эту не просто так разработали, а чтобы непосредственно её внедрить в коде.

Зачем нам может понадобиться DDD.

Это эффективный способ борьбы со сложностью. Действительно в сложных системах – хорошая модель предметной области уже сама по себе помогает бороться со сложностью. А когда мы её непосредственно внедряем в код, когда программисты, аналитики, специалисты предметной области все они работают в одних терминах, причём всегда и программисту не нужно думать, как ему из «авторов-читателей» перевести в датасеты, рекордсеты. Это существенно, это не то, что об этом программист вообще не должен думать, просто мы это явным образом отделяем. Отделяем от того, что есть. И это единый язык. Не стоит не дооценивать значение этой вещи, поскольку этот единый язык имеет непосредственное отображение код, ну практически любую фразу, которую мы говорим на этом языке, мы можем сразу проверить, даже чисто умозрительно. Можно ли её реализовать в коде или нет. Как правило, когда у нас код написан в несколько других терминах, — на это нужно потратить существенное время. И более того, сам уже по себе единый язык, само по себе наличие языка, даёт возможность существенно улучшить выработку требований. Достаточно известный факт тот, что качество проекта и скорость проекта зависит от хорошего определения его Scope, по большей части не чего-то там, а именно от того, что мы будем делать, а что не будем и определить это без единой терминологии, постоянно, каждый раз заново договариваясь про то, о чём мы говорим – достаточно сложно.
И всё это в итоге даёт низкую стоимость разработки и сопровождения, что в разработке корпоративных информационных систем, естественно, очень важно.

Я описал столько плюсов. А почему же мы можем не использовать DDD, почему мы можем от него отказаться? У нас есть некоторые проблемы. Не всё так хорошо, как хотелось бы.

Минусы DDD

Организационные проблемы, например, разделение анализа и проектирования, оно может быть как явным образом – в команде присутствуют аналитики и разработчики, которые вообще не участвуют в анализе, так и не явно, просто в голове человека, пусть он даже не участвует в анализе, но для себя он вначале анализирует и строит какую-то модель, а потом пытается её реализовать. Причём реализовать он её пытается, как правило, как-то по другому. В данном случае при DDD, мы должны сразу думать, как мы модель будем реализовывать. И например, если мы понимаем, что мы в таком виде не сможем модель реализовать – для нас очень важна производительность. То мы должны будем вносить в модель предметной области явным образом, в явном виде, в явных терминах на основании которых мы будем разговаривать потом с заказчиком и со всеми другими участниками проекта эти новые понятия – это достаточно тяжело, и обычно требуется некий опыт.
Также часто встречается чисто административная проблема, когда разработчик отстранён от анализа, и разработчики вообще могут ни разу не увидеть, для кого они всё это делают, когда выделяется отдельный отдел аналитиков. Это не то чтобы плохо, но просто аналитики, как правило, не представляют и не могут построить архитектуру от начала и до конца, так как не знакомы с необходимым числом технических подробностей. И за счёт этого у нас обязательно – ту модель, которую построят аналитики разработчик не сможет внедрить в код, потому что она не учитывает особенности реализации. И именно поэтому надо привлекать именно тех, кто непосредственно будет строить архитектуру приложения и будет писать на основе её код к проектированию модели, чтобы сразу можно было бы сказать — мы сможем так сделать или нет. И даже если бы кто-то ошибся, чтобы сразу было бы можно это оперативно исправить.
Отсутствие опыта DDD. Надо сказать, что DDD это в первую очередь изменение сознания внутри проектной команды, разработчиков, чтобы они привлекались к анализу, также аналитиков, чтобы они более внимательно смотрели на то, как это будет реализовываться. Так и руководителей проектов, которых требуется привлекать к разработке и анализу. Ну и сам по себе Model Driven Design, который является основополагающей частью DDD – требует некой ломки, потому что мы пытаемся внедрить то, что мы придумали в код, — всегда хочется где-то проскочить, вот здесь взять датасет, там что-то сделать ещё.
Ну и множество технических есть проблем. Все проблемы связаны с Model Driven Design. В первую очередь это плохие инструменты, для того, чтобы хранить как-то данные – очевидно, в объектно-ориентированных языках надо использовать какие-то средства. Обычно данные в корпоративных системах хранятся в реляционных базах данных. Это вынуждает нас выбирать какой-то преобразователь из реляционной базы данных в нашу объектную модель. Для этого существует даже много промышленных средств, таких как Hibernate и другие ORM, но все они имеют проблемы. Их сложно использовать и они далеки от идеала, для того, чтобы мы могли абстрагироваться от того, что у нас там какая-то база данных лежит внизу, зачастую это настолько важно, что приводит вообще к необходимости отказаться от DDD, иначе – системы не будет, пока мы будем бороться с плохим инструментарием. Ну и также в других областях и технологиях, в распределённых системах, например, у нас возникает ещё больше проблем в DDD, по непосредственному отображению нашей модели в код, у нас начинают в код пролезать совсем другие модели: модели взаимодействия между распределёнными системами, модель взаимодействия с базой данных, — просто модели программы, которые там совершенно не нужны.
Всё это может привести к тому, что применение DDD становится или невозможным или нежелательным, или очень дорого.
Ну на этом всё, я надеюсь, что я сделал некоторое краткое введение в DDD. И что у вас действительно есть инструменты для проектирования на основе моделей, то вы попробуете использовать этот подход.

Вопросы:

Вопрос: В чём разница между ООП подходом и DDD?
Ответ: ООП подход не призывает нас строить модель, ООП подход – это объединение данных с поведением, причём это может быть не связано с предметной областью. Датасеты, которые я приводил, Датаридеры – это тоже ООП подход, просто там объекты другие и поведение другое и они не имеют отношения к решаемой нами задаче и вызваны технологическими причинами. А DDD это именно набор подходов и взглядов, которые заставляют нас строить эти объекты определённым образом, непосредственно тем, как они устроены в реальном мире. При этом DDD нас призывает не как-то строить нашу модель, которую мы потом будем отражать на ООП, а также выделяя из неё все понятия явно и более близко к тому, на чём мы говорим. Хороший пример, который говорит, что мы работаем на DDD, это когда, мы говорим какую-то фразу, ставим какую-то задачу она точно также выглядит в коде, комментариев, без ничего – вот прямо так в коде и написано. Если там написано «рассчитать зарплату сотрудников», то в коде тоже будет написано «рассчитать зарплату сотрудников». Если написано, что «зароптала сотрудников, это количество рабочих дней * на оклад + количество отпуск * среднегодовую зп», то точно в таких же терминах, может правда на английском языке, если это удобней для языка, хотя это, конечно, тоже плохо – так и должно быть написано. А если у нас написано «select from db order by … group by …» — это уже признак того, что мы уже далеко отошли от Model Driven Design и наша модель уже не соответствует тому, что мы реализуем.

Вопрос: правильно ли я понимаю, что это переход от технических сущностей (листов, баз данных и др. вещей) к бизнес сущностям?
Ответ: Да, именно, так.

Вопрос: Это итеративный процесс. Сколько в среднем нужно итераций?
Ответ: это зависит от предметных областей. У некоторых сложных систем бывает очень простые предметные области. У Facebook, например, в самом начале была очень простая предметная область – это человек и его сообщения между людьми. Если говорить о сложной системе, то там число итераций вызвано не сколько сложностью моделей, сколько непосредственно изменяющимися бизнес-процессами, потому что мы начинаем разрабатывать модель, итеративно начинаем её реализовывать. А тут люди от бизнеса понимают, что они хотели немного другое. Тогда мы выделяем новые понятия. Как правило, этот процесс никогда не заканчивается, либо заканчивается тогда, когда система будет полностью реализована.

Вопрос: Когда вы применяете этот подход у вас есть некоторый overdraft, при каком размере проекта стоит использовать этот подход?
Ответ: Я действительно это забыл упомянуть, DDD имеет смысл только в очень крупных проектах. Если проект не большой, то скорей всего и предметная область не большая, а значит мы можем хотя бы попытаться в голове удержать и предметную область и нашу программную модель (рекордсеты и т.п.). Но для проектов от нескольких человеко лет, например от пяти, ну это условно, сами понимаете, это зависит от непосредственно от проекта. Вся сложность проекта должна заключаться в предметной области. Если нам надо оптимизировать производительность проекта, обрабатывать миллиард запрос на одного пользователя, то эту задачу тяжело будет описывать в терминах бухгалтерии, здесь будет много технических подробностей, здесь тоже можно использовать DDD, но здесь программисты для себя могут построить удобную модель и работать с ней. А вот если мы работаем со сложной предметной областью, то та модель, которую разработали аналитики – она как правило, полностью не отображается в код и выглядит несколько иначе.

Вопрос: А у вас не может быть так. Что вы вот всё так красиво пишете, а вам поступает новое требование, что мол надо зарплату сотрудников распараллелить на несколько машин и вы не можете это так просто в своей модели сделать.
Ответ: Тут есть два варианта. Если у нас есть уже более-менее стабилизированная система. И у нас там есть одна такая страничка, где пользователи ждут два часа на то, что она работает. И её нам надо с оптимизировать, то в принципе здесь можно отойти от DDD и всего остального и если это достаточно локально и заняться таким мелким подкручиванием. Если же получается так, что это проходит по всему проекту и мы чувствуем, что это будет встречаться постоянно. Значит нам придаться менять модель предметной области, причём менять её таким образом, что в неё попадут понятия, касающиеся производительности, распараллеливания на 10 машин и всего остального, и наша задача будет – во-первых, уговорить заказчика всё это понимать. Вот смотрите, бухгалтер, когда работает с системой даже с простейшим принт-сервером, у него появляется простейшее понятие – соединение, оно может быть разорвано, его может не быть. Мы можем сказать, что бухгалтер работает со счетами: дебет-кредит и к чему ему «соединения»? мы не будем вносить это в предметную область, но это не так, если вы подойдёте к любому человеку и скажите, вот смотри – у тебя соединение разорвалось, он прекрасно поймёт, о чём идёт речь. Или вот «связи нет» — даже в любом магазине крупном, где компьютерные системы зависают – все кто стоят в очереди прекрасно поймут этот термин. Они есть в предметной области, их нужно туда явно вносить! Если вам сказали сделать крупную оптимизацию и она касается всего проекта и многое меняет, то придётся вам менять всю предметную область и вводить в неё новые понятия, касающиеся производительности, распределённости и прочих вещей, которых от вас требуют.

Автор: Polazhenko