Haruka

Engineer

プロジェクトの詳細

大手ECサイトサービスのフルリニューアルに合わせて、会員基盤でAPIの実装と他社サービスとの連携を担当。アプリログイン連携やポイント基盤の繋ぎ込み（既存ユーザーのポイント付与、減算、合算）、決済処理の連携など外部の連携先のAPI開発を担当し会員処理のビジネスロジックの実装と設計。クリーンアーキテクチャを使って会員基盤のロジックを疎結合にし、インフラ通信部分の抽象化。

使用技術

  • API: Go, DIツールとしてwireを使用
  • インフラ：AWS、Docker
  • チケット管理：Backlog
  • API仕様書：Swagger

参加期間

  • 2020年12月〜2021年8月

開発規模

  • 約100人 担当していた会員周りは5人、内2人がエンジニア

主な取り組み

  • 会員基盤でAPIの実装と他社サービスとの連携
  • API開発 -インフラ通信部分の抽象化

【クリーンアーキテクチャ】

クリーンアーキテクチャでの設計は社内パッケージの雛形を修正し、プロダクトに使える形で修正しました。DBの接続部分のみ抽象化されており、APIとの連携を可能にするため、新しくAPIとの通信部分も抽象化できるように実装しました。 外部連携先のポイント基盤、決済、アプリログインのエンドポイントの作成および会員基盤内でも使用できるように組み込み、旧サービスで必要な物不要なものを整理し、会員基盤で持つ必要がある情報の整理と実装を担当しました。 外部の連携先が多かったため、モックを準備したり実装前にAPIの仕様書を用意するなど、他チームの開発に滞りがないように努めました。

【感じたこと】

参加当時はクリーンアーキテクチャに対しての知識が浅く、実力的には理解できるほどではありませんでした。 雛形を参考にしながら本やネットを参考に実装していく中で抽象化による疎結合化のメリット、デメリットを理解できるようになったと考えています。

フルリプレイスに合わせて多数の企業が参加しての開発で情報が古く、使われていない機能や仕様が多数ある中で新しい仕様ができたりと、各所の連携も含めて管理する必要があり正しい情報の整理に難航しました。 また、フロントエンドでの実装で必要なデータ設計や、連携先に合わせて会員基盤のロジックなど、APIの設計に苦労することもありました。 そのため、仕様を話し合いながら処理に必要な部分を調べ、ロジック、データ設計などをドキュメントとして新しく書き落とし整理しながら決めていくことで解決していきました。