Посадіть пухких моделей на дієту з занепокоєнням

Різні моделі у вашому додатку Rails часто поділяють набір наскрізних проблем. У Basecamp ми маємо майже сорок таких проблем з такими іменами, як Trashable, Searchable, Visible, Movable, Taggable.

моделей

Ці проблеми включають як доступ до даних, так і логіку домену щодо певного зрізу відповідальності. Ось спрощена версія позначеного концерну:

Потім це занепокоєння можна змішати з усіма моделями, які можна позначити, і у вас буде єдине місце для оновлення логіки та аргументів щодо цього.

Ось подібне занепокоєння, коли все, що ми додаємо, - це метод одного класу:

Побоювання також є корисним способом вилучення фрагмента моделі, який не здається частиною її сутності (те, що є і що не є суттю моделі, - це нечітка лінія та довше обговорення), не переходячи на повну єдину відповідальність Принцип та ризик створення повітряних запасів об'єкта.

Ось проблема Dropboxed, яку ми поєднуємо лише з моделлю Person, що дозволяє нам пізніше направляти вхідні електронні листи від потрібної людини:

Зараз це, звичайно, не єдиний спосіб нарізати пухкі моделі. Для видимого занепокоєння ви можете мати Viewer.visible (current_account.posts, to: current_user) і інкапсулювати запит в окремому об’єкті. Для Dropboxed ви можете мати самостійний клас Dropbox.

Але я вважаю, що проблеми часто є лише потрібною кількістю абстракції і що вони часто призводять до більш дружнього API. Я набагато віддаю перевагу current_account.posts.visible_to (current_user) перед залученням третього об'єкта запиту. І звичайно, такі речі, як Taggable, яким потрібно додати асоціації до цільового об'єкта, важко зробити будь-яким іншим способом.

Це правда, що це призведе до поширення методів на деяких об’єктах, але це мене ніколи не турбувало. Мені цікаво, як я взаємодію зі своєю базою коду через джерело. Те, що виникає загроза змішати все це разом у велику модель під капотом, не має значення для розуміння моделі домену.

Ми використовуємо це поняття вилучення проблем з пухких моделей у всіх додатках на 37 сигналів протягом багатьох років. Це призвело до моделі домену, яка є простою та зрозумілою без зайвих церемоній. Модель домену Basecamp Classic наразі 8+ років, і вона все ще зміцнюється з використанням проблем.

Цей підхід до розбиття логіки домену на проблеми дещо схожий на поняття DCI про Ролі. Він не має акробатики мікшину під час виконання, а також не має припису «твої моделі повинні бути повністю позбавлені логіки», але, крім цього, це часто призводить до отримання подібної логіки з використанням подібних назв.

У Rails 4 ми запрошуємо програмістів використовувати проблеми з типовими програмами/моделями/проблемами та програмами/контролерами/турботами, які автоматично є частиною шляху завантаження. Разом з обгорткою ActiveSupport: Concern це достатня підтримка, щоб цей легкий механізм факторингу засяяв. Але ви можете почати використовувати цей підхід із будь-яким додатком Rails вже сьогодні.