При каких условиях мы можем оправдать попытку ввести единый размер, подходящий для всех терминов, если это противоречит опыту работы?

Question

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

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

Итак, какое оправдание в этом случае можно использовать, чтобы попытаться ввести термин «один размер подходит всем», если он противоречит опыту работы?

Answer 1

Ваш аргумент "напрашивается на вопрос" (в логическом смысле этого термина).

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

Вы предлагаете: «пытается ввести один термин, который будет использоваться во всем исходном коде, а также в разговорах».У всех клиентов может возникнуть путаница ".В самом деле, это может ... и может также избежать путаницы.

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

Для руководства по стилю вполне разумно объявить предпочтительный термин и ожидать, что все будут следовать ему, как единообразие в этом.Ситуация имеет большой потенциал.Используя ваш пример, в моем конкретном проекте я использую термин «предложение» вместо «ставка» каждый раз, и код лучше для него.Я могу указать на другие термины, которые еще не были стандартизированы, и увидеть дополнительные усилия, которые требуются для их кодирования.

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

(Как ни странно, я работал над этиморганизация, в которой в пользовательской документации телефоны упоминаются как «голосовые терминалы», поскольку термин «телефон» был неоднозначным; я подозреваю, что он зашел слишком далеко?)

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

Answer 2

Вы сказали,

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

А как насчет ограниченного контекста? Возможно, когда один и тот же термин означает две разные вещи, они должны находиться в двух разных контекстах?

Я цитирую со страницы Мартина Фаулера на Ограниченный контекст :

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

Его и твои описания проблем звучат одинаково.