پیاده‌سازی Clean Architecture در پروژه‌های Java با Spring Boot

معماری چند ضلعی و Clean Architecture یکی از روش‌های طراحی نرم‌افزار است که هدف آن ساخت سیستم‌هایی با قابلیت نگهداری، تست و توسعه آسان می‌باشد. این معماری توسط “روبرت مارتین” (Robert C. Martin) معرفی شده و به دنبال جداسازی وابستگی‌ها و مسئولیت‌ها در لایه‌های مختلف نرم‌افزار است. در این مقاله، نحوه پیاده‌سازی معماری چند ضلعی و  Clean Architecture  در یک پروژه جاوا با استفاده از Spring Boot به صورت قدم به قدم شرح داده می‌شود.

دلایل استفاده ازمعماری چند ضلعی و  Clean Architecture

• استقلال از چارچوب‌ها: Clean Architecture تضمین می‌کند که وابستگی به چارچوب‌های خاص (مانند Spring، Hibernate و غیره) به حداقل برسد. این ویژگی باعث می‌شود که شما بتوانید در صورت نیاز به راحتی چارچوب مورد استفاده را تغییر دهید، بدون اینکه تأثیر زیادی بر منطق اصلی برنامه بگذارد؛ برای مثال، اگر در آینده بخواهید از Spring Boot  به Micronaut یا Quarkus تغییر دهید، این فرآیند با استفاده از Clean Architecture ساده‌تر خواهد بود.
• استقلال از دیتابیس: یکی از اصول اساسی Clean Architecture جدا کردن منطق تجاری (Business Logic) از دیتابیس است. این بدین معناست که تغییرات در دیتابیس (مانند تغییر ساختار جداول یا تغییر نوع دیتابیس از MySQL به PostgreSQL) هیچ تأثیری بر منطق اصلی برنامه نخواهد داشت. لایه‌های Repository در معماری Clean مسئول مدیریت ارتباط با دیتابیس هستند و این لایه‌ها به صورت کاملاً جداگانه پیاده‌سازی می‌شوند.
• تست‌پذیری بالا: معماری Clean به دلیل تقسیم پروژه به لایه‌های مشخص (مانندUse Case، Entities و Adapters) امکان تست جداگانه هر بخش را فراهم می‌کند. برای مثال، می‌توانید منطق استفاده (Use Case) را به صورت مستقل از دیتابیس یا سایر وابستگی‌ها تست کنید. این قابلیت باعث کاهش هزینه و زمان توسعه می‌شود.
• مدیریت بهتر وابستگی‌ها: اصل Dependency Inversion که در قلب Clean Architecture قرار دارد، تضمین می‌کند که وابستگی‌ها همیشه از لایه‌های بیرونی (مانند UI یا دیتابیس) به سمت لایه‌های داخلی (مانند منطق تجاری) حرکت کنند. این جهت‌گیری وابستگی باعث افزایش خوانایی، مقیاس‌پذیری و قابلیت نگهداری پروژه می‌شود؛ همچنین این رویکرد به شما اجازه می‌دهد تا با حفظ انعطاف‌پذیری، وابستگی‌ها را به راحتی مدیریت کنید.

ساختار کلی پروژه

برای پیاده‌سازیClean Architecture، پروژه به چهار لایه اصلی تقسیم می‌شود:

1. Entities یا (Core): این لایه شامل مدل‌ها و قوانین اصلی سیستم است و قلب معماری شما محسوب می‌شود. این قوانین مستقل از تکنولوژی‌ها، چارچوب‌ها و دیتابیس‌ها هستند؛ به عنوان مثال، اگر در پروژه‌ای یک سیستم مدیریت کاربران دارید، Entity مربوط به “User” می‌تواند شامل خصوصیات (مانند username، email و password) و رفتارهای مرتبط (مانند تغییر رمز عبور) باشد. این لایه کاملاًً مستقل از سایر لایه‌ها است و می‌تواند بدون تغییر باقی بماند، حتی اگر سایر لایه‌ها تغییر کنند.

