Nguyễn Khánk's Wiki

# Reusability

# Overview

Code reusability is the cornerstone of efficient and maintainable software development. It involves writing code in a way that can be used repeatedly in different parts of a project or even in entirely separate projects. This practice significantly boosts productivity, reduces development time, and improves code quality.

# Why is Reusability Important?

  • Saves Time: Reusing existing code eliminates the need to rewrite the same logic multiple times.
  • Reduces Errors: Well-tested code is less likely to introduce bugs when reused.
  • Improves Maintainability: A smaller codebase with reusable components is easier to understand and modify.
  • Enhances Consistency: Shared code promotes consistent behavior and style across different parts of a project.
  • Accelerates Development: By focusing on new features, developers can build applications faster.

# Techniques

  • Functions and Methods: Encapsulate specific tasks into reusable functions or methods.
  • Modules and Libraries: Create self-contained units of code for specific functionalities.
  • Classes and Objects: Define reusable blueprints for creating objects with specific attributes and behaviors.
  • Design Patterns: Apply proven design patterns to structure code for reusability.
  • Code Refactoring: Continuously improve code structure and readability to enhance reusability.

# Examples

  • Mathematical functions: sqrt, pow, sin, cos are reusable across various applications.
  • Data structures: Lists, arrays, dictionaries, and sets are fundamental building blocks.
  • UI components: Buttons, input fields, and menus can be reused in different parts of an interface.
  • API clients: Libraries for interacting with external APIs can be shared among projects.

# Challenges

  • Code Coupling: Tightly coupled code can hinder reusability.
  • Performance Overhead: Excessive function calls or method invocations might impact performance.
  • Maintainability: Reusable code should be well-documented and easy to understand.
  • Licensing: Be aware of licensing restrictions when reusing external code.

# Best Practices

  • Write clean and modular code.
  • Use meaningful names for functions and variables.
  • Test your reusable code thoroughly.
  • Consider performance implications.
  • Document your code effectively.
  • Leverage version control to manage code changes.

# Helpers vs Utils

Reference: https://dev.to/victor1890/exploring-the-contrast-helpers-and-utils-demystified-47bo

# Utils (Utilities)**:

  • General purpose: Utility functions or classes are designed to be used across different parts of your project. They handle common tasks that are not specific to any particular domain or feature.
  • Independent: Ideally, utils are stateless and don't rely on any external dependencies. This makes them reusable and easier to test.

# Helpers**:

  • More specific: Helper functions or classes can be more specific to a particular module, component, or feature. They might encapsulate logic related to a specific use case.
  • Can be stateful: Helpers can sometimes have an internal state or rely on external dependencies specific to their context.

# Key Differences

Feature Helpers Utils
Scope Often more specific to a component or feature Typically more general-purpose
Coupling Might be more tightly coupled to other code Often loosely coupled, standalone functions
Complexity Can range from simple to complex, depending on the task Generally simpler, focused on core utilities

# Clean Architecture

Clean architecture is a software architectural pattern that emphasizes separation of concerns, testability, and independence from external frameworks. One of its key benefits is its strong support for code reusability.

# How Clean Architecture Promotes Reusability

  • Independent Core: The core of your application, containing business logic and domain entities, is completely isolated from external frameworks and databases. This makes it highly reusable across different platforms and technologies.
  • Dependency Rule: The dependency rule ensures that code in outer layers can depend on code in inner layers, but not vice versa. This promotes loose coupling, making components more easily replaceable and reusable.
  • Entities: These are the heart of your domain model and represent the core business concepts. Entities are inherently reusable across different use cases and applications.
  • Use Cases: While less reusable than entities, use cases can still be adapted for different scenarios. They often encapsulate specific business workflows and can be reused within a similar domain.
  • Data Access Layer: This layer is responsible for interacting with data sources. While specific implementations might vary, the abstractions defined in the interface can often be reused.

# Shared Kernel Module

A shared kernel module is a component that is shared between multiple bounded contexts in a domain-driven design (DDD) architecture. It's a strategic design pattern aimed at maximizing code reuse and consistency across different parts of the system.

# How Shared Kernel Promotes Reusability

  • Common Language: By sharing a kernel, different bounded contexts can use a common language, ensuring consistent terminology and understanding.
  • Code Reuse: The shared kernel contains core business rules and logic that can be directly used by multiple bounded contexts, avoiding code duplication.
  • Consistency: Shared models and invariants guarantee consistency across the system, reducing the risk of discrepancies.

# Key Considerations

  • Tight Coupling: Overusing a shared kernel can lead to tight coupling between bounded contexts, reducing autonomy and increasing maintenance costs.
  • Change Impact: Modifications to the shared kernel can affect multiple bounded contexts, requiring careful consideration and impact analysis.
  • Domain Complexity: The shared kernel should be limited to truly core business concepts. Introducing too many details can hinder reusability and increase complexity.

