C#上級

上級 C#で学ぶクリーンアーキテクチャ｜アンチパターン編

 

導入

クリーンアーキテクチャは、ソフトウェア開発における保守性や拡張性を高めるための設計原則を提供しますが、実際の開発現場では意図しないアンチパターンに陥ることが少なくありません。本稿では、特にクリーンアーキテクチャの実践において遭遇しやすい具体的なシチュエーションを取り上げ、その中での失敗例と改善策について詳しく解説します。

教科書レベルの解説（クリーンアーキテクチャ）

重要な概念の整理

クリーンアーキテクチャは、依存関係の逆転を重視し、ビジネスロジックを外部の技術的詳細から独立させることを目指します。これにより、テストの容易さや、将来的な技術変更に対する柔軟性が得られます。具体的には、エンティティ、ユースケース、インターフェースアダプター、フレームワークの4つのレイヤーから構成されます。

コード例（C#）


public interface IOrderRepository
{
    void Save(Order order);
}

public class OrderService
{
    private readonly IOrderRepository _orderRepository;

    public OrderService(IOrderRepository orderRepository)
    {
        _orderRepository = orderRepository;
    }

    public void ProcessOrder(Order order)
    {
        // ビジネスロジック
        _orderRepository.Save(order);
    }
}

コードの行ごとの解説

  1. インターフェース IOrderRepository を定義し、データアクセスの抽象化を行います。

  2. OrderService クラスは、IOrderRepository に依存し、依存性注入を通じてリポジトリを受け取ります。

  3. ProcessOrder メソッド内で、ビジネスロジックを実装し、リポジトリを介してデータを保存します。

アンチパターン編

クリーンアーキテクチャを実装する際、よく見られるアンチパターンの一つに「リポジトリの実装がビジネスロジックを持ってしまう」という問題があります。この場合、リポジトリは単なるデータアクセスの役割を超えて、ビジネスルールをも含むようになります。これにより、リポジトリが変更されるたびにビジネスロジックも影響を受け、コードの保守性が低下します。

以下に、問題のあるコード例を示します。


public class OrderRepository : IOrderRepository
{
    public void Save(Order order)
    {
        // ビジネスロジックをここに含めてしまう
        if (order.TotalAmount > 1000)
        {
            // 特別な処理
        }
        // データベースに保存
    }
}

このコードでは、リポジトリがビジネスロジックを持ち込んでしまっているため、リポジトリの変更がビジネスロジックに影響を与えます。この問題を解決するためには、ビジネスロジックをサービス層に移動させ、リポジトリはデータアクセスのみに専念させることが重要です。

まとめ

  • クリーンアーキテクチャでは、各レイヤーの責任を明確に分けることが重要です。
  • ビジネスロジックはサービス層に保持し、リポジトリはデータアクセスに特化させることが望ましいです。
  • アンチパターンを避けるためには、コードの責任範囲を常に意識することが必要です。
RELATED POST