ソフトウェアアーキテクチャ研修【MIXI 26新卒技術研修】

MIXI 26新卒技術研修ソフトウェアアーキテクチャ研修 ©MIXI

講師紹介登内雅人とのうちまさと 2020 年度新卒入社 Docbaseマイページ github pages:
https://github.com/tonouchi510 ©MIXI • 業務は、今は主にサッカー周りの技術支援をしてます • 静岡県浜松市からリモートワーク • 趣味はサッカー観戦、格闘技、将棋、個人開発 22

講師紹介加藤大和（かとうやまと） 25新卒 TIPSTAR事業部サーバーサイドエンジニア【学生時代】情報通信技術, Blockchain,
分散型デジタルアイデンティティの仕組みを研究 toC向け金融スタートアップでシステム開発【経歴】 2021年: 大学入学 2024年: スタートアップにて開発業務 2025年3月: 大学卒業 2025年4月: MIXI新卒入社【現在】 ⚽ 🐕 🏎 🎰 公営競技×ソーシャルのサーバーサイド, インフラを少し最近は外部SaaSの導入設計〜実装・運用まで担当 ©MIXI 3

はじめにソフトウェアアーキテクチャ研修と⾔いつつ、設計に関する概念を全般的に触れていきます。セクションごとに質問の時間を挟むので、疑問点があれば質問してください。⾊々話すと思いますが、以下の観点を持って返ってもらえると幸いです。 • • ©MIXI アーキテクチャとは何か、なぜ学ぶ必要があるか設計の考え⽅‧向き合い⽅について、何を⽬的とするべきか
4

⽬次 • • • • • • • • ©MIXI
ソフトウェアアーキテクチャとはアーキテクチャを学ぶ必要性モノリシックアーキテクチャマイクロサービスアーキテクチャモノリス vs マイクロサービス？？疎結合を実現するための⽅法論の紹介ドメイン駆動設計（DDD）の解説 DDD実践演習 5

ソフトウェアアーキテクチャとは ©MIXI

アーキテクチャとは対象の構造や、対象を構成する部品と部品同⼠の関係を⽰す設計図。システム全体のアーキテクチャ（インフラ構成）の場合 • • • • • • •
Webサーバー APIサーバー認証基盤データベース APIゲートウェイクラウドサービス etc ソフトウェアアーキテクチャではこの部分の構造の設計⽅針を定義する ©MIXI 7

ソフトウェアアーキテクチャとはソフトウェアの構成要素とそれらの関係を定義したもの。ソフトウェアの構成要素 • 各機能を実現するためのサービス‧モジュール‧クラス ◦ • • • •
例：ユーザ管理、在庫管理、商品検索、決済認証‧認可 DB操作外部サービス連携 etc ソフトウェアを組み⽴てるときには様々な要素が必要となる ©MIXI 8

ソフトウェアアーキテクチャとはソフトウェアアーキテクチャと聞いてよく出てくる⽤語 • • • • クリーンアーキテクチャレイヤードアーキテクチャオニオンアーキテクチャヘキサゴナルアーキテクチャ
• • モノリシックアーキテクチャ（モノリス）マイクロサービスアーキテクチャ ※あとでまた触れます。 ©MIXI 9

アーキテクチャを学ぶ必要性 ©MIXI

アーキテクチャを学ぶ必要性なぜソフトウェア開発において、アーキテクチャ‧設計が重要か？⾮機能要件を実現するため • 機能要件 ◦ • 「ユーザアカウントを作成できる」、「注文できる」など。ユーザやシステムが「何をできるか」に関する要件。機能そのもの。
⾮機能要件 ◦ ◦ ◦ ◦ システムが「どのように動作するか」など機能に限らない要件（品質や性能等）。実⾏時の品質：パフォーマンス‧スケーラビリティ、可⽤性‧信頼性、セキュリティデプロイ時の品質：デプロイ‧ロールバックの容易性開発時の品質：保守性（メンテナンス‧機能改修、新機能開発の容易性）ソフトウェア開発では、単にエンジニアを増やせば開発速度が上がるわけではないという現実がある ©MIXI 11

アーキテクチャを学ぶ必要性実際、Accelerateという、2000社以上の開発組織の調査結果をまとめた⽂献がある。 ‧横軸：エンジニアの数 ‧縦軸：1⽇のデプロイ数エンジニアが単に増えるだけではパフォーマンス（⽣産性）は上がらず、鈍化することさえある。 High Performersは⼈数とデプロイ数をほぼ線形を維持。 =>
High Performance組織としての⼟台が必要。 Nicole Forsgren, Jez Humble, & Gene Kim. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press. p.92. パフォーマンス向上には、「プロセスの改善（DevOps的な話）」や「組織作り（心理的安全性）」なども重要。ただし、それだけではどうにもならない問題もある=> 技術での解決が必要 ©MIXI 12

アーキテクチャを学ぶ必要性素朴な疑問： • 開発速度の観点でいうと、アーキテクチャとか設計を考えた⽅が落ちるのでは？ ◦ ◦ 少なくとも設計考えて会議して議論してっていう⼯程が増える⼤変そうなので機能要件だけ考えて作った⽅が早いのでは？ => １回作りきって終わりのソフトウェアはそう
=> スケールし、継続的な改修が必要なソフトウェアの場合、規模拡⼤とともにそうも⾔えなくなる ©MIXI 13

機能要件の実現のみを意識した実装機能要件しかなければ、極端なことを⾔うと、クラスを定義せず、⼀つの関数でIf⽂とFor⽂だけで組み⽴てたコードでも良いことになる。ただ機能を追加していくだけのコード。機能要件は実現できても、人間にとって理解しづらい。 ※あくまで疑似コードです。 ©MIXI 14

密結合と疎結合ソフトウェアアーキテクチャや設計の⽂脈においては、”ソフトウェアの構成要素同⼠の結合度合い”が重要な設計の観点となる。 • 密結合（⼀般的に良くない状態） ◦ • 疎結合（⼀般的に良い状態） ◦ ©MIXI
クラスやモジュールが互いの内部構造や具体的な実装に依存している状態 ▪ 例：他のクラスの変数を直接参照したり、インスタンス⾃体を変数に持つなどクラスやモジュールが互いの内部構造や具体的な実装に依存していない状態 ▪ 「インターフェースや抽象のみへの依存」、「集約」など 15

密結合した実装の例例：「家族アルバムみてね」のようなアルバムサービスを想定仕様：アプリのユーザはアルバムの作成と参加が可能 => コード上では機能要件は満たしている UserクラスがAlbumクラスに依存している => 例えば Albumのコンストラクタが変更されたら
`create_album` が壊れる可能性がある ※以降もあくまで疑似コードなので、プログラムとしての正しさは仮定してません。 ©MIXI 16

密結合した実装の例 Albumの仕様変更：`follower_scope`を追加（参加者のアクセス権制御） • 定数定義が変わったら依存先が壊れる ◦ • オブジェクトがどこでどう変更されるかが分からない ◦ ◦ ©MIXI
1 がフル権限になったら`create_album`が壊れる UserがAlbumのインスタンスを持っていて、やろうと思えばメンバ変数にも直接アクセス‧変更できるバリデーション（整合性チェック）の実装が分散しやすい ▪ そうなると別の場所ではバリデーションをやり忘れたり、バリデーションの変更漏れも起きやすい ▪ ※本来はAlbumクラスにscope変更のメソッドを⽣やすなど、⼀箇所にできると良い 17