# Best Practices

  • Identify Core Business Concepts: Carefully select the elements to include in the shared kernel, ensuring they are essential to multiple bounded contexts.
  • Define Clear Boundaries: Establish clear boundaries between the shared kernel and other bounded contexts to prevent excessive coupling.
  • Version Control: Implement a versioning mechanism for the shared kernel to manage changes and their impact on dependent contexts.
  • Anti-Corruption Layer: Consider using anti-corruption layers to isolate bounded contexts from changes in the shared kernel. Continuous Evaluation**: Regularly review the shared kernel to ensure it remains valuable and doesn't become a bottleneck.

# Event-Driven Architecture

# Reusability within the Event Store

Event stores are a cornerstone of event-driven architecture, providing a persistent record of system state changes. While the concept might seem inherently tied to specific domains, there's a significant potential for reusability within the event store itself and the surrounding infrastructure.

  • Event Schema:
    • Generic event structure: Define a base event structure with common properties (e.g., timestamp, event ID, aggregate ID) that can be reused across different event types.
    • Event metadata: Standardize metadata fields (e.g., correlation ID, causation ID) to facilitate event tracing and correlation.
  • Event Store API:
    • Abstraction layer: Create a generic event store API that can interact with different underlying storage technologies (e.g., relational databases, NoSQL, message queues).
    • Common operations: Implement core operations like append, read, and query in a reusable manner.
  • Event Serialization:
    • Flexible serialization formats: Support multiple serialization formats (e.g., JSON, Protobuf) to accommodate different systems and performance requirements.
    • Schema evolution: Implement strategies for handling schema changes without breaking existing consumers.

# Reusability in EDA

  • Event Producers and Consumers:
    • Event bus: Create a reusable event bus component to decouple event producers and consumers.
    • Event publishers and subscribers: Develop generic frameworks for publishing and subscribing to events.
  • Event Processing:
    • Event handlers: Design reusable event handlers for common event patterns (e.g., command handlers, projections).
    • Event sourcing: Implement a generic event sourcing framework that can be applied to different aggregates.
  • Event Projection:
    • Projection frameworks: Develop reusable tools for creating read models from event streams.
    • Materialized views: Provide mechanisms for creating materialized views for performance optimization.

# Frameworks vs. Libraries

Frameworks and libraries are both essential tools for software development, offering pre-written code to streamline processes. However, they differ significantly in terms of control, structure, and reusability.

# Libraries

  • Purpose: Provide reusable code for specific tasks.
  • Control: Developers have full control over how and when to use library functions.
  • Structure: Typically don't impose a specific project structure.
  • Reusability: Highly reusable, often across different projects and languages.
  • Examples: Lodash, jQuery, React Router.

# Reusability in Libraries

  • Function-level reuse: Individual functions can be imported and used independently.
  • Code sharing: Libraries often promote code sharing within a project or across projects.
  • Language independence: Many libraries are language-agnostic, enhancing cross-platform development.

# Frameworks

  • Purpose: Provide a structured foundation for building applications.
  • Control: Developers adapt their code to fit the framework's structure.
  • Structure: Impose a specific project structure and workflow.
  • Reusability: Reusable components and patterns within the framework, but often tied to the framework's ecosystem.
  • Examples: Angular, React, Django.

# Reusability in Frameworks

  • Component-based reusability: Frameworks often encourage component-based architecture, promoting code reuse within the application.
  • Pattern-based reusability: Frameworks often follow design patterns, providing reusable solutions to common problems.
  • Ecosystem reusability: Frameworks often have rich ecosystems of third-party libraries and components, expanding reusability options.
Feature Libraries Frameworks
Scope of Reuse Wider, often across projects and languages Primarily within the framework's ecosystem
Level of Control Higher, developers choose when and how to use Lower, developers adapt to the framework's structure
Dependency Loose coupling Tighter coupling to the framework

# Reusability within Layers

A typical application is often structured into layers:

  • Presentation Layer: Handles user interface and interaction.
  • Business Logic Layer: Encapsulates core business rules and processes.
  • Data Access Layer: Manages interactions with data storage.

# Presentation Layer:

  • UI Components: Creating reusable UI components like buttons, input fields, and navigation elements can significantly speed up development.
  • Templates and Layouts: Reusable templates and layouts can streamline the creation of different pages and screens.
  • Style Libraries: Defining a consistent style guide can ensure visual consistency and promote reusability.

# Business Logic Layer:

  • Domain Models: Well-defined domain models can be reused across different use cases.
  • Business Services: Creating reusable business services that encapsulate specific functionalities can improve code modularity.
  • Utility Functions: Developing general-purpose utility functions for tasks like data validation, formatting, or calculations can enhance reusability.

# Data Access Layer:

  • Data Access Objects (DAOs): Implementing DAOs to abstract database interactions can facilitate swapping data sources.
  • ORM Frameworks: Using ORMs can often provide built-in mechanisms for data mapping and query generation.
  • Caching Strategies: Implementing caching layers can improve performance and reduce database load.

← Code structure →