Пишите на языке предметной области

Сравните две нотации написания кода.

В одной вы увидите:

if (portfolioIdsByTraderId.get (trader.getId ())
  . ContainsKey (portfolio.getId ())) {...}

Не сразу можно понять, что делает этот код. Кажется, это - получение идентификатора объекта trader, с его дальнейшим использованием для получения карты, то есть, по-видимому, карты карт, и проверка на существование в этой внутренней карте идентификатора объекта portfolio. Вы чувствуете, что надо думать дальше. Объявление portfolioIdsByTraderId выглядит следующим образом:

Map <int, Map <int, int>> portfolioIdsByTraderId;



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



В другой нотации вы столкнетесь со следующим:



if (trader.canView (portfolio)) {...}



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

Итак, с какой из этих нотаций записи кода Вы предпочли бы работать?

Давным-давно у нас были только самые основные структуры данных: биты, байты и символы (на самом деле просто байт, но мы хотели бы сделать вид, что это были буквы и знаки препинания). С десятичными числами было немного сложнее, так как эта система счисления не совсем сочетается с двоичном форматом работы аппаратной части, поэтому мы вынуждены были использовать несколько типов данных с плавающей запятой. Потом появились массивы и строки (на самом деле это были просто разные типы массивов). Тогда мы получили возможность работать со стеком, очередью,хэш-таблицей, связанным списком, разреженным списком и множеством других интересных''структур данных, которых не существует в действительности''. IT-специалисты тратили много усилий на отображение объектов реального мира в рамках нашего ограниченного набора структур данных. Настоящие гуру даже помнят, как им это удавалось.

И наконец, мы получили определяемые пользователем типы! Хорошо, это не ново, но это полностью меняет условия игры. Если ваша модель процесса содержит такие понятия, как торговцы и портфели, вы можете моделировать их собственными типами, скажем, Trader и Portfolio . Но гораздо важнее то, что вы можете моделировать''отношения между ними'', используя терминологию предметной области.

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

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

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

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



Перевод: Протченко Алексей a.k.a. Severyanin

Лицензия: [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3] 

Оригинал: Code_in_the_Language_of_the_Domain

Автор [[Dan North]]
Лицензия: [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]