株式会社リンクス / バックエンドエンジニア
オニオンアーキテクチャでのドライブレコーダー管理システム開発
## プロジェクト概要 損害保険会社のドライブレコーダーの在庫管理システムを開発しておりました。 アプリJavaのSpring Frameworkを使っており、 画面→contoroller→service→entityという依存関係をとっているオニオンアーキテクチャでの開発でした。 しかし、詳細設計が詰めきれておらず、単体テストで炎上していました。 ### 担当した役割 単体テストで生じた障害の修正対応から入り、結合テストでのテスト設計や打鍵まで行いました。 詳細は以下の通りです。 ・Javaのcontroller, service, entityクラスの障害対応、またそれにともなう横展開の修正 →特に在庫引当の周りの制御 ※簿記の知識が活きました。 ・入力チェックと業務チェックのリファクタリング ・障害対応にともなう詳細設計書の修正 ・設計書及び実装の差分調査 ・ステージング環境でのテスト設計書の作成及び打鍵 ・Redmineによるチケットの作成、管理 ・SVN、Gitによるバージョン管理 ### 使用技術や開発環境等 フロントエンド:Thymeleaf バックエンド:Java(Spring) DB:MySQL(A5M2) OS:windows インフラ:AWS ### 取り組んだ課題 ・在庫引当周りの制御に関する機能改修 PJは、ドライブレコーダーを車に搭載することで契約を結ぶ形式の保険でした。 その際に、ドライブレコーダーの在庫管理とそれに関連する仕訳の制御で問題が頻発していました。 返品・交換・破損による取り替え・取り消しなどで、仕分けがそれぞれどうなるかに関する知識を持った方がPJに少なく、 外部設計から内部設計に落とし込む際に、曖昧になってしまっていました。 その点に関して、私は簿記2級を持っていて、その経験から機能改修を行うことができました。 ・入力チェックと業務チェックのリファクタリング 通常オニオンアーキテクチャでは、各階層で責務範囲が明確に割り当てられていますが、 炎上していたため、作り込みが甘くなっていました。 私が担当した入力チェックと業務チェックでは、contoroller/service/entityで処理が混在していました。 そこで、入力チェックと業務チェックを分離し、エラー処理を統一しました。 入力チェックは、entityにspringの@Pattern処理を書いて、正規表現に統一しました。 業務チェックは、serviceからrepoisitoryを経由してDBにアクセスするので、serviceでまとめて処理を行いました。