密結合の特徴これらの例では、規模も⼩さく仕様もシンプルなのでミスも起こらないと思うが、規模が拡⼤すると、仕様も複雑になり、把握できない部分も増えていくため、より影響が⼤きくなる。密結合の特徴を整理すると以下の通り • • • ©MIXI 他のモジュールの変数やメソッドにアクセスし放題で、開発はしやすい
⼀⽅で、変更時の影響範囲が広く、それらを適切に把握できないとバグを⽣むつまり、あるモジュールの開発‧改修を⾏う際に依存先のモジュールに関する知識も必要になってしまう 18

密結合について（リアルに⾟さをイメージしてもらうため）密結合した１００億⾏のコードで出来たシステムを想像してみてください。あなたの配属先事業ではそのシステムを扱います。数ヶ⽉後に新機能のリリースが迫っていて、そこを担当してもらいます。さらに、新機能は仕様書だけで数⼗ページあります。 => どれくらい絶望的な状況か理解していただけたでしょうか？ ©MIXI 19

アーキテクチャを学ぶ必要性規模が⼤きくなると遅くなる原因 • コード量‧機能量が多いことによる認知負荷増 ◦ ◦ ◦ どのコードや機能がどこに依存しているのかわからなくなる（メンバーの離職等により）誰も把握していないコードも増える =>
時間とともに、もはやそのソフトウェアを⼗分に理解することが不可能になる • 障害やバグの数も増える ◦ • つまり、本質的な機能改修に取り組める時間がどんどん失われていく組織の⼈数が増えることによるコミュニケーションコスト増 ◦ リリースなどの調整先が増える、コンフリクトも増える ※特に前スライドのように複雑なものに複雑なものを追加する時は顕著になる ©MIXI 20

アーキテクチャを学ぶ必要性以上を踏まえると、このグラフが起こりうる現実としておかしくないと理解してもらえるはず。 • • 既存のエンジニア ◦ 勤務時間における会議や障害‧バグ対応、コンフリクトの割合が増える ◦
本質的な業務に取り組めない新規参⼊エンジニア ◦ 読まなければいけないコードが多すぎて把握しきれない ◦ ⼀⼈⽴ちできるまで時間を要する Nicole Forsgren, Jez Humble, & Gene Kim. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press. p.92. アーキテクチャを学ぶ必要性：要点 ©MIXI • • エンジニアの増加に対するパフォーマンスの最⼤化を⽬指す機能改修の速さはビジネス観点では ”競合優位性（参⼊障壁）” となる 21

（再掲）⽬次 • • • • • • • • ソフトウェアアーキテクチャとは
アーキテクチャを学ぶ必要性 <= ここまで終了モノリシックアーキテクチャマイクロサービスアーキテクチャモノリス vs マイクロサービス？？疎結合を実現するための⽅法論の紹介ドメイン駆動設計（DDD）の解説 DDD実践演習質問あれば受け付けます。 ©MIXI 22

補⾜：エンジニア組織のパフォーマンス計測組織の開発のパフォーマンスを測るのは実際にはかなり難しい。デプロイ数で計測するというのは⽅法の⼀つ。有名なものとしては、Four Keysがある。リードタイムデプロイ頻度変更失敗率平均修復時間(MTTR) コードがコミットされてか
ら本番環境で正常に機能するまでの時間コードを本番環境にデプロイまたはリリースした頻度リリース後に障害や不具合等により修正を⾏う必要が⽣じた割合変更失敗時にサービス復元までにかかる時間リファクタリング‧リアーキテクチャのKPIに設定し、そこの改善を⾒ると⾯⽩そう。 ©MIXI 23

ソフトウェアアーキテクチャとは（再掲）ソフトウェアアーキテクチャと聞いてよく出てくる⽤語 • • • • クリーンアーキテクチャレイヤードアーキテクチャオニオンアーキテクチャヘキサゴナルアーキテクチャ
• • モノリシックアーキテクチャ（モノリス）マイクロサービスアーキテクチャこちらはあくまで⼀つのモノリス or サービスの内部の構造の話まずこちらを扱うここから、まずマクロレベルの設計の話として、モノリスとマイクロサービスについての概要と、アーキテクチャ選定に関する考え⽅の解説をします。 ©MIXI 24

モノリシックアーキテクチャ ©MIXI

モノリシックアーキテクチャ⼀般的な説明：「コードベースが単⼀」、「全ての機能が同⼀プロセス内で動作」、「各機能が密結合（※）」後で補足します。 Business Logic API Business Logic 外部
サービス Adapter Business Logic Business Logic Business Logic Web UI Business Logic Adapter DB 普通に作ったら⼤体こうなる ©MIXI 26

モノリシックアーキテクチャ⼩規模アプリケーション開発の場合 • テストがしやすい ◦ • デプロイしやすい ◦ • 複雑なコンポーネントに分かれていない、シングルバイナリ
スケーリングが簡単 ◦ • サーバー間通信などもなく、E2Eテストも簡単アプリケーションを複数インスタンスで実⾏するだけ開発もしやすい ◦ ◦ コードベースが単⼀（やろうと思えば全てのクラス‧メソッドにアクセスできる） DBも単⼀（全てのデータを参照できる、整合性の担保も簡単）全てが⼀箇所であることからくる利点 ©MIXI 27

モノリシックアーキテクチャ⼤規模アプリケーション開発の場合 • テストが⾟い（実⾏時間等） ◦ • 異なるリソース要件の機能が混在するため開発がしづらい ◦ ◦
• ⼤⼈数で同じコードベースを触るので競合が増えるスケーリングが⾟い ◦ • メリットだった部分が全て反転してくるデプロイが⾟い ◦ • ⼀部の機能を修正しただけなのに全体のテストが動くコードベースがデカすぎて⼀⼈のエンジニアが理解できるキャパを超えてしまう古い技術スタックに縛られる（依存する範囲が広いため）信頼性低下 ◦ ◦ バグや障害を起こしやすく、発⽣時に特定しづらくなる依存箇所が多いライブラリのアプデ難易度も上がるアプリケーション開発において、規模が拡⼤するとあらゆる問題が出現してくる ©MIXI 28

マイクロサービスアーキテクチャ ©MIXI

マイクロサービスアーキテクチャ⼀般的な説明(※)：アプリケーションを⼩さく、独⽴したサービスの集合体として設計‧開発するアプローチ。サービスごとに独⽴したコードベース‧基盤‧データベースを持ち、独⽴してデプロイされる。サービス： • 特定の機能を提供し、個別にデプロイできるソフトウェアコンポーネント •
外部からはAPI経由でのみアクセス可能（疎結合） ※ただし、次のセクションで話しますが、定義にとらわれる必要はありません ©MIXI 30

マイクロサービスアーキテクチャマイクロサービス（の理想状態）では、以下のような恩恵が受けられる。 • テストが効率的 ◦ • デプロイがしやすい ◦ • サービスごとに、リソース要件に合わせてスケーリングできる
⾃分の担当するサービスに関する知識だけあれば良いので、認知負荷が低い依存範囲が狭いため、技術スタック‧ライブラリの更新がしやすい（サービスごとに可能）信頼性向上 ◦ ©MIXI 他のサービスの開発者の作業に影響されない開発‧メンテナンスがしやすい（保守性） ◦ ◦ • あらゆる事柄を個別のサービス単位で考えられるようになる恩恵スケーリングが効率的 ◦ • 変更したサービスだけテストすれば良いコードベース、DB、インスタンス等が分かれているため、障害発⽣時の影響を限定できる、原因の特定がしやすい 31

