[ABC Wallet] アーキテクチャ + モジュール化

---

📌 概要

• プロジェクト期間: 2024年1月 ～ 2025年4月（最終更新）

• 役割: iOSアプリ開発、Swapサーバー開発

• チーム構成: プランナー1名、デザイナー1名、iOS1名、Android1名、Server2名、QA3名

• リリース日: 2024年5月

• App Storeリンク: https://apps.apple.com/kr/app/id1642837445

---

🧩 プロジェクト紹介

'ABCWallet'は既存のReact Nativeベースのアプリをネイティブに移行し、安定性とパフォーマンスを大幅に改善したプロジェクトです。iOSとAndroidの開発者間で協業し、クリーンアーキテクチャに基づくコードベースを構築して拡張性とテストのしやすさを確保しました。

Swift Package Managerを活用してモジュール化を進め、保守効率を高めました。マルチブロックチェーン対応、Swap、ステーキング、NFT転送などの主要機能を安定的に運用し、さまざまなユーザー環境に対応できる基盤を整えました。

---

🔧 技術スタックとアーキテクチャ

• アーキテクチャ: Clean Architecture + MVVM

• モジュール管理: Swift Package Manager

• 技術: SwiftUI、UIKit、Swift Concurrency、Combine、StoreKit など

• ローカルデータ:

  • CoreData – キャッシュデータ

  • UserDefaults – アプリ設定

  • Keychain – MPCベースの共有キー

---

🚀 主な機能と実装事例

1. Clean Architecture / SPMによるモジュール化

• Domain → UseCases、Repositoryプロトコル、Entities

• Data → Repository実装、Data Source（Network / Local Storage）、Mapper ..

• ABCUI → アプリで共通して使用するViewコンポーネントの集合

• Common → ユーティリティ機能の集合

[SPMによるモジュール化]

2. SNSLoginUseCase 実装サンプル

このコードは クリーンアーキテクチャのUseCase層を実装した例です。

ビジネスロジックである SNSログイン処理を execute メソッドに定義し、外部依存はすべて抽象化されたインターフェース（Repository、Service、UseCase）を通じて注入されます。

• 責任の分離: ログイン要求、ユーザー情報更新、トークン保存、デバイスデータ初期化などの様々な責任を各協力オブジェクトに委譲

• 依存性注入: RepositoryとServiceをコンストラクタ注入で受け取り、テストの容易性と柔軟性を確保

• 非同期処理: async/awaitを通じて非同期フローの可読性を改善

この構造は他のユースケース実装にも同様に適用され、 役割別に分離されたモジュール構造と柔軟な拡張性を目標に構成しました。

public protocol SNSLoginUseCase {
    func execute(with type: ABCUser.LoginType) async throws -> String
}

public final class DefaultSNSLoginUseCase: SNSLoginUseCase {
    
    let authTokenRepository: AuthTokenRepository
    let abcUserRepository: ABCUserRepository
    let clearDeviceStorageUseCase: ClearDeviceStorageUseCase
    private let loginServiceResolver: (ABCUser.LoginType) -> SNSLoginService
    
    public init(
        authTokenRepository: AuthTokenRepository,
        abcUserRepository: ABCUserRepository,
        loginServiceResolver: @escaping (ABCUser.LoginType) -> SNSLoginService,
        clearDeviceStorageUseCase: ClearDeviceStorageUseCase
    ) {
        ...
    }
    
    public func execute(with type: ABCUser.LoginType) async throws -> String {
        guard type != .email else {
            throw SNSLoginUseCaseError.invalidSNSType
        }
        
        let service: SNSLoginService = loginServiceResolver(type)
        
        let idToken = try await service.requestLogin()
        
        let abcToken = try await abcUserRepository.signIn(with: type, idToken: idToken)
        let email = try await abcUserRepository.getEmail(accessToken: abcToken.accessToken)
        
        let cachedUser = abcUserRepository.fetchABCUser()
        
        let abcUser = try await abcUserRepository.updateABCUser(
            accessToken: abcToken.accessToken,
            email: email,
            loginType: type
        )
        if cachedUser?.email != abcUser.email {
            clearDeviceStorageUseCase.execute()
        }
        authTokenRepository.update(abcToken)
        return email
    }
}

3. ABC Wallet アプリ内 Swap API 開発

• Python、Redis、AWS（ECS）

• 1inch、Swapscanner のAPIを活用

• ネットワーク（Ethereum、Polygon、Binance、KAIなど）に応じて異なるProviderを選択して呼び出す

3-1. 実装したAPI一覧

1. 対応するブロックチェーン一覧の取得

2. 利用可能なトークン一覧の取得

3. 交換受取見積価格の取得

4. ERC20 承認量の取得

5. ERC20 承認Txデータの取得

6. 交換時に使用するTxデータの取得

アプリ内Swapサービス

4. 社内サービス WaaS（Wallet as a Service）SDK 設計および実装

• SwiftでiOS向けに設計・実装し、これをもとに同僚がAndroid / Web向けモジュールを実装しました。

• Readme WaaS SDK

---

🎯 成果

• Clean Architecture を基盤としてiOSアプリの構造を再定義し、機能拡張時のコード修正範囲を最小化して保守効率を最大化しました

• Swift Package Manager（SPM） を活用したモジュール化によりコアドメイン（Domain、Data）を再利用可能に設計し、 Klipプロジェクトへの移植が最小の修正で可能となりました

• 非同期ロジック（Access Token管理、WalletConnect、資産送信） などの安定性を確保し、 並行制御および抽象化レイヤーを改善してクライアントの障害率を低減しました

• プロジェクト内 Swapサーバーおよび WaaS SDK の設計を主導し、ウォレット関連APIの抽象化およびサービス間の機能一貫性を確保しました

---

🧠 振り返り

1. Access Token 管理ロジックの並行制御が最も難しかった点

• Access Tokenを要求する際、まず有効性を検査し、期限切れの場合はRefreshトークンを通じて再発行する必要があります。この過程は 同時リクエストが重なると重複更新を防ぐために単一スレッドで順次処理される必要がありました。

• 初期にはGCDの Serial Queue を 活用して、トークン更新ロジックが一つのスレッドでのみ安全に実行されるように処理しました。

• その後、 Alamofireの RequestInterceptor 機能を使えばこのフローをより簡潔かつ安定して実装できることに気づき、将来的なリファクタリングでその方式に改善する計画です。

2. クリーンアーキテクチャ適用による構造的安定性と拡張性の確保

• プロジェクト全体にClean Architectureを適用し、 ドメイン、データ、プレゼンテーションレイヤーを明確に分離し、テストと保守が容易な構造を作りました。

• プロジェクト初期にはモジュール化を考慮できなかったことが悔やまれましたが、その後構造を改善してKlipアプリへData / Domainモジュールを成功裏に移植し、 再利用性と拡張性の面で大きな満足を得ました。