Прочитав статью Джеймиса Бака Integration API vs. Internal API, я почувствовал необходимость подробнее остановиться на теме интеграционного API, основываясь на собственном опыте, но из совершенно другого, возможно, более социального или культурного контекста. аспект.
Я работаю над унаследованной кодовой базой уже несколько лет, и одна из вещей, которую мне постоянно трудно понять: «Эта концепция или операция существует только для интеграции?» Под унаследованной кодовой базой я подразумеваю систему без каких-либо автоматических тестов, изначально созданную многими разными людьми с течением времени без четких структурных рекомендаций (или архитектуры).
В этой системе возникла модель перемещения всего, что происходит на уровне домена или службы с первого раза. Я думаю, вы могли бы назвать это упреждением ничего не повторять по сравнению с принципом Не повторяйся (DRY). Однако разговоры о DRY очень распространены, поэтому я не буду определять здесь какие-либо новые аббревиатуры.
В то время как наша кодовая база страдает от ряда проблем, этот превентивный удар в надежде никогда не повториться ни с кем другим, нанес, пожалуй, наибольший ущерб. Нас это тоже не вылечило даже от повторения — с количеством различных возможных инфраструктурных операций уже невозможно вспомнить, какие реальные операции уже поддерживаются. Это относится даже к самым простым служебным службам, имеющим несколько реализаций дедупликации списков строк.
Дублирование усилий по дедупликации для списков строк — хороший способ продемонстрировать следующую проблему с (упреждающим) стремлением к DRY: Что, если вы представляете плохую идею как простой в использовании сервис? В случае «дедупликации для строковых списков» очевидно: учитывая простую инфраструктурную поддержку дедупликации, никто никогда не думал об использовании структуры данных Set.
Пример дедупликации хорош тем, что его легко понять любому. Как насчет более сложных плохих идей, связанных с предметной областью, которые у вас есть в настоящее время? Знания об истоках почему существует этот простой в использовании сервис для конкретных доменов могут быть утеряны, но конечный результат кажется приемлемым, так в чем же проблема его использования?
Лекарство от всего этого слишком простое. Вы допускаете дублирование кода. Это просто технический долг. Вы должны справиться с этим в конце концов, но даже до удаления дублирования вы и ваша команда должны просто знать об этом. Возможно, когда вы заметите, что один и тот же код появляется в трех разных местах, вы могли бы начать обсуждение, нужно ли что-то для этого делать. Возможно, кто-то поймет, что существует структура данных Set.
Как насчет дублирования концептуального уровня? Следует ли это терпеть? Интуиция подсказывает, что нет, это определенно должно быть DRY'd out.
Однако, если мы говорим о различных ограниченных контекстах в смысле концепции Эванса, ориентированной на предметную область, это зависит от обстоятельств. Например, простое приложение может иметь один ограниченный контекст с дополнительным контекстом, ограниченным интеграцией. Идея ограниченных контекстов позволяет вам ограничить ваши проблемы интеграции от вашего реального приложения, предлагая определенную степень разделения. Хотя в фактическом определении ограниченных контекстов есть нечто большее, сейчас достаточно рассматривать его как способ разделения задач.
Должны ли мы терпеть дублирование между разными контекстами? Абсолютно.
Сегодня они могут показаться дублированными, но поскольку мы говорим об интеграции как об интеграции с какой-то другой системой, эти две системы, скорее всего, развиваются очень разными темпами.
Рефакторинг вашего пути от DRY'd out, ни одной строки кода не дублирует кодовую базу к той, которая поддерживает эволюцию различных систем, не является невозможным, но это много. работы. Прежде чем сделать это, у вас уже будет код, в котором операция приспосабливает две реальные системы с некоторыми условными структурами, смешанными с общим поведением. Определить, какие блоки кода относятся к внутренней или внешней системе, скорее всего, сложно — комментарии, если вы найдете такие, могут быть устаревшими и неправильными.
Так что делайте что-нибудь кроме упреждающего DRY. Оставьте его в покое, если он находится между системами и ограниченными контекстами, или на позже, но запомните это. Вместо этого хорошие вещи включают в себя написание тестов для вашего кода, соответствующих фактическому использованию. Наличие тестов делает дедупликацию более поздней.
Примечание: это не моя первоначальная идея, многие более мудрые обсуждали ту же тему. Помимо уже упомянутого Эрика Эванса, одним из таких является Рич Хикки в его великих речах.