マイクロサービスアーキテクチャこのリポジトリ渡されて開発任されるのと、このリポジトリ渡されて開発任されるの、どっちが良いですか？基本的にはこういうイメージで考えてもらえるとわかりやすいかも。 ©MIXI 32

マイクロサービスアーキテクチャマイクロサービスアーキテクチャの⽋点 • マイクロサービスを理想通り実現するためには多くの専⾨知識が必要 ◦ 様々な設計パターンに関する知識 ◦ 分散システム特有の問題への対処 • サービスへの適切な分割を考える難易度が⾼いこと
◦ 他サービスの開発に影響しない分割（疎結合）をする必要がある => 具体的にマイクロサービスの構築で考えなければいけないことをみていきます ©MIXI 33

マイクロサービスアーキテクチャ「サービス間通信はどうするか？」サービスに分かれることになるので、サービス間でやり取りが必要となることがある。せっかくサービスで分かれているのに、これまで通り同期APIで呼び出していては可⽤性が上がらない。 => （可⽤性を上げたければ）出来るだけ⾮同期のメッセージング基盤等でやり取りする設計に変える必要がある。例えば「家族アルバムみて
ね」の例でいうと、写真アップロード時に AIによる写真の解析処理が動くが、解析処理の遅延や失敗でアップロード機能自体を利用不可にしたくない。 => 非同期通信にする ©MIXI 34

マイクロサービスアーキテクチャ「サービス間でのデータ整合性はどうするか？」サービスごとにDBが分かれることにより、様々な問題が⽣じる。特に複数サービスにまたがったデータの整合性維持は難しい問題。結果整合性で考えていくことになる（※サーガ）。 ※単⼀DBではトランザクションのACID特性により整合性を担保できる。注文キャンセルの例： ©MIXI 在庫修正だけ失敗すると配送してないのに在庫数が減ってデータの整合性が壊れることに
35

結果整合性とは分散システムにおいて、⾼いパフォーマンスや可⽤性を優先するために⽤いられる整合性担保の⽅法。通常のRDBなどで保証されている「強い整合性」では、トランザクション処理によってデータの更新が即時にすべてのテーブルで反映されます。⼀⽅で、「結果整合性」では、⼀時的な不整合‧不⼀致を許容しつつ、最終的には全体が⼀貫性を持った状態に落ち着くことを保証する整合性モデルです。 ©MIXI 36

結果整合性の⾟みマイクロサービスではサービス間のデータ整合性は結果整合性を前提としているのでそれに伴う問題の考慮は当然必要になってくる。⾮同期更新なので、DB研修で習ったような「ダーティリード」、「ノンリピータブルリード」、「ファントムリード」に類似するような問題が発⽣し放題。その他の問題も多い。 • • • 注⽂処理は成功しているのに在庫情報が変わっていない（更新遅延）在庫確認してから注⽂処理を確定し、その後在庫を引き落とそうとしたらなかった
決済で処理が失敗したが、在庫の修正前（確定前）の値を読んでしまう（対処できるものもあるが）これらが致命的になるデータの場合は、単⼀のサービスに含める必要がある。多くの場⾯でトランザクションの分離性よりもパフォーマンスが重要視されるようになってきているとはいえ、データの整合性は事業の存続に関わる重⼤な問題であり、正確に判断するための知⾒が必要。 ©MIXI 37

マイクロサービスアーキテクチャ「そもそもどうやってサービスに分割するか？」⼀般的なシチュエーションとしては、事業がスケールし、密結合が⾟く感じるようになってから、マイクロサービスへの移⾏を検討するようになる。ただし、単に特定の機能をサービスに切り出しても、アーキテクチャ図上の⾒え⽅が変わるだけで実態は変わるわけではない。「サービスに切り出した」 => 「疎結合」ではなく
「疎結合」 => 「サービスに切り出せる」 ©MIXI 38

マイクロサービスアーキテクチャ先ほどのアルバムアプリの例を再掲この状態で単にUserを別のコードベースに切り出しても、当然Àlbum`周りでÙndefined Error`が出まくるだけ。まずはAlbumクラスへの依存を解消してからでないと切り出せない。依存の多いクラスは全ての依存を解消して初めて切り出せる。この作業だけでも⼤変。 ©MIXI 39

マイクロサービスアーキテクチャ加えて、⾒かけ上のエラーがなくなっても密結合が解消されるわけではない本質的に疎結合を実現してからでないと以下のような状態に陥る可能性がある • • • • 切り出したサービスで、処理の途中で元のサービスのデータが必要になり、何度もやり取りが発⽣する切り出したのに、元のサービスの知識が必要
お互い共有ライブラリのロジックに依存しているサービス間通信のインターフェースが曖昧で頻繁に変わるこのように、せっかく切り出しても独⽴して開発できない状態になってしまう。 ©MIXI 40

マイクロサービスの失敗ここまで聞くと、マイクロサービス化はかなり難易度が⾼いことがわかる => 実際、マイクロサービス化 / サービス切り出しの失敗例は数多くある失敗例 • 組織の構造にあっていない ◦
• 内部構造をそのままにサービスへの分割を⾏ってしまっている ◦ • サービスごとに担当する⾃⽴したチームがいなければ、サービスだけ分かれていても効果が薄い先ほども説明したように、モノリスに課題を感じているからといって、単にサービスに切り出すだけでは問題は解決しない（それどころか悪化する可能性も）マイクロサービス化が⽬的になってしまっている ◦ アーキテクチャはあくまで⾮機能要件を実現するための⼿段失敗すると、頑張ってサービス分割してもメリットを享受できずにデメリットだけ追加される可能性も... => しっかりとした⽬的と知識を持って進めることが⼤事。 ©MIXI 41

⼀旦休憩質問あれば受け付けます。質問終了後、トイレ休憩も挟みます。 ©MIXI 42

補⾜：サーガ • • • マイクロサービスにおいて、複数サービスでデータを⼀貫性を持って更新するための⽅法⾮同期メッセージングによる⼀連の「ローカルトランザクション」と「補償トランザクション」の組み合わせで整合性を維持する仕組み ◦ 補償トランザクション：処理失敗時に、途中までコミットしてしまった操作を戻すトランザクション処理
ACDのみ保証、Cは結果整合性のみ保証 ◦ 「I（分離性）」はサポートしないので注意コレオグラフィベースとオーケストレーションベースの２種類がある。 ©MIXI 43

補⾜：コレオグラフィベースサーガ • • サーガの参加サービス⾃⾝が⾃律的に連携し合う失敗した場合の補償トランザクションのリクエストも各サービスが担う API XXX サービス API
YYY サービス API ZZZ サービス API ABC サービス API ABC サービスそれぞれで非同期にローカルトランザクションが実行される（結果整合）。補償トランザクション打ち消すためのトランザクション実行 API XXX サービス打ち消すためのトランザクション実行 API YYY サービスここで処理が失敗 API ZZZ サービス補償トランザクションのパブリッシュ ©MIXI 44

補⾜：オーケストレーションベースサーガ • • サーガに参加する各サービスへの制御を中央集権的に担うリクエストや補償トランザクションの管理 API XXX サービス API
YYY サービス API ZZZ サービス ABC サービスサーガオーケストレーター ©MIXI 45