» ویژگی‌های کلیدی:

• استقلال از چارچوب‌ها و تکنولوژی‌ها.
• تمرکز بر مدل‌ها و منطق اصلی سیستم.
• قابل استفاده مجدد در پروژه‌های دیگر.

1. Use Cases  یا (Application Services):  این لایه منطق اصلی برنامه و وظایف خاص سیستم را تعریف می‌کند. Use Cases به طور مستقیم با Entities کار می‌کنند و وظیفه دارند درخواست‌های دریافتی را پردازش کرده و خروجی مورد نظر را تولید کنند؛ به عنوان مثال، در سیستم مدیریت کاربران، یک Use Case می‌تواند مسئولیت ورود کاربر را داشته باشد. این Use Case ممکن است بررسی کند که آیا کاربر با اطلاعات معتبر وارد شده است یا خیر و سپس توکن احراز هویت تولید کند.

» ویژگی‌های کلیدی:

• تمرکز بر روی نیازمندی‌های تجاری سیستم.
• مستقل از لایه‌های خارجی مانند دیتابیس یا APIها.
• قابل تست به صورت مستقل.

1. Interface Adapters:  این لایه به عنوان واسطه‌ای بین Use Cases و لایه Frameworks & Drivers عمل می‌کند. وظیفه این لایه این است که داده‌ها را از فرمتی که برای Use Cases مناسب است به فرمتی که برای چارچوب‌های خارجی (مانند UI یا دیتابیس) قابل استفاده است، تبدیل کند؛ برای مثال، این لایه ممکن است داده‌های دریافتی از یک API  را به مدل‌های داخلی سیستم تبدیل کند.

» ویژگی‌های کلیدی:

• تبدیل داده‌ها بین لایه‌های مختلف.
• ارائه رابط‌های استاندارد برای ارتباط با Use Cases.
• مدیریت وابستگی‌ها به لایه‌های خارجی.

1. Frameworks & Drivers:  این لایه شامل تکنولوژی‌ها، دیتابیس‌ها، APIهای خارجی  و هر چارچوبی است که در پروژه استفاده می‌شود. این لایه در معماری Clean به صورت کاملاً جدا از لایه‌های اصلی عمل می‌کند و وابستگی‌ها به لایه‌های داخلی را مدیریت می‌کند؛ به عنوان مثال، اگر از Spring Boot استفاده می‌کنید، این لایه شامل کنترلرها، کانفیگ‌های Spring و سایر اجزا خواهد بود.

» ویژگی‌های کلیدی:

• وابسته به تکنولوژی‌ها و چارچوب‌های خاص.
• مدیریت ارتباط با سیستم‌های خارجی.
• قابل جایگزینی بدون تأثیر بر سایر لایه‌ها.

ساختار پیشنهادی پوشه‌ها برای پروژه Spring Boot به شکل زیر است:

src/main/java
|- com.example.cleanarchitecture
   |- core
      |- entity
      |- usecase
   |- adapters
      |- in
      |- out
   |- frameworks
      |- config
      |- persistence
      |- web

قدم اول: طراحی Entities لایه (Core)

این لایه شامل مدل‌ها و قوانین اساسی است و به صورت کاملاً مستقل از سایر لایه‌ها طراحی می‌شود. تمرکز این لایه بر روی قوانین کلی سیستم است.

مثال:

package com.example.cleanarchitecture.core.entity;
import java.util.Objects;
public class Product {
    private final Long id;
    private final String name;
    private final double price;
    public Product(Long id, String name, double price) {
        this.id = id;
        this.name = name;
        this.price = price;
    }
    public Long getId() {
        return id;
    }
    public String getName() {
        return name;
    }
    public double getPrice() {
        return price;
    }
    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Product product = (Product) o;
        return Double.compare(product.price, price) == 0 &&
               Objects.equals(id, product.id) &&
               Objects.equals(name, product.name);
    }
    @Override
    public int hashCode() {
        return Objects.hash(id, name, price);
    }
}

