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

ドメインを分析し、設計に落とし込むには？ 2つのSaaSをフルスクラッチで開発した経験から学んだこと 株式会社メディカルフォース 取締役CTO 畠中 翔⼀

⾃⼰紹介 株式会社メディカルフォース 取締役CTO 畠中 翔⼀ 1997年⽣まれ、⼤阪府出⾝学⽣時代からインフラの 構築やWebアプリの⽴ち上げを多数こなす。 2020年11⽉に株式会社メディカルフォースを設⽴。 現在のmedicalforceをフルスクラッチで開発。 開発の傍ら、深層⽣成学習を⽤いた研究が国際学会に採択 されるなど、機械学習(AI)や最先端の技術にも精通。

本⽇の講演について

本⽇の講演について どんな⼈向けか アーキテクチャ選定に迷いがある 開発組織の仕様変更のスピードをあげたい DDDの価値が分からない

本⽇の講演について 話す内容 仕様変更のボトルネック オニオンアーキテクチャの旨み 採⽤する上で抑えておきたいこと

私たちについて バーティカルSaaSのコングロマリットを⽬指すテックカンパニー ⾃由診療向けオールインワンSaaS 警備業向けオールインワンSaaS

ビジョン Vision これからの産業の成⻑プロセスを合理化する このビジョンを達成するために、スピード感はとても重要

スタートアップはスピード感は開発組織のスピード感から

PMF ミッションクリティカルなプロダクト これを超えてくれるのがPMF。ミッションクリティカルなプロダクトは特に⼤変。 業務の⼤変さ 元システムが20年かけて できなく 開発しているシステム なること 元システム 普通にやったら5年はかかる できるように なること 新システム ⼤幅に短縮して実現するには

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

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

仕様変更/カイゼンのスピード どこを変更するべきかが明確 変更した時の影響範囲が明確 ▶ カイゼンにも同じことが⾔える

仕様変更/カイゼンのスピード どこを変更するべきかが明確 各関数やクラスの責務が明確 ⾒通しの良いコード 変更した時の影響範囲が明確 依存の関係が明確 依存の向きや向き先が限定的

スピード感とは 結局、、⾼凝集‧低結合が⼤事！！！ 仕様変更もカイゼンも⾼凝集‧低結合であれば安全に少ない変更量で⾏える

アーキテクチャ

これまでの三層アーキテクチャ プレゼンテーション層 ロジック層 データアクセス層 レイヤーの責務⾃体は明確で 依存の向きや向き先も明確という意味では⾼凝集‧低結合に⾒える ⼤体ぐちゃぐちゃになるのロジック層じゃないですか？

ロジック A ロジック B ロジックAにも置くと 凝集度が下がる ロジックBから持ってくると 結合度が上がる ロジック Bの一部

在庫アラートの例 在庫仕入れロジック 在庫減算 ロジック 在庫使用ロジック ⾊々なところで本来 関係のない通知周りの ロジックが出現 ▶ こちらを渋々採⽤ 在庫のアラート通知 ロジック アラートを出したくない処理 の時に、意図せずアラートが 出てしまう

ロジック A ロジック B ロジックAにも置くと 凝集度が下がる ロジック Bの一部 ロジックBから持ってくると 結合度が上がる => 意図しない仕様が⽣まれや すく、バグが起きやすい

名寄せの例 患者ロジック カルテロジック 名寄せロジックが巨⼤なため、 ⼤したことのない処理でも 名寄せのせいでコードが膨らむ ▶ 可読性も品質も落ちる 名寄せロジック

ロジック A ロジックAにも置くと 凝集度が下がる => 変更漏れや毎度複 雑な処理を書くのでバ グが起きやすい ロジック B ロジック Bの一部 ロジックBから持ってくると 結合度が上がる => 意図しない仕様が⽣まれや すく、バグが起きやすい

ユースケース B ユースケース A ロジック A ロジック B ロジック C ロジック D

仕様変更/カイゼンのスピード どこを変更するべきかが明確 各関数やクラスの責務が明確 ⾒通しの良いコード 変更した時の影響範囲が明確 依存の関係が明確 依存の向きや向き先が限定的

⼆種類のロジック アプリケーションロジック 頻繁に変更される アプリケーションごとに異なる ドメインロジック 知識として蓄積される どんなアプリケーションでも同じ

これまでの三層アーキテクチャ プレゼンテーション層 アプリケーションロ ジック ドメイン ロジック データアクセス層 ビジネスロジックとドメインロジックをレイヤー分けすることで解決する問題が多い！！

在庫アラートの例 在庫使用ビジネスロジッ ク 在庫使用ドメインロジック 在庫仕入れビジネスロ ジック アラート通知ドメイン ロジック 在庫仕入れドメインロ ジック アラート通知をするということは在庫使⽤のビジネスロジック だが、それぞれの処理は書かずに呼び出すだけ

名寄せの例 患者ドメインロジック 会計ビジネスロジック カルテビジネスロジック (名寄せ) 患者ドメインロジック 会計ドメインロジック カルテドメインロジック (名寄せ) アラート通知をするということは在庫使⽤のビジネスロジック だが、それぞれの処理は書かずに呼び出すだけ

名寄せの例 カルテビジネスロジック 患者ビジネスロジック カルテドメインロジック 患者ドメインロジック

カイゼンについて

カイゼン ▶ 関数のリファクタリングは⾼凝集‧低結合になると⾃ずとやりやすくなる フレームワークやORMの変更 DBの変更

本当にそんなカイゼンすることあるの？ フレームワークやORMなど変更することは滅多にないと思っていた。 が、実際(Node.jsでは)ORMのデファクトスタンダードが 変わってきていたり、良さげなフレームワークが登場したりなど ここ三年で変化が⼤きい。またDBについても実際に ⼀部DynamoDBからPostgresに置き換えたり、逆もある。

データアクセス層 プレゼンテーション層 アプリケーションロ ジック ドメイン ロジック データアクセス層 データアクセス層は、エンティティの永続化と復元以外の責務を負ってはいけない！

User Interface ⾼凝集‧低結合をとりあえず Application Service 守っておけばなんとかなりそう。 Domain Service だが実際にこれらをルール化して Domain Model st ru fra Web Service File In オニオンアーキテクチャの採⽤ ct ts s Te Application Core ur e みんなに守ってもらうのは難しい DB

結果

良かったこと ▶ 当然仕様変更は圧倒的にしやすくなった！！ テストが書きやすくなった！ コードの再利⽤性が⾼まって新規実装も速くなった！ DBの変更 バグが出にくくなった！

結論 今⽇伝えたかったこと とにかく⾼凝集‧低結合 ロジックの責任分けがとにかく重要 インフラレイヤーを作ることも重要

アンケートご回答お願いします ごせいちょうありがとうございました！