モノリス vs マイクロサービス？？ ©MIXI

モノリス vs マイクロサービス？？ここまで、モノリスとマイクロサービスという2つのアーキテクチャパターンの概要を解説しました。対⽐する事柄なのでよく⽐較されることもある • • モノリスは悪・善？マイクロサービスは悪・善？
結局のところどっちの⽅が優れているのか？どちらを採⽤すれば良いか？ => 「モノリス vs マイクロサービス」という構図はそもそも間違い ©MIXI 47

モノリス vs マイクロサービス？？そもそもどちらか⼀⽅ではなく、基本的には共存することが多い。どちらも活かす。スケールするプロダクト開発では、以下のような流れになるのが⼀般的。 • • 初期フェーズ： ◦ まずは、⼩規模少⼈数で利点が多い”モノリス”で開発を始める
組織規模拡⼤後： ◦ 必要に応じてマイクロサービスも検討するようになる ◦ 分割する必要のあるものからサービスに切り出されていくこのように、モノリスとマイクロサービスが共存している状態になるはず。特定のアーキテクチャスタイルやデザインパターンを採⽤したからといって、全てそれに従わなければいけないわけではない。 ©MIXI 48

モノリス vs マイクロサービス？？課題感（その１）： • • モノリス⾟いのでマイクロサービスにしたい。でもサービス間のデータ整合性の問題が⽣じるのは厳しいかも。対処法： =>
データ整合性の重要度が低い部分だけ切り出せば良い • • • ©MIXI ここでも、マイクロサービスアーキテクチャを採⽤したら何でもかんでも細かくサービスに切り出さなければいけないわけではないサービスに切り出してより⾟くなるのは本末転倒利点が⽋点を上回ると判断した部分だけサービスに切り出せば良い 49

モノリス vs マイクロサービス？？課題感（その２）： • • 他サービスのデータを参照したいが、毎回サービス間通信を挟むのは⾟い。パフォーマンスや可⽤性に問題が⽣じてしまう。対処法： =>
データのコピーを持てば良い他サービスの必要となるデータをあらかじめ⾃サービス内に同期しておき、そこを参照するよう変更する。こうすることでサービス間通信が不要になる。 ※これ⾃体はマイクロサービスで⼀般的な設計パターン ©MIXI 50

モノリス vs マイクロサービス？？課題感（その３）： • 他サービスのデータを同期するのも同期遅延による不整合が怖い。 ◦ 例：注⽂管理サービスで在庫管理サービスのデータのコピーを同期しているが、同期遅延で在庫管理サービス側のDB（正規）が空なのに注⽂受付してしまった。対処法：
=> Read権限のみ許可して直接他サービスのデータを参照すれば良い他サービスのDBに依存するのでもちろん可⽤性の観点では低下するが、同期遅延の⽅が問題になると判断すれば検討の価値がある。マイクロサービスだからといって必ずしもDBを分離する必要はない。 ※ロジックまで密結合になりすぎないように注意 ©MIXI 51

モノリス vs マイクロサービス？？課題感（その４） • マイクロサービスを⽬指すほどのモチベはないが、事業拡⼤に伴ってエンジニアを増やしても⽣産性が上がらないのは厳しい... 対処法： => コード上の疎結合さえ実現できていれば、上記⽬的は達成できる可能性が⾼い
=> モノリスでも可（モジュラーモノリス）エンジニアの増加に対する⽣産性向上の観点でいえば、サービスまで分けずとも、モジュール分割によって分担したり認知負荷の軽減ができれば⽣産性向上は⾒込める。そこを優先して他の要件‧サービス切り出しのメリットは妥協するとか。どこを達成したいか、どこを優先するかという考え⽅が⼤事。 ©MIXI 52

モノリス vs マイクロサービス？？ここまでまとめ： • ここまで話したように、モノリス/マイクロと⾔ってもやり⽅は⾊々あり、どっちが良い悪いではなく、トレードオフであり、適宜使い分けるものです。 • 特定のアーキテクチャスタイルやデザインパターンを採⽤するからといって、定義通りに作る必要はなく、全ての箇所で従わなければいけないわけでもありません。
◦ • アーキテクチャはあくまで⼿段であり、⾃分たちのチームの課題がどこにあって、何を解決したいかが重要です。 ◦ ©MIXI => そこを⽬指すと⼿段が⽬的化してしまう解決するための⼿段をみて、それを実⾏する利点が⽋点を上回れば実⾏すれば良い 53

アーキテクチャを学ぶ必要性モノリシックアーキテクチャマイクロサービスアーキテクチャモノリス vs マイクロサービス？？ <= ここまで終了疎結合を実現するための⽅法論の紹介ドメイン駆動設計（DDD）の解説 DDD実践演習質問あれば受け付けます。 ©MIXI 54

補⾜：マイクロサービスを検討する場⾯モジュラーモノリスでも⼗分という話もしたが、例えば以下の場⾯など。他にもあるかも。 • 機械学習モデルを動かすモジュールなど、リソース要件が⼤きく異なるもの ◦ • 技術スタックを新しくしたい場合 ◦ ◦ •
©MIXI 例：Perlで作られた古いシステムに新しい機能を追加したいが、現在ではPerlのエンジニアは市場にほとんどいない。 => このような場合は致命的であるのである程度デメリットを許容してでも、別サービスとして切り出し、既存の技術スタックに縛られずに作る⽅が良いかも横展開する汎⽤的なシステムを作る場合 ◦ • 元々ステートレスな処理でありサービスへの切り出しも容易例えば、あるプロダクトにポイント機能を追加したいとして、社内の他のプロダクトにも同様にポイント機能を提供する可能性がある場合、独⽴して動くサービスとして開発しておくと使いまわせて良いかも？外注する場合など。別組織なので独⽴して開発できるものを任せられると効率的 55

疎結合を実現するための⽅法論 ©MIXI

設計に関する各種⽅法論ここから、具体的に疎結合を実現するための⽅法について解説していきます。本当に多くのものが提唱されてるので、その内⼀部を独断と偏⾒で以下に整理してみます。 ©MIXI カテゴリ具体例主な目的や役割アーキテクチャスタイルクリーンアーキテクチャ, オニオン
アーキテクチャ, マイクロサービス, モノリスソフトウェア全体の構造・依存関係の流れ、分割の方針を決める設計思想・アプローチオブジェクト指向, ドメイン駆動設計（DDD）, CQRS 設計や実装、分割に関する思想・指針。人間が理解しやすい実装への指針。設計原則 SOLID原則, DRY, YAGNI クラス・モジュールの内部構造や依存のあり方に関するもの設計指標モジュール結合度, モジュール強度（凝集度）, LCOM 設計の品質を評価する軸、設計改善の指針になる設計パターン Repository, Factory, Saga, Entity 具体的な実装方法についてのテンプレート 57

モジュール強度（凝集度）‧結合度良い設計かどうかを判断する基本的な指標。⾼強度‧疎結合が⼀般的に良い設計とされる。 ©MIXI 58

SOLID原則オブジェクト指向の⽂脈で良く出てくる。変更に強く、拡張しやすく、理解しやすいソフトウェアを作るためのガイド。 ©MIXI 59

