What is IDesign way in architecture?

As experienced engineers, we've all experienced the phenomenon of a once manageable project spiraling into complexity. This article explores the IDesign method, a structured approach to software architecture that aims to create robust, adaptable systems.

The need for robust architecture

Software projects often start small and cute, but can quickly become unmanageable as requirements change. This transformation is usually due to the lack of an appropriate architecture, or an architecture that is not designed for future change.

The IDesign Method: An Overview

The IDesign method, developed by Juval Löwy, provides a systematic approach to creating a software architecture that will stand the test of time. Let's explore its key principles.

Avoid functional decomposition
The first principle of IDesign is to avoid functional decomposition - the practice of translating requirements directly into services. For example, if you're building an e-commerce platform, don't create separate services for "user management", "product catalogue" and "order processing" just because those are your main requirements. Instead, IDesign advocates a more thoughtful approach based on volatility.

Volatility based decomposition
IDesign focuses on identifying areas of volatility - aspects of the system that are likely to change over time. For example, in our e-commerce example, payment methods might be an area of volatility, as you may need to add new payment options in the future.

The three-step process:

  1. Identify 3-5 core use cases
    What your system does at its most basic level. For our e-commerce platform, these might be:
    1. Browse and search for products
    2. Manage shopping cart
    3. Completing a purchase
  2. Identify areas of volatility
    Identify aspects of the system that are likely to change. In our e-commerce example:
    1. Payment methods
    2. Shipping options
    3. Product recommendation algorithms
  3. Define services
    IDesign defines five types of services:
    1. Client: Handles user interaction (e.g. web interface)
    2. Manager: Orchestrates business use cases
    3. Engine: Executes specific business logic
    4. Resource Access: Handles data storage and retrieval
    5. Utility: Provides cross-cutting functionality

For our e-commerce platform example we might have:

  • A ShoppingManager - to orchestrate the shopping process
  • A PaymentEngine - to handle different payment methods
  • A ProductCatalogAccess - to manage product data

Implementation tips

In my opinion, I strongly suggest these things:

  • Keep managers declarative and focus on orchestrating use cases.
  • Don't use engines unless there is uncertainty about how a particular activity should be performed.
  • Write integration tests that describe business use cases with minimal mocking.
  • Ensure that utilities are truly domain agnostic.

Summary

The IDesign method provides a structured approach to creating robust, adaptable software architectures. By focusing on core use cases and areas of volatility, it helps create systems that can evolve with changing requirements.

Happy IDesigning!