Clean Dependencies: Isolated Features & Handling Duplication

Overview

Maintaining clean dependencies is important for building scalable and maintainable applications, This document describes the importance of isolated features, the challenges posed by duplicate code, and a structured approach to managing shared functionality without introducing unwanted coupling

Isolated Features: The Path to Clean Dependencies

Why Isolated Features Matter

Isolated features are the foundation of clean architecture. By designing features to be self-contained and independent, we ensure that our applications are:

• Easier to scale ??
• Simpler to test ??
• More maintainable

However, real-world projects often introduce duplicate functionality, leading developers to centralize shared logic into a single service. While this might seem like a smart solution, it can lead to coupled code where hidden dependencies form between features, making refactoring and scaling increasingly difficult.

The Challenge of Duplication

When multiple parts of an application require the same functionality, developers often:

• Identify the duplicate logic.
• Move it to a shared service.
• Use the service across multiple features.

While this reduces repetition, it can introduce tight coupling, which contradicts the goal of isolation. The question then becomes: How do we eliminate duplication while keeping features truly independent?

The "Go One Step Back" Rule

A Simple Principle for Handling Duplication

"In case of duplication, let go one step back."

Whenever we encounter duplicated logic between features, instead of immediately creating a global service, we step back and look for the closest parent scope that can logically house the shared functionality.

Applying the Rule in Sub-Features

Consider a main feature containing two sub-features (Sub-Feature A and Sub-Feature B). If both sub-features require the same functionality, the duplication should be handled one level up within the main feature’s service. This keeps the sub-features independent while eliminating redundant code.

If duplication arises deeper (e.g., sub-sub-sub features), we continue stepping back to the parent, grandparent, or great-grandparent feature, identifying the best place to house the shared logic.

Handling Duplication Across Main Features

What if duplication exists between separate main features? In this case, instead of coupling them together via a shared service, we introduce a Cross Features folder. This folder houses shared logic that is relevant across multiple main features while ensuring they remain independently modular.

Folder Structure Example:

app/
  features/
    featureA/
    featureB/
  cross-features/
    cross-feature-a-b.ts        

By structuring shared functionality under Cross Features, we avoid tightly coupling our main features while still reusing code effectively.

Summary

• Isolated features are essential for clean dependencies.
• Duplicate functionality is common but should be managed strategically.
• The "Go One Step Back" rule helps identify the best place to house shared logic.
• Duplication in sub-features should be resolved at the closest parent level.
• Duplication across main features should be handled within a dedicated Cross Features folder.