設計の⽅法論に関する注意点これらの考え⽅を参考にするだけでも良い設計に近づける。ただし以下に注意。 • これらの指標や原則に従うことを⽬的化するべきではない ◦ ◦ • 全てのモジュール強度最強‧結合度最弱にすることが必ずしも良いわけではない必要以上にやりすぎてしまうとかえって書きづらく、読みづらくなり本末転倒設計の⽅法論はパターンやテンプレートとして使うべきではない
◦ ◦ 重要なのは⽂脈、背景、⽬的（これを知った上で使うと効果的）パターンにとらわれるとやりすぎという状態に陥ってしまいがち ▪ • マイクロサービスで例えると、必要以上にサービスに切り出してしまっている状態単にこれに従うだけでは良い疎結合が達成できるわけではない ◦ ◦ そもそも「単⼀機能‧責務」とは何？どれくらいの範囲か？これだけだとどういうまとまりで開発を分担すれば良いか分からない => まずは全体の構造やモジュール分割の⼤⽅針が必要。 ©MIXI 60

アーキテクチャスタイル有名なものとしては、「レイヤードアーキテクチャ」、「オニオンアーキテクチャ」、「クリーンアーキテクチャ」、「ヘキサゴナルアーキテクチャ」の４つが挙げられる（以下、⼀部解説）。 • • • ©MIXI Domain（ビジネスロジック）から Infra層への依存を排除。
=> Domain層が純粋なビジネスロジックに集中できる Domain層にInfra層のインターフェースを定義し、Application層からはそこに依存させる（依存関係逆転の法則）。 61

オブジェクト指向データ構造とそのデータに対する操作（振る舞い）を⼀つのまとまりとして扱い、それらの関係からシステムを構築する⽅法論。ある役割（機能）を持った”モノ”ごとにクラスを分割するという、モジュール分割に関する指針の側⾯も。 => ⼈間が理解しやすい分割の概念が⼊る ©MIXI 概念説明
クラスオブジェクトの「設計図」に値するもの。プロパティ（属性）とメソッド（振る舞い）を定義。オブジェクトクラスから生成された「実体」。状態と振る舞いを持つ。カプセル化データと振る舞いを一つのクラスにまとめ、内部を隠蔽する。継承既存のクラスを元にして、共通処理を再利用・拡張できる。ポリモーフィズム同じインターフェースで異なる振る舞いを実現する。差し替え可能。 62

ドメイン駆動設計（DDD）ソフトウェアが解決すべき問題領域（=ドメイン）を中⼼に据えて、ソフトウェアを設計‧実装する⽅法論。オブジェクト指向の最終到達点と⾔われることもある。 DDDにおいては、「オブジェクト（モノ）」ではなく「ドメイン（ユビキタス⾔語）」に抽象化することで、現実世界のモデリングとソフトウェアへの落とし込みを⽬指している。どちらの概念もコードに意味を伝えさせる⽅法論。 • ©MIXI ドメイン（特定の業務領域‧問題領域）の例
◦ ECなら「注⽂‧⽀払い‧配送」 ◦ 銀⾏なら「⼝座‧取引‧残⾼」 ◦ SNSなら「投稿‧フォロー‧通知」 63

設計パターン適⽤の失敗例ここまで話した設計概念を”なんとなく取り⼊れる”だと失敗する。 • • • DRY（Don’t repeat yourself）やりすぎて逆に⾟い ◦ 重複を減らすためといって、なんでもかんでも共通化するべきというわけではない
機能的強度を⽬指して、機能を細分化しすぎてしまい逆にコードを把握しづらい ◦ SNSの例：「フォローリクエストできる」「フォローリクエストを承認できる」を別機能として別クラスで実装する？ ◦ やりすぎると、ファイルやクラスが別れすぎて逆にコード追いづらいことも ◦ ⼈間が把握しやすいことが⼤事なので、その意図であえて下げる判断も⼤事何らかのアーキテクチャスタイル採⽤しているのにドメイン層に知識が全くない ◦ データを持つクラスが定義されているだけ => ドメインモデル貧⾎症 ◦ ドメインルール、ビジネスロジックがドメイン層に集約させるべき => しっかりとした⽬的と設計概念への理解が重要 ©MIXI 64

ここまでまとめ（前半） • これらのように、設計に関する⽅法論は数多く提唱されています。先駆者たちのこれまでの研鑽が反映された指針として、⾮常に参考になるので、興味あると思った部分はもっと深ぼって学んでみてください • ⼀⽅で、あくまで⽅法論の⼀つであり、それに従うことを⽬的にするべきではありません。⽬的はあくまで⾮機能要件であるべきです。 • ほとんどの⾮機能要件の実現は、疎結合化によって達成できます
◦ ◦ ◦ ©MIXI ただし、必要な疎結合のレベルは⽬的の⾮機能要件によって変わる加えて、「どこをどのレベルの疎結合にするべきか」は各々の開発チームごとに異なるという認識が重要⽣産性向上のためには、⼈間にとって意味のあるまとまりを持った疎結合が⼤事 65

アーキテクチャを学ぶ必要性モノリシックアーキテクチャマイクロサービスアーキテクチャモノリス vs マイクロサービス？？疎結合を実現するための⽅法論の紹介 <= ここまで終了ドメイン駆動設計（DDD）の解説 DDD実践演習質問あれば受け付けます。その後休憩に⼊ります。 ©MIXI 66

演習問題 ©MIXI

演習問題ここまでの内容を振り返るために、アーキテクチャに関するケーススタディ的な例題をいくつか出してみます。扱うテーマ的に、明確に回答があるわけではないですが、少し時間を取るので考えてみてください。 ©MIXI 68

演習問題１問：あなたは密結合しているシステムのマイクロサービス化に着⼿しようとしています。「システムのコアとなる機能やロジックが集約された”巨⼤クラス（密結合）”」から、「あまり使われておらず他との依存が少ない⼩規模なクラス」まで様々な機能やクラスが存在します。ここで、どちらのクラス‧機能からサービスの切り出しに取りかかるべきでしょうか？ ©MIXI 69

演習問題１問：あなたは密結合しているシステムのマイクロサービス化に着⼿しようとしています。「システムのコアとなる機能やロジックが集約された”巨⼤クラス（密結合）”」から、「あまり使われておらず他との依存が少ない⼩規模なクラス」まで様々な機能やクラスが存在します。ここで、どちらのクラス‧機能からサービスの切り出しに取りかかるべきでしょうか？回答例： • • ©MIXI ⼩さく依存の少ないクラス（すでに疎結合）
◦ 切り出しやすい。ただし、更新頻度が少ないためそもそも開発効率を上げる意味がない ◦ 第⼀歩としての成功事例を作るためならありあらゆる機能改修に関わってくる巨⼤クラス（ゴッドクラス） ◦ 今後の開発の効率化に繋がり、切り出す効果は⾼い ◦ ただし、依存先が多いため、疎結合化するにも全体の把握と多くの調整が必要 70

演習問題２問い：あなたはある会社から新規サービスの開発案件を受注しました。その会社では、エンジニアが⾜りないのでひとまず外注して開発を進めたいということだったが、納品後の機能改修やメンテナンスは⾃社内で継続的に⾏うということだった。あなたは技術⼒に⾃信があったので、納品先での今後の開発効率やサービスのスケールまで考慮し、マイクロサービスアーキテクチャを採⽤した。この判断は正しいでしょうか？ ©MIXI 71

