Нашел крайне интересный материал для любителей нестандартного программирования в Apex. А нестандартность в том чтобы динамически работать с Apex классами что позволит избавиться от жестких зависимостей в коде.
Как бы особого нового тут нет, но для себя я открыл вот этот пункт "LEVERAGE NATIVE INTERFACES". Можно вообще забыть про какие либо зависимости, даже через глобальные интерфейсы. Код будет, конечно, бросаться в глаза, но это работает.
Приглашаю к ознакомлению!
https://salesforce.stackexchange.com/questions/6016/managed-package-integration-without-extensions-or-dependencies
Вопрос только зачем делать все эти извращения и использовать вещи не по назначению?
Блин, честно сложно ответить на данный вопрос.
Бывают и такие задачи.
Уточни плиз, ты реально не знаешь для чего делать такие извращения или просто противник использования вещей не по назначению. 
Задачи да, бывают, и 1й описанный вариант COMMON 3RD PACKAGE видится более предпочтительным вариантом. Да и, как правило, всегда можно найти какое-то стандартное решение, паттерн.
Конечно, я против использования вещей не по назначению) Это как правило выливается в хождение по грани лимитов, или выход из них)
А так, я думаю, этого парня часто вспоминают, кто его решения(2. LEVERAGE NATIVE INTERFACES и 3. WILD AND CRAZY) потом поддерживают)
Вот теперь все понял. И соглашусь.
Решение с глобальными интерфейсами и 3RD PACKAGE элегантное. Но появляется зависимость на этот 3RD PACKAGE и если его понадобится выпилить, то уже будет проблема.
2. LEVERAGE NATIVE INTERFACES грязный хак, но блин, он простой как валенок. Хотя у неподготовленного разработчика, который читает код, вызовет недоумение.
3. WILD AND CRAZY - еще более запутанный вариант для понимания и поддержки.
Понятное дело что пихать эти хаки на каждом шагу не стоит, но иметь в арсенале необходимо. Я к примеру до этого гемороился с глобальными интерфейсами и когда вставал вопрос снести пакет - то приходилось выпиливать зависимости на этот глобальный интерфейс. А оказывается можно просто воспользоваться стандартными системными интерфейсами (хотя бы на время разработки до получения конечного продукта)
Тут просто нужно применить и реализовать Dependency Inversion Principle, чтобы 3rd Package инициализировал связь или дергал глобальные интерфейсы 2х других пакетов. Тогда эти 2 пакета ничего не будут знать о 3RD PACKAGE и не будут от него зависить, только 3RD PACKAGE будет завить от 2х пакетов, которые связываются.
Так в том то и проблема - теперь пакеты зависят не один от другого а от них обоих зависит 3rd Package. Сменили шило на мыло. Теперь чтобы удалить один из пакетов надо сначала снести 3rd Package.
Вопрос в том как заставить 2 пакета взаимодействовать между собой, но при этом полность развязать их в коде. Чтобы можно было любой из пакетов удалить с орга и при этом второй никак этому не помешал и даже продолжил работать (с какими либо ограничениями).
Так 3rd Package не нужен на орге, если сносится один из пакетов, которые связывались. 3rd Package - только связть. Нет одного из связуемого - и сама связь удаляется.
2й пакет сносим вместе со связующим 3м и все, 1й пролоджает работать как ничего и не было.
мы для интеграции пакетов вот такую штуку юзаем
https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_interface_System_Callable.htm
довольно удобно
Рустам, ты прям в точку со своим советом. Это именно то что надо!!!
Системный интерфейс и именно предназначенный для того что я описал выше.
Я использовал другие интрефейсы, чем заслужено получил укор в свой адрес
Но Callable Interface это прям точто надо!!!!!!!!!!!!!!!
Enables developers to use a common interface to build loosely coupled integrations between Apex classes or triggers, even for code in separate packages. Agreeing upon a common interface enables developers from different companies or different departments to build upon one another’s solutions. Implement this interface to enable the broader community, which might have different solutions than the ones you had in mind, to extend your code’s functionality.
Огромное спасибо за подсказку!!!!
ЗЫ: Надо, блин, почаще в доку заглядывать 
