ドメインを分析し、設計に落とし込むには？ 2つのSaaSをフルスクラッチで開発した経験から学んだこと

どんな人向けか

• アーキテクチャ選定に迷いがある

• 開発組織の仕様変更のスピードを上げたい

• DDDの価値がわからない

PMF ミッションクリティカルなプロダクト

できなくなることを減らして、できるようになることを増やしていかないといけない

スピード感

これからのスピード感

機能は時間が経つにつれて、コモディティ化していく。
真の意味で競合優位性になるのは顧客に向き合って、独自のロードマップを作り、どこよりも早く実装していくスピード感になると思っている

スピード感とは

❌ 新しい機能を早く作っていくこと
⭕️ 仕様変更が素早くできること
⭕️ カイゼンのスピードを速くすること

仕様変更/カイゼンのスピード

• どこを変更するべきかが明確

  • 各関数やクラスの責務が明確

  • 見通しの良いコード
    

• 変更した時の影響範囲が明確

  • 依存関係が明確

  • 依存の向きや向き先が限定的

→高凝集・低結合が大事

これまでの三層アーキテクチャ

ロジック層を綺麗にしていくのが大事だと思う

2種類のロジック

• アプリケーションロジック（うちではこうだけど、他社は違う）

  • 頻繁に変更される

  • アプリケーションごとに異なる

• ドメインロジック（他社でも一緒）

  • 知識として蓄積される

  • どんなアプリケーションでも同じ

カイゼン

関数のリファクタリングは高凝集・低結合になると自ずとやりやすくなる

• フレームワークやORMの変更

• DBの変更

→ここ3年でデファクトスタンダードが変わったり変化が大きくなってきた

データアクセス層

エンティティの永続化と復元以外の責務を負ってはいけない
→オニオンアーキテクチャを採用採用した

良かったこと

仕様変更が圧倒的にしやすくなった

• テストが書きやすくなった

• コードの再利用性が高まって新規実装も速くなった

• バグが出にくくなった