هدف اصلی این لایه، حفظ استقلال قوانین اصلی سیستم از هرگونه وابستگی به دیتابیس یا چارچوب‌ها است.

قدم دوم: طراحی Use Cases لایه (Application)

در این لایه، منطق برنامه و وظایف خاص سیستم پیاده‌سازی می‌شود؛ تمام اتفاقات اصلی در اینجا رخ می‌دهد.

مثال:

package com.example.cleanarchitecture.core.usecase;
import com.example.cleanarchitecture.core.entity.Product;
import com.example.cleanarchitecture.core.port.out.ProductRepository;
import java.util.List;
public class GetAllProductsUseCase {
    private final ProductRepository productRepository;
    public GetAllProductsUseCase(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }
    public List<Product> execute() {
        return productRepository.findAll();
    }
}

در این لایه فقط از واسط‌هایی که توسط لایه‌های پایین‌تر پیاده‌سازی می‌شوند، استفاده می‌شود؛ بنابراین این لایه به هیچ تکنولوژی خاصی وابسته نیست.

قدم سوم: طراحی Interface Adapters

این لایه وظیفه واسطه‌گری بین لایه‌های داخلی و خارجی را بر عهده دارد؛ به عنوان مثال، داده‌ها از ورودی دریافت شده و به فرمت مناسب تبدیل می‌شوند.

مثال:

package com.example.cleanarchitecture.adapters.in;
import com.example.cleanarchitecture.core.entity.Product;
import com.example.cleanarchitecture.core.usecase.GetAllProductsUseCase;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
import java.util.List;
@RestController
@RequestMapping("/products")
public class ProductController {
    private final GetAllProductsUseCase getAllProductsUseCase;
    public ProductController(GetAllProductsUseCase getAllProductsUseCase) {
        this.getAllProductsUseCase = getAllProductsUseCase;
    }
    @GetMapping
    public List<Product> getAllProducts() {
        return getAllProductsUseCase.execute();
    }
}

این لایه مستقیماً با ورودی‌ها مانند درخواست (HTTP) و خروجی‌ها مانند (JSON) در ارتباط است.

قدم چهارم: طراحی Frameworks & Drivers

این لایه شامل پیاده‌سازی وابستگی‌ها، دیتابیس و ارتباطات خارجی است.

مثال:

package com.example.cleanarchitecture.frameworks.persistence;
import com.example.cleanarchitecture.core.entity.Product;
import com.example.cleanarchitecture.core.port.out.ProductRepository;
import org.springframework.stereotype.Component;
import java.util.Arrays;
import java.util.List;
@Component
public class ProductRepositoryImpl implements ProductRepository {
    @Override
    public List<Product> findAll() {
        // Mock data for simplicity
        return Arrays.asList(
            new Product(1L, "Product A", 100.0),
            new Product(2L, "Product B", 200.0)
        );
    }
}

این لایه وابسته به تکنولوژی‌هایی مانند دیتابیس و سرویس‌های خارجی است.

ارتباط بین لایه‌ها

یکی از اصول اساسی در معماریClean، جریان وابستگی‌ها از لایه‌های بیرونی به سمت لایه‌های داخلی است. این ساختار باعث می‌شود که هر لایه تنها به لایه‌هایی که نزدیک‌تر به هسته سیستم (Core) هستند وابسته باشد. در ادامه جزئیات این ارتباطات را بررسی می‌کنیم:

1. لایهCore (Entities): این لایه به هیچ لایه دیگری وابسته نیست و کاملاً مستقل است. تمام قوانین اصلی سیستم (مانند قوانین تجاری، محاسبات ریاضی و منطق عمومی) در اینجا قرار می‌گیرند. استقلال این لایه تضمین می‌کند که تغییرات در سایر لایه‌ها هیچ تأثیری بر قوانین اصلی سیستم نخواهد داشت. این استقلال به کمک اصل Dependency Inversion  حفظ می‌شود.

» ویژگی کلیدی:

• استقلال کامل از تمام لایه‌های دیگر.

