Refactoring a legacy codebase with a god Repository and incomplete Clean Architecture

I'm currently working on a large legacy project that tried to implement Clean Architecture combined with MVVM, but unfortunately didn't fully adhere to the principles. One major problem: The repository layer simply forwards raw data from the data source (network api) directly to the ViewModel. The transformation and formatting of the data is done in the ViewModel itself — often using private helper methods. This makes the ViewModel hard to test and violates separation of concerns. We’re planning a refactoring, and we want to move the transformation logic elsewhere. However, we’re facing a challenge: There is one huge, heavily-used repository class "God Repository" that is referenced in a large number of places throughout the codebase. Although we have multiple repositories, this one in particular has grown into a superclass-like dependency, and it's used across many features. Mainly because it's pointing to our main network API and delivers us data for most features. Data transformation logic varies across different consumers (ViewModels), so there’s no single, consistent transformation. Ultimately, we want to cleanly separate transformation logic and reduce the responsibility and surface area of this repository. We're currently considering these possible strategies: Introduce Use Cases that act as intermediaries between ViewModel and Repository. These Use Cases would handle all business logic and transformation, so eventually, the God Repository could be phased out or minimized. Introduce a Domain Layer with entities and services responsible for transforming the raw data. This could involve patterns like Mappers, Adapters, or Domain Services. Refactor the God Repository into smaller, more modular repositories over time — each scoped to a specific feature or domain area Our main goal should be to refactor piece by piece, so we don't have to face issues when changing to much of the codebase. So now I’m wondering: How would you approach refactoring a God Repository that’s tightly coupled across many parts of a legacy codebase? Are there any design patterns or techniques (e.g., Facade, Strategy, Visitor, etc.) that you’ve found useful for cleanly handling this kind of transformation?

Apr 15, 2025 - 09:57

I'm currently working on a large legacy project that tried to implement Clean Architecture combined with MVVM, but unfortunately didn't fully adhere to the principles.

One major problem: The repository layer simply forwards raw data from the data source (network api) directly to the ViewModel. The transformation and formatting of the data is done in the ViewModel itself — often using private helper methods. This makes the ViewModel hard to test and violates separation of concerns.

We’re planning a refactoring, and we want to move the transformation logic elsewhere. However, we’re facing a challenge:

There is one huge, heavily-used repository class "God Repository" that is referenced in a large number of places throughout the codebase.

Although we have multiple repositories, this one in particular has grown into a superclass-like dependency, and it's used across many features. Mainly because it's pointing to our main network API and delivers us data for most features.

Data transformation logic varies across different consumers (ViewModels), so there’s no single, consistent transformation.

Ultimately, we want to cleanly separate transformation logic and reduce the responsibility and surface area of this repository.

We're currently considering these possible strategies:

Introduce Use Cases that act as intermediaries between ViewModel and Repository. These Use Cases would handle all business logic and transformation, so eventually, the God Repository could be phased out or minimized.
Introduce a Domain Layer with entities and services responsible for transforming the raw data. This could involve patterns like Mappers, Adapters, or Domain Services.
Refactor the God Repository into smaller, more modular repositories over time — each scoped to a specific feature or domain area

Our main goal should be to refactor piece by piece, so we don't have to face issues when changing to much of the codebase.

So now I’m wondering:

How would you approach refactoring a God Repository that’s tightly coupled across many parts of a legacy codebase?
Are there any design patterns or techniques (e.g., Facade, Strategy, Visitor, etc.) that you’ve found useful for cleanly handling this kind of transformation?