演習問題２問い：あなたはある会社から新規サービスの開発案件を受注しました。その会社では、エンジニアが⾜りないのでひとまず外注して開発を進めたいということだったが、納品後の機能改修やメンテナンスは⾃社内で継続的に⾏うということだった。あなたは技術⼒に⾃信があったので、納品先での今後の開発効率やサービスのスケールまで考慮し、マイクロサービスアーキテクチャを採⽤した。この判断は正しいでしょうか？回答例：例えば納品先が基本エンジニア⼀⼈体制ならオーバースペック。また、納品先でマイクロサービスに関する知⾒が無ければむしろ負債化するリスクもある。サービスまで切り出さずとも、モノリスで内部が疎結合であれば⼗分な場合も多い。
その辺りの背景を汲み取った上で判断が必要。 ©MIXI 72

演習問題３問：あなたの開発チームでは出前サービスを開発しています。ここで、競合サービスを作っている他社のエンジニアから、出前サービスでは「注⽂管理」、「配達」、「決済」で、ロジックを明確に分けて考えることが可能なのに、このシステムでは密結合になっているためリファクタが必要と指摘されました。どうするべきでしょうか？ ©MIXI 73

演習問題３問：あなたの開発チームでは出前サービスを開発しています。ここで、競合サービスを作っている他社のエンジニアから、出前サービスでは「注⽂管理」、「配達」、「決済」で、ロジックを明確に分けて考えることが可能なのに、このシステムでは密結合になっているためリファクタが必要と指摘されました。どうするべきでしょうか？回答例：競合他社と事情（組織構成‧技術スタックなど）が同じとは限らないため、⾃社でも分割が最適とは限らない。例えばその競合他社とは類似していても強みとする機能が異なる場合、機能改修や更新頻度は変わることになる。開発頻度が低いモジュールをあえて分割しても効果は薄い。
補⾜：外部の⼈から「このソフトウェアは密結合だ」と⾔われても、内部の⼈達が問題に感じていないならその組織にとっては必要⼗分。あくまで開発を担当するチーム内で基準を持つべき。 ©MIXI 74

演習問題４問：SNSなどで、AI〇〇アプリ（もしくは機能）がバズっており、⼀定規模の市場が望めることがわかった。あなたは同じようなアイデアを持っていたため、⾃⾝でもアプリ（もしくは機能）の開発をすることを考えた。この時、どのような設計を考えるべきでしょうか？ ©MIXI 75

演習問題４問：SNSなどで、AI〇〇アプリ（もしくは機能）がバズっており、⼀定規模の市場が望めることがわかった。あなたは同じようなアイデアを持っていたため、⾃⾝でもアプリ（もしくは機能）の開発をすることを考えた。この時、どのような設計を考えるべきでしょうか？回答例：機能要件だけでも実装し、とにかく早くリリースすることを優先するのもあり。トレンド的なものだと、競合も同じように考えやすいので、速さが正義になる可能性も。この場合は、設計とか考えている場合ではなく、ビジネスチャンスを逃さないためにもとにかく先にリリースしたい。密結合
= 絶対悪ではない。速度を優先させるために意図して選択することもありうる。 ※注意：密結合の⽅が早いかどうかは状況による ©MIXI 76

アーキテクチャを学ぶ必要性モノリシックアーキテクチャマイクロサービスアーキテクチャモノリス vs マイクロサービス？？疎結合を実現するための⽅法論の紹介ドメイン駆動設計（DDD）の解説 DDD実践演習⼀旦休憩を挟みます。 ©MIXI 77

疎結合を実現するための⽅法論ドメイン駆動設計（DDD）の紹介 ©MIXI

ドメイン駆動設計の背景 • • • • ここまで話してきたように、ソフトウェア開発は複雑で⾊々な問題を抱える。ドメイン（業務領域‧問題領域）⾃体が本質的に複雑であることが要因の⼀つ。 ◦ ⼈間の⾏う⼊り組んだ業務や活動をプログラムに落とし込む作業なので、当然と⾔えば当然。
何もしないとソフトウェアはどんどん密結合し複雑になっていってしまう。 ◦ ビジネスルールがコードのいたるところに散在してしまうそこからさらに複雑なドメインが現れたら、⼿も⾜も出せなくなる。 ◦ ※例えば、AI等による技術⾰新で業務フローやユーザ⾏動に重⼤な変化が起きたとしても、そのレベルの変更をソフトウェアに反映させるのは不可能になっているかもしれない => 次から次に機能を満たすコードを作成するだけでなく、「ドメインに対する理解」と「モデリング」にしっかりと取り組むことが重要 ©MIXI 79

ドメイン駆動設計の⽤語集 • ドメイン（Domain） ◦ ◦ • ドメインエキスパート ◦ ◦ •
システムが解決しようとする業務領域‧問題領域のこと例：ECサイト（注⽂管理‧在庫管理）、SNS（投稿、フォロー、リアクション）などその業務の専⾨家 ▪ 医療システムであれば医者、看護師、医療事務⼀般ユーザ向けアプリであれば、ユーザの⾏動や背景を深く理解している⼈ ▪ PO、PMなどユビキタス⾔語 ◦ 開発者とドメインエキスパートなどの参画者が共通して使う⾔葉 ▪ ◦ コミュニケーションにおける⾔語の認識のズレが起きるのを防ぐモデル、クラス名、関数名など、コード上でもそのままその⾔語が使われる ※toBの業務システムとtoCのビジネスで若⼲解釈に違いはある。今回は主にtoC向けに解説。 ©MIXI 80

ドメイン駆動設計の概要（その名の通り）ドメインを深く理解し、それを中⼼にシステムを組み⽴てる設計思想。 ※開発プロセスやコミュニケーション等にまで踏み込んだ思想であるが今回は省略。 DDDを取り⼊れることにより、ソフトウェアは以下のように変わる • • ©MIXI ドメインモデルに責務が集中する ◦
プログラムで動作するドメインのルールや振る舞いが全て書かれている ◦ => つまり、コードがドキュメントになる（常に最新版を担保）ドメインモデルによるモジュール分割 ◦ 変更に強く、意味のある単位での疎結合化 81

ドメイン駆動設計の流れ基本的な流れ • • • ドメインモデリング実装レビュー‧ドメインの理解これを繰り返していくことで、ドメインモデルが洗練されていく。
ドメインモデリングレビュー・ドメインの理解実装 ※今回は省略してますが、このサイクル⾃体もDDDにおいてはかなり重要な側⾯を持ちます。 ©MIXI イテレーション 82

ドメインモデリングドメインエキスパートの中にある知識を、必要な性質を取捨選択して抽象化し、ソフトウェアで扱えるようにするための作業（設計にあたる）。モデリングの流れの例 • • • • なんとなくクラスを定義ドメインエキスパートと対話し、ドメインについて理解を深める
するのではなく、こういったモデリングをしっかり ◦ どういった概念‧ルール‧関係があるのかを整理するやろうというのが DDDで名詞や動詞に注⽬しながら⽤語を洗い出す（ユビキタス⾔語）す。 UMLなどでモデルと関係を整理するモデルをドメインオブジェクトと対応づける ◦ ドメインオブジェクト：モデルをソフトウェアで動作するモジュールとして表現オブジェクトには、振る舞いと守るべきルールがある。単なるデータスキーマではなく、ドメインモデルにそういった知識を反映させていくことが重要。 ©MIXI 83

ドメインモデリング先ほどのアルバムサンプリアプリをモデリングした例（UML）左：ユースケース図、右：ドメインモデル図 ※今回はシンプルすぎるので図にする必要もないが、複雑な例では図が役に⽴つこともあるこれで実装に進めるフェーズに。 ©MIXI 84