1. لایه Use Cases: این لایه وظیفه پیاده‌سازی منطق کاربردی (Application Logic) سیستم را بر عهده دارد و تنها به لایه Core وابسته است. به عبارت دیگر، Use Cases از قوانین تعریف‌شده در Core استفاده می‌کنند تا وظایف خاصی مانند ثبت کاربر، پردازش سفارش، یا محاسبات مالی را اجرا کنند. هیچ وابستگی مستقیمی بین این لایه و لایه‌های بیرونی (مانند دیتابیس یا رابط کاربری) وجود ندارد.

» ویژگی کلیدی:

• وابستگی تنها به
• مدیریت جریان داده‌ها بین Core و سایر لایه‌ها.

1. لایه  Interface Adapters: این لایه مسئول ارتباط بین لایه‌های داخلی و خارجی سیستم است. Interface Adapters  داده‌هایی که از منابع خارجی دریافت می‌شود (مانند APIها یا دیتابیس) را به فرمتی که برای Use Cases  مناسب است، تبدیل می‌کند؛ همچنین داده‌هایی که از Use Cases دریافت می‌شوند را به فرمتی که برای نمایش در UI یا ذخیره در دیتابیس مناسب است تبدیل می‌کند.

» ویژگی کلیدی:

• وابستگی به Use Cases
• واسطه‌ای برای هماهنگی بین لایه‌های داخلی و خارجی.

1. لایه  Frameworks & Drivers: این لایه شامل چارچوب‌ها، ابزارها و تکنولوژی‌های خارجی است که برای اجرای سیستم مورد استفاده قرار می‌گیرند (مانند دیتابیس‌ها، وب‌سرورها وAPIها). این لایه به طور مستقیم به Interface Adapters  وابسته است و از آن برای ارتباط با سایر لایه‌ها استفاده می‌کند. تمام تغییرات تکنولوژی (مانند جایگزینی دیتابیس MySQL با PostgreSQL) تنها در این لایه انجام می‌شود و تأثیری بر سایر لایه‌ها ندارد.

» ویژگی کلیدی:

• وابستگی به Interface Adapters
• جداسازی تکنولوژی‌ها از منطق اصلی سیستم.

جریان وابستگی‌ها

وابستگی‌ها در Clean Architecture همیشه از بیرون به داخل حرکت می‌کنند:

• Frameworks & Drivers → Interface Adapters → Use Cases → Core

این جهت‌گیری وابستگی‌ها باعث می‌شود که منطق سیستم Core و Use Cases مستقل از تکنولوژی‌های خاص باشد و سیستم به راحتی قابل تغییر، نگهداری و تست باشد.

سخن پایانی

با پیاده‌سازی معماری چند ضلعی و Clean Architecture در پروژه‌های Java با استفاده ازSpring Boot، می‌توان به یک ساختار ماژولار و قابل گسترش دست یافت که تغییر در یک بخش، سایر بخش‌ها را تحت تأثیر قرار نمی‌دهد. این معماری با جداسازی دقیق مسئولیت‌ها و ایجاد استقلال بین لایه‌ها، باعث تسهیل در نگهداری و توسعه پروژه می‌شود. استقلال لایه‌ها از چارچوب‌ها و تکنولوژی‌های خاص، انعطاف‌پذیری بالایی را برای تغییرات آینده فراهم می‌کند و امکان جایگزینی یا ارتقا فناوری‌های مختلف مانند دیتابیس یا چارچوب‌ها را بدون اثرگذاری بر منطق اصلی سیستم به وجود می‌آورد.

هدف اصلی این معماری، ارائه سیستمی پایدار، خوانا و قابل اعتماد است که به توسعه‌دهندگان اجازه می‌دهد تغییرات و بهبودها را با کمترین پیچیدگی و بیشترین کارایی انجام دهند. چنین سیستمی با قابلیت تست‌پذیری بالا و جداسازی وظایف، پایه‌ای مناسب برای توسعه نرم‌افزارهای پیچیده و مقیاس‌پذیر خواهد بود؛ با نیک آموز همراه باشید.