객체지향 설계 고수님들 조언 좀 부탁드립니다.

몇달째 책이나 강의를 통해 설계관련 공부를 해도 도무지 해결이 안되는 문제가 있어 조언을 부탁드립니다.

많이들 하시는 OOP, Unit Test, SOLID 원칙, Design Pattern들 개념적으로는 잘 이해가 갑니다.
하지만 예제로 사용되는 코드들은 사실 너무 간단해서 막상 실무에 적용하긴 뭔가 한계가 있는 듯 합니다.
저를 제일 괴롭히는 문제는 Class들 상호간의 Relationship과 Testability입니다.

예를 들어...
처음에는 단순한 클래스(ClassA)를 작성합니다.
그러다가 클래스의 로직이 증가하면서 SRP에 따라 클래스(ClassB)를 분리합니다.
ClassB를 분리했기 때문에 원래 ClassA 자체의 로직이 좀 더 단순해지는 것까지는 좋습니다.
문제는 ClassA와 ClassB 사이의 (넓은 의미에서)의존성이 생긴다는 겁니다.
즉, ClassA와 ClassB는 유사한 책임을 가지고 있다가 분리된 것이어서 (예외도 있지만) 어떤식으로든 상호참조를 가져야 하는 경우가 많습니다.
더 나아가, 분리된 ClassA와 ClassB에 대해서도 점차 로직이 증가하면서 다른 클래스가 분리되면 그 클래스들과의 상호작용이 생기게 됩니다.
클래스 몇개만 만들어도 복잡한 연결관계를 피할 수 없더군요.

(또, 의존성을 줄이기 위해 상호참조를 일방참조로 바꾸는 과정에서 많은 경우 ClassA의 멤버변수 중 일부를 ClassB 에서도 멤버변수로 가지고 있어야 하는 경우도 있습니다.
이런 경우 여러 클래스가 같은 종류의 멤버를 가지고 있어서 코드 중복의 느낌이 납니다. 다만, 이건 복잡도의 문제는 아니기에 패스..)

클래스 로직을 단순하게 만드는 과정에서 역설적으로 클래스의 수가 증가하고
무엇보다도 클래스들 상호간의 참조관계가 폭발적으로 증가하게 됩니다.
운이 좋아서 디자인 패턴이라도 적용할 수 있는 형태면 그나마 좋지만 그건 일반적인 경우도 아니고요
또 하나의 문제는 이런 클래스는 여러 다른 객체들의 참조를 가지고 있기 때문에 테스트하기가 까다롭습니다.

클래스 하나를 단순하게 작성하기는 쉽습니다.
그런데 클래스를 단순하게 하면서 생기는 사이드 이펙트로서, 다른 클래스들 상호간의 관계가 복잡해 지는 문제를 도무지 어떻게 해야 할지 모르겠습니다.

여러 디자인 관련 책들을 봐도 SOLID 원칙등을 얘기하며 클래스를 단순하게 하고
클래스들 사이에 Loosely Coupling을 유지하기 위해 인터페이스 등를 활용하라라고만 나와 있지
정작 그런 과정에서 발생하는 클래스들간의 관계의 복잡성을 속시원히 해결해 주는 책은 없더군요.

이런 고민들은 비단 저 혼자만 하는 것은 아닐텐데... 혹시 조언 좀 해 주실 수 있는 분 계신가요?

P.S.
하스스톤 클라이언트 코드를 한번 디컴파일 해 봤는데 Card 라는 클래스는 클래스 하나에 멤버필드만 40여개이고, 라인수가 3000줄이 넘네요..
블리자드 개발자가 객체 지향 설계방법을 모르는 사람들도 아닐텐데, 이렇게 작성하는 것은 뭔가 한계가 있기 때문은 아닐런지..