DDDの実装ドメインモデリングが完了したら、それを元に実装することになります。当然ですが、モデリングした結果と実装が乖離してしまっては意味がないので、正しくコードに落とし込む必要があります。 DDDでは、ドメインモデルを実装に落とし込み、システムを構築するための設計パターンも提唱されています。重要な概念を紹介していきます。 ©MIXI 85

ドメイン駆動設計のパターン（構成要素）ドメインの知識を表現するための構成要素アプリケーションを実現するための構成要素集約アプリケーションサービスエンティティリポジトリ • •
©MIXI ファクトリ利用して組み立てるドメインサービス仕様値オブジェクトモデリングした知識を⼀箇所に集中させるそれを活⽤してアプリケーションを組み⽴てる 86

値オブジェクト（Value Object）ライフサイクルのないオブジェクト。値に関する知識を表現する。 • • ©MIXI 値オブジェクトの例ルール住所都道府県・市区町村・番地など
名前姓と名から成るメールアドレス特定のフォーマットがある座標 (x, y)の数値の組み合わせで表現されるこういった何らかのルールがあるものは、プログラミング⾔語のプリミティブ型（Int, Float, Stringなど）ではなく、独⾃の型として定義して知識を組み込むのが良い必要に応じて、振る舞い（メソッド）を定義することもある 87

値オブジェクト（Value Object）アルバムアプリのコード例（再掲）： • • • ©MIXI follower_scopeに関するバリデーションを利⽤側で書いている。他にもアクセスする関数‧メソッドがあればその都度バリデーションの記述が必要。 Albumクラスを⾒ても、follower_scopeに関するルールが書かれていない
88

値オブジェクト（Value Object）修正コード例（擬似コード）： ※便宜上Go⾔語に変わってます。 • • ©MIXI FollowerScope型を定義し、コンストラクタにルール（バリデーション）を記述 ◦ FollowerScopeのインスタンスが存在している時点でバリデーション通っていることが保証される
ため、他の場所でバリデーションする必要がなくなる（※Goの場合は紳⼠協定が必要）このように、値オブジェクトに意味‧ルールを持たせた⽅が⼀箇所にまとまり、把握しやすい 89

エンティティ（Entity）ライフサイクルのあるオブジェクト。⼀意に識別するためのIDを持つ。状態の変化を得ても、IDにより同⼀性が判断される。エンティティの例ライフサイクルユーザーアカウント登録し、退会までシステムに存在し続ける。注文リクエストを受けてから生成され、 ”ステータス=完了”までの状
態変化がある。商品登録後、価格や在庫の変動などの状態変化がある。取扱い対象商品から除外されて役目を終える。エンティティでは、ルールに加えてこういった振る舞いを定義することが多い。 ©MIXI 90

エンティティ（Entity）先ほどのUserクラス、Albumクラスに識別⼦（ID）を追加すれば、エンティティに該当する。ただし、UserクラスにAlbumクラスの振る舞いが書かれてしまっていたので直す。 ChangeScopeは、アルバムの属性に対する変更操作なのでここに移動仕様の⾃然⾔語で書かれた通りではなく、どのドメインモデルに対する操作‧振る舞いかということを意識してメソッドを定義することが⼤事。 ※UserクラスにはUserモデルに関する振る舞いを書く ©MIXI
91

集約（Aggregate）⼀貫性を保つべきエンティティや値オブジェクトをひとまとめにしたもの。 • 集約パターンにおける実装上の制約 ◦ 集約ルート（Aggregate Root）を外部とのやりとりの唯⼀の窓⼝とする ▪ 内部のオブジェクトには直接外からアクセスさせない ◦
他の集約のオブジェクトを直接参照することを禁⽌（IDのみ許可） ▪ • ©MIXI 先ほどの例だと、UserクラスがAlbumクラスのコレクションを保持しているが、これを禁⽌する => 集約を境界としてモジュール分割される（疎結合化） 92

集約（Aggregate）修正コード例： • • • • ©MIXI Album、Userそれぞれを集約ルートとして捉え、Id以外の変数を⾮公開に便宜上、それぞれのクラスのID型を作成 Album、Userそれぞれで、互いのIdのみ保持するよう変更
=> ここまでいけば、Userクラス開発担当者はAlbumクラスに関する知識が不要になる 93

その他 • ドメインサービス（Domain Service） ◦ ◦ • エンティティや値オブジェクトに属さないドメイン知識に関するロジック（関数）を表現 ※例えば、存在確認‧重複確認のメソッド（Exists）は、エンティティ⾃⾝の振る舞いとして定義するのは違和感であるため、ドメインサービスとして実装する。
リポジトリ（Repository） ◦ ◦ ◦ データの永続化や読み込みのためのインターフェース DDDにおいては「集約」を保存‧取得する役割そのため集約単位で設計するのが基本 • ファクトリ（Factory） ◦ 複雑なドメインオブジェクトの⽣成処理をカプセル化するための要素 ◦ コンストラクタで記述するのでは重すぎる⽣成処理の場合はファクトリを使う • 仕様（Speciﬁcation） ◦ 複雑なドメインオブジェクトのバリデーションルールをカプセル化するための要素 ©MIXI 94

ドメインモデルを隔離するための⽅法アーキテクチャスタイルを採⽤し、全体の構造と依存の⽅向を整理する => ここではオニオンアーキテクチャを採⽤（Domain層からInfra層への依存を無くせるため） • Domain層 ◦ ドメインオブジェクトを実装 ◦ ◦
ドメイン知識がこの層に集中するリポジトリのインターフェースもここで定義 • Application層 ◦ ドメインオブジェクトとInfra層（DIP）を活⽤し、ユースケースを組み⽴てる • Infrastructure層 ◦ ドメインオブジェクトの永続化‧取得を担う ▪ ◦ ©MIXI I/O両⽅ドメインオブジェクト（DAO返さないよう注意）リポジトリ、ファクトリなどの実装がある 95

オニオンアーキテクチャどうやってコード上でオニオンアーキテクチャを実現するか？（Go⾔語の例）サンプルリポジトリ： => https://github.com/tonouchi510/application-arch-blueprint Go⾔語の特徴 • • • ©MIXI
パッケージレベルのアクセス制御⽅式 ◦ パッケージ外部では public のみアクセス可能で、パッケージ内部では他オブジェクトの private 変数‧メソッドにもアクセスできる => 集約の実装にも適している ◦ 各レイヤ（層）をパッケージで分けることで、他の層から内部データにアクセス不可能にできる静的型付け⾔語である => 設計上のルールを、紳⼠協定でなく、コード（仕組み）で担保できる 96

オニオンアーキテクチャこういったアーキテクチャスタイルを採⽤した時には、各レイヤ（層）をまたぐ際に、データを別のオブジェクトに詰め直す処理がある。 • リポジトリ（インフラ層） ◦ ◦ • 内部では使⽤するORMライブラリのデータ構造を扱うことになるが、返却時はドメインオブジェクトに詰め直す
=> 他の層でDB操作をさせないため⼊⼒もドメインオブジェクトにすることで保存前のバリデーションが不要にアプリケーション層 ◦ ◦ 内部ではドメインオブジェクトを触っても良いが、上位層に返却する時にはDTO（ロジックを持たない構造体）に詰め直す必要がある意図しない場⾯でドメインオブジェクトに対する操作が⾏われないため⾯倒な部分で敬遠されがちだが、紳⼠協定でなく仕組みで防ぐために重要なこと。今ならAIがほぼ⾃動⽣成してくれるはず。 ©MIXI 97

