Это зависит от работодателя. Многие IT компании открыты к перевозу сотрудников. Когда я искал компанию у меня было три собеседования, 2 компании в итоге дали оффер, я принял афер XING и поехал в Гамбург. Т.к. процесс оформления визы проще чем в США и сотрудника не надо потом ждать до сентября (как в США), то многие компании идут на это. Плюс от компании нужно не так много. Визу сотрудник оформляет сам. Нужен только контракт на зарплату выше минимально допустимой для BlueCard и профильное высшее образование одобренного ВУЗа.
Нет, не придется. Отступление: я говорю в рамках руби. Чтобы Быть бегуном у всех должны быть ноги и все. А в роли Бегун у нас просто определена функция реализующая бег через ноги.
Вы предлагаете наследовать роль от модели, что неверно, потому что роль может быть дана совершенно разным объектам. Например объекты Человек, Собака, Лошадь, роль — Бегун. Очень общий пример, но думаю мысль ясна.
В руби ваш подход лучше реализовать через модули
class User
include Author
...
end
но и это противоречит DCI, роль назначается в контексте.
А затем объект вместе с ролью собирается GC. Контексты должны быть лаконичными и односложными, как и контроллеры. Это идеальная ситуация конечно, но к этому нужно стремиться.
В большом проекте в таких функциях потом легко утонуть. К тому же к чему привязана эта функция, где она лежит? Это не ООП подход.
Разделяя функционал на роли и контексты мы улучшаем читаемость кода. Модели — отдельно, действия (роли) — отдельно, события (контексты) — отдельно.
В идеале нужно разделить даже доменные модели и модели хранения данных (ORM) и абстрагировать свою бизнес логику от фреймворка вплоть до выделения ее в отдельную библиотеку.
Такой код проще тестировать, поддерживать и развивать.
Штука в том, что определенные роли нужны в определенном контексте и не стоит нагружать модель всеми ролями сразу. В парадигме DCI мы присваиваем роль объекту в контексте прямо перед использованием, мы не расширяем класс, а только конкретный объект. Это возвращает нас к думанию объектами, а не классами.
Плюс такого подхода — чистые доменные модели, которые ничего не знают о ролях и роли, которые не привязаны ни к одной из моделей.
coderwall.com/p/lhsrcq
В руби ваш подход лучше реализовать через модули
но и это противоречит DCI, роль назначается в контексте.
Разделяя функционал на роли и контексты мы улучшаем читаемость кода. Модели — отдельно, действия (роли) — отдельно, события (контексты) — отдельно.
В идеале нужно разделить даже доменные модели и модели хранения данных (ORM) и абстрагировать свою бизнес логику от фреймворка вплоть до выделения ее в отдельную библиотеку.
Такой код проще тестировать, поддерживать и развивать.
Плюс такого подхода — чистые доменные модели, которые ничего не знают о ролях и роли, которые не привязаны ни к одной из моделей.
А сегодня сижу и переношу остальные.