オニオンアーキテクチャオニオンアーキテクチャを利⽤することで得られる利点を以下に整理します。 • 依存が整理される、各層の責務も明確になる ◦ どんなユースケースがあるか知りたければアプリケーション層を、どんなドメインモデルが存在してどういうルールや振る舞いがあるのか知りたければドメイン層を⾒れば良い ◦
実装の際にも、どこに実装すれば良いかを迷わずに済むようになる • ドメイン層が⼀番下でどこからも依存しない ◦ インフラ層への依存も取り除かれるため、純粋なドメインモデルの実装に集中できる ◦ ドメインモデルのテストも容易になる ©MIXI 98

ドメインモデルで逆に困る場⾯ Userデータの取得に関するユースケースを考える。ここで、参加アルバムのIDだけ取得しても表⽰に困るので、”JoinedAlbumIds”ごとに Albumデータも取得する。 => N+1問題 • • • DBに保存されているデータを取り出して返すだけなので、本来ドメインモデルの操作
も、バリデーションも必要ないドメインモデルを経由していたら⾮効率 => ドメイン層をスキップすれば良い（CQRS）（何度も話しているが）DDDを採⽤したからといって、全てDDDの原則に従わなければいけないわけではない。必要に応じてドメイン層はスキップしても良い。 ©MIXI 99

CQRS Command Query Responsibility Segregation（CQRS）とは • Command（更新系の処理）とQuery（参照系の処理）で責務を分離するパターン ◦ Command：複雑なビジネスロジックが絡み、整合性などの要件がある ◦
Query：パフォーマンス含め、更新系と異なる要件がある ▪ パフォーマンス、ページング、並べ替えなど ▪ 参照のみなのでドメインモデルの操作やバリデーションは本来不要 ◦ => Queryはドメインモデル介さずに実装する補⾜：CQRSパターン採⽤する⽅はHasuraおすすめしときます。 • • • ©MIXI Query系APIは⾃動⽣成（ただしGraphQLに限る）⼈間はCommand系の実装に集中できる興味あれば調べてみてください 100

DDDも銀の弾丸ではない • DDDに限らず、設計の理論やパターンを学ぶと⼤きな期待感を抱いてもらえるかも。 • ⼀⽅で、実際のプロジェクトでやろうとするとひどい現実が降りかかってくることも ◦ 組織上の問題もあれば、技術的な問題も ▪ ◦ 指針が⽰されているとはいえ、どう実装するか悩む場⾯もまだ出てくるはず
▪ ◦ • 技術への適合、時間の制約、ドメインに対する理解不⾜などで諦めが必要な場⾯もどこの層、どのオブジェクトが適切か？など＝> 経験も必要になってくる部分結局リファクタリングは必要 ◦ 最初にしっかりドメインモデリングしてから実装するとはいえ、最初から完璧なドメインモデルを得られることはほぼない。ドメインに対しては継続的な学習が必要。 ◦ ドメインモデルは開発のサイクルを通じて洗練させていくもの銀の弾丸ではないが、設計やリファクタにおける⼤きな指針として活⽤してください。 ©MIXI 101

ドメイン駆動設計まとめ少なくとも、今回話した内容を取り⼊れることで、機能要件のみを満たすコードを作成するだけのコードよりも、はるかに意味を伝えてくれて、可読性の⾼いコードになると思います。 ※左と右、どちらの書き⽅が読みやすいですか？ ©MIXI 102

アーキテクチャを学ぶ必要性モノリシックアーキテクチャマイクロサービスアーキテクチャモノリス vs マイクロサービス？？疎結合を実現するための⽅法論の紹介ドメイン駆動設計（DDD）の解説 <= ここまで終了 DDD実践演習質問あれば受け付けます。その後休憩に⼊ります。 ©MIXI 103

DDD実践演習 ©MIXI

1. ドメイン（業務領域‧問題領域）の理解をするドメインエキスパートとの対話であったり、書籍や⽂献、ネットなどから情報を集めるのが⼀般的な⽅法。今回はリリース済みのアプリであり、公式サイトがあるのでそこから学ぶ。 => https://mitene.us/ ©MIXI 106

3. ユビキタス⾔語による統⼀‧整理議論におけるコミュニケーションエラーを減らすために、この段階でユビキタス⾔語を定義しておくと良い。ユースケースの洗い出しで出てきた単語や概念を整理し、⽤語を統⼀する。めんどくさいので省いちゃいがちだが、今だと議事録からAIがドキュメント化してくれるかも？ ©MIXI 108

4. モデリングの対象を決めるいきなり全てのモデリングを⾏うのは⼤変。対象を絞ってから⾏う。スモールから始めるのもありだが、基本的に事業において最も重要なコアドメインを中⼼にモデリングを⾏うのが効果が⾼い。ここでも、まずコアドメインを⾒つけてみることとする。ここまで議論した中で最も頻出した単語‧概念がコアドメインである可能性が⾼い。 ©MIXI 109

5. UMLの作成前ステップで決めたコアドメインに対して、モデリングを⾏う。モデルにどういう情報が必要か？他のモデルとどういう関係があるか？などの観点で整理し、UMLを作成する。集約（モジュール境界）も意識しながら設計すると良い。 UMLではモデルの持つデータや関係、振る舞いなどは表現できるが、モデルの持つルールは別途記述しておく。 ※補⾜：ドメインモデルはDBスキーマとは異なる。必要なデータを考える際、エンジニアだとついDBのことを意識してしまいがちだが、ドメインモデリングは出来るだけ現実世界を反映させるように
⼼がける。 ©MIXI 110

まとめ⾊々と幅広く解説しましたが、本研修では以下を持ち帰ってもらえると幸いです。 • • スケールするプロダクト開発におけるアーキテクチャや設計の重要性設計の⽅法論に対する向き合い⽅（何のためにやるかの⽬的が⼤事） ※特に今回の講義では⽣産性の観点からこれらを述べましたまた、今回話した各テーマについては、本研修ではあくまで概要を触れただけなので、より深く知りたいと思った⽅は書籍などで体系的に学んでみてください。とにかく議論したり実践することで学べることも多いと思います。
各部署に配属後、既存機能のリファクタや、新機能開発の設計の際の指針として役⽴ててもらえると幸いです。 ©MIXI 112

補⾜：⽣成AI時代にアーキテクチャ‧設計を学ぶ意義はあるか？雑談レベルのポエムです。AIでコードかける時代でアーキテクチャはどれくらい重要か？あくまで個⼈的な考えですが、以下のように考えています。 • 基本的に、ある機能の作り⽅は⼀意ではない（200⾊ある）。特に、複雑な機能になると設計によって⾮機能要件は⼤きく変わる • AIは機能要件を実現するのは得意だが、⾮機能要件については⼈間がガイドを与えないと、過不⾜が起こりうる ◦
• 密結合になると⼈間にしろAIにしろコーディングにおいて必要な情報量が増える ◦ ©MIXI => 結局理解している⼈間が必要 => 疎結合を維持できた⽅が、AIコーディングにおいてもリーズナブル 113

©MIXI 114

ソフトウェアアーキテクチャ研修【MIXI 26新卒技術研修】

ソフトウェアアーキテクチャ研修【MIXI 26新卒技術研修】

More Decks by MIXI ENGINEERS

Other Decks in Technology

Featured

Transcript