設計原則、アーキテクチャパターン、アーキテクチャスタイルの違いって何？いつどう向き合ったらいいの？を考えてみる

1.

設計原則、アーキテクチャパターン、アーキテクチャスタイルの違いって何？いつどう向き合ったらいいの？を考えてみる PHP カンファレンス名古屋 2025 Feb 22, 2025. v0.0.3 @katzumi(かつみ) Press Space for next page

2.

自己紹介（かつみ）と申します。 katzumi 「障害のない社会をつくる」をビジョンに掲げている「LITALICO」という会社に所属しています以下のアカウントで活動しています。 katzchum k2tzumi katzumi

3.

お願い写真撮影、での実況について SNS 登壇者の励みになるので是非ともご意見やご感想など、フィードバック頂けると助かります mm あとでスライドを公開します 🙆‍♀📷 🙅‍♂📹💸 🙅📸👨‍👦‍👦 #phpcon_nagoya #s

https://x.com/search?q=#phpcon_nagoya #q&f=live

4.

開発者が直面する「設計に関する情報過多」このを見て「それな」と思ったのが、本セッションをしようと思い立ったきっかけになっています Post しまぶ @shimabox · Follow うーん、やっぱり、なんちゃらアーキテクチャうんぬんよりかはSOLID原則を意識して設計するだけでいいような気がするなぁ。なんだろ、アーキテクチャを先に考えると順番が逆になっちゃうんだよな。原則を守ってたら、なんちゃらアーキテクチャっぽくなってました。っていうのがいい気がするな。 8:05 AM · Sep 20, 2024 487 Reply Copy link Read 4 replies

5.

今日お話すること・話さないこと狙いは「設計概念を体系的に理解し、個々のパターンを把握するための助けとする」です 🚫セッションでは扱わない✨セッションで得られるこことと個々の設計パターンの詳細な解説具体的な実装方法やコード例の紹介特定のアーキテクチャの採用判断基準個別の設計パターンやアーキテクチャの詳細は、巻末の参考資料参照📚 設計に関する概念を体系的に理解する視点各設計概念の位置づけと相互の関係性設計概念の発展背景と解決してきた課題の理解

6.

見慣れた風景設計に関する用語が飛び交う日々 … このプロジェクトは Clean Architecture で…" "ここは ServiceLayer パターンを使って…" "SOLID の原則に従って設計しましょう" "マイクロサービスアーキテクチャに移行して…" ドキュメントやブログで目にするアーキテクチャやパターンの数々 "

7.

開発者の本音分かった気になっているけど … 具体的に何をすればいいの？この規模のプロジェクトに必要？いつ何を考えればいいの？設計の検討は早すぎ？遅すぎ？どの段階で決めるべき？既存のコードにどう適用する？トレードオフは何だろう？

8.

開発者の本音分かった気になっているけど … 具体的に何をすればいいの？この規模のプロジェクトに必要？いつ何を考えればいいの？設計の検討は早すぎ？遅すぎ？どの段階で決めるべき？既存のコードにどう適用する？トレードオフは何だろう？知識はあるのに、実践での判断に迷う

9.

ぜんぜんわからない 🤔

10.

俺達は雰囲気で（ry

11.

「雰囲気」の真意「雰囲気で設計」の現実ソフトウェア開発に正解はない要件は常に変化するチームごとに異なる制約があるビジネスの不確実性と向き合う時には直感や経験に基づく判断も必要完璧な情報収集は現実的でないスピードと質のバランスチームの力量と成長

12.

基礎となる原則を理解するなぜ体系的な理解が必要なのか？個別に学習・実践するには難易度が高すぎる新しい設計手法や考え方を次々と学ぶが、実践する機会がない表面的な理解に留まり、本質的な価値が掴めていない理想的な設計パターンやアーキテクチャの例を見ても、既存のプロジェクトにどう適用するか分からない様々な設計手法の中から、どれを選択すべきか判断できない各設計手法が生まれた背景や解決しようとした問題の理解が浅い概念は互いに関連しており、体系的に理解することで、より効果的に活用することができる概念の適用範囲や限界を理解し、状況に応じて適切な選択を行う為

13.

基礎となる原則を理解するなぜ体系的な理解が必要なのか？個別に学習・実践するには難易度が高すぎる新しい設計手法や考え方を次々と学ぶが、実践する機会がない表面的な理解に留まり、本質的な価値が掴めていない理想的な設計パターンやアーキテクチャの例を見ても、既存のプロジェクトにどう適用するか分からない様々な設計手法の中から、どれを選択すべきか判断できない各設計手法が生まれた背景や解決しようとした問題の理解が浅い概念は互いに関連しており、体系的に理解することで、より効果的に活用することができる概念の適用範囲や限界を理解し、状況に応じて適切な選択を行う為近道はない

14.

＿人人人人人＿＞救世主＜￣Y^Y^Y^Y^Y^￣

15.

「TECHNICAL MASTER はじめての PHP エンジニア入門編」年月発刊！ 2024 12 豪華執筆陣！

https://www.shuwasystem.co.jp/book/9784798073224.html

16.

「TECHNICAL MASTER はじめてのPHP エンジニア入門編」のおすすめ章本セッションとも関連が高くて気に入るはずです Chapter09: “ 設計原則とパターンこの章では、ソフトウェア開発における設計原則の重要性とアーキテクチャパターンの具体的な適用方法について詳しく解説します。まず、アーキテクチャの定義とその必要性を説明し、SOLID原則を通じて設計の基本概念を理解します。その後、さまざまなアーキテクチャパターン（MVC、レイヤードアーキテクチャ、クリーンアーキテクチャ、ヘキサゴナルアーキテクチャ）を紹介します。また、設計パターンとアンチパターンをとりあげ、実際の開発における適用例や回避すべき設計の落とし穴についても解説します。

https://www.shuwasystem.co.jp/book/9784798073224.html

17.

超絶オススメなので是非！きちんと学びたい＝学び直しにも

18.

設計概念の階層構造

19.

設計に関する用語の 3つのカテゴリ数多の用語がどういうカテゴリになるのか？〇〇の原則・法則 SOLID, KISS, YAGNI, DRY, 則 → 設計の原則〇〇パターン [1] コマンドクエリ分離原則(CQS) , デメテルの法則（最小知識の原則）,驚き最小の原 MVC, ActiveRecord, Value Object, Server Session State, Domain Model, CQRS → アーキテクチャパターン〇〇アーキテクチャ Layered, Clean, Hexagonal, Event Driven, Pipeline, Service Oriented → アーキテクチャスタイル 1. UNIX哲学 "Basics of the Unix Philosophy" の基本原則の一つ ↩︎

20.

設計原則等 SOLID, DRY 設計における普遍的な指針個々の判断の基準となる考え方文脈に依存しない基礎的なルール

21.

設計原則等 SOLID, DRY 設計における普遍的な指針個々の判断の基準となる考え方文脈に依存しない基礎的なルール最も具象的で個々のクラスやメソッドレベルの直接的な設計指針となる

22.

アーキテクチャパターン等 MVC, ActiveRecord 特定の問題に対する定型的な解決策複数の原則を組み合わせた実践的な手法文脈に応じて選択・適用する

23.

アーキテクチャパターン等 MVC, ActiveRecord 特定の問題に対する定型的な解決策複数の原則を組み合わせた実践的な手法文脈に応じて選択・適用する抽象度が中程度なモジュールやコンポーネントレベルの設計パターン

24.

デザインパターンとの違いパターンにも色々ある項目設計レベルパターン数適用範囲デザインパターン（GoF）クラス/オブジェクトの設計レベル 23個のパターンで完結言語非依存の解決策アーキテクチャパターンシステム構造レベル POSA 、PoEAA 、EIPで体系化エンタープライズアプリケーション特有 [1] [2] 1. Pattern-Oriented Software Architecture ↩︎ 2. Patterns of Enterprise Application Architecture ↩︎ 3. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions ↩︎ [3]

25.

アーキテクチャスタイル等 Layered, Event-Driven, Microservices システム全体の構造を定義する設計思想複数のパターンを包含する包括的な方針ビジネス要件と技術要件を橋渡しする

26.

アーキテクチャスタイル等 Layered, Event-Driven, Microservices システム全体の構造を定義する設計思想複数のパターンを包含する包括的な方針ビジネス要件と技術要件を橋渡しする最も抽象度が高く、システム全体の構造を決定する

27.

設計に関する 3つの概念カテゴリ比較抽象度が低→高、影響度も小→大となる項目適用範囲抽象度決定の影響設計原則メソッド/クラスレベルがメイン具象的（直接的な指針）局所的な影響アーキテクチャパターンモジュール/コンポーネントレベル中間（再利用可能な解決策）中規模な影響アーキテクチャスタイルシステム/アプリケーションレベル抽象的（全体的な方針）全体的な影響

28.

抽象度レベルピラミッド最も抽象的アーキテクチャスタイル全体的な⽅針アーキテクチャパターン再利⽤可能な解決策設計原則具象的・直接的な指針抽象度が低 → ⾼最も具象的

29.

抽象度レベルピラミッド最も抽象的アーキテクチャスタイル全体的な⽅針アーキテクチャパターン再利⽤可能な解決策設計原則具象的・直接的な指針抽象度が低 → ⾼抽象度の上昇に伴い、影響範囲が広がっていくスタイルは変更コストが高く、決定の重要度も高い最も具象的

30.

設計課題の解決領域

31.

設計原則の役割ソフトウェア開発の品質向上と効率化を目指す解決しようとした課題コードの重複等による保守性の低下変更の影響範囲が予測できないテストが困難チーム間での品質にばらつきがある目指すゴール一貫した設計基準を提供し、コードの品質を均一に保つ保守性を向上させ、長期的な維持管理を容易にする技術的負債を削減するチーム内のコミュニケーションを円滑にする

32.

設計原則の役割ソフトウェア開発の品質向上と効率化を目指す解決しようとした課題コードの複雑性大規模なソフトウェアシステムの複雑さを管理し、理解しやすく保守しやすいコードを作成する。 2. 変更への対応ビジネス要件の変更や技術の進歩に柔軟に対応できるシステムを設計する。 3. 品質の向上バグの少ない、信頼性の高いソフトウェアを開発するための指針が求められた。 4. 開発効率の改善開発時間の短縮と、チーム間のコミュニケーション改善が必要。 1. 主な目的コードの保守性向上 1. 再利用性の促進 3. 拡張性の確保 4. バグの減少 5. 開発効率の向上 2.

33.

設計原則の役割ソフトウェア開発の品質向上と効率化を目指す解決しようとした課題コードの複雑性大規模なソフトウェアシステムの複雑さを管理し、理解しやすく保守しやすいコードを作成する。 2. 変更への対応ビジネス要件の変更や技術の進歩に柔軟に対応できるシステムを設計する。 3. 品質の向上バグの少ない、信頼性の高いソフトウェアを開発するための指針が求められた。 4. 開発効率の改善開発時間の短縮と、チーム間のコミュニケーション改善が必要。 1. 主な目的コードの保守性向上 1. 再利用性の促進 3. 拡張性の確保 4. バグの減少 5. 開発効率の向上 2. 変更に強く理解しやすいコードにする変更容易性と理解容易性を高くする

34.

設計原則による課題解決マトリクス原則での課題解決事例 SOLID 課題単一責任原則オープン/クローズドリスコフの置換原則インターフェース依存性逆転原則（SRP）原則（OCP）（LSP）分離原則（ISP）（DIP）コードクラスの目的継承やポリモーフィの複雑を明確化ズムを活用性変更へ変更理由の一新機能追加時に既存の対応つに限定コードを変更しない品質向高凝集を実現変更影響範囲の最小上化一貫した振る舞いの必要な機能だけを抽象化と依存関提供提供係の最小化クライアントコードインターフェース依存関係の逆転の変更を最小限にの分離による柔軟性クライアントコード高凝集のインターモジュール間のとの結合を維持フェース独立性向上

35.

アーキテクチャパターンの役割複雑化するエンタープライズアプリケーションの設計と統合における共通課題に対処するための体系化解決しようとした課題似たような問題を何度も解決している設計ノウハウが共有されない実装方法の選択に時間がかかるチーム間で実装方法がバラバラ目指すゴール再利用可能な設計手法を提供し、効率的な開発を実現する設計の標準化と一貫性を確保するチーム間のコミュニケーションを促進する

36.

アーキテクチャパターンの役割複雑化するエンタープライズアプリケーションの設計と統合における共通課題に対処するための体系化解決しようとした課題複雑性の管理大規模エンタープライズアプリケーションの複雑さを管理し、理解しやすく保守しやすいシステムを設計する必要。 2. 再利用性の向上共通のパターンを識別し、再利用可能なソリューションを提供することで、開発効率を向上させる必要。 3. システム統合の複雑さ異なるシステム間の統合が複雑化し、標準化されたアプローチが必要。 1. 主な目的（ PoEAA Patterns of Enterprise Application ） 1. エンタープライズアプリケーションの設計に関する知識の体系化 2. 複雑なビジネスロジックとデータ処理の効率的な実装方法の提供 3. スケーラブルで保守性の高いアプリケーション構築のための指針提供 EIP（Enterprise Integration Patterns） 1. 分散システム間の統合パターンの標準化 2. メッセージングシステムを使用した効果的な統合方法の提供 Architecture

37.

アーキテクチャパターンの役割複雑化するエンタープライズアプリケーションの設計と統合における共通課題に対処するための体系化解決しようとした課題複雑性の管理大規模エンタープライズアプリケーションの複雑さを管理し、理解しやすく保守しやすいシステムを設計する必要。 2. 再利用性の向上共通のパターンを識別し、再利用可能なソリューションを提供することで、開発効率を向上させる必要。 3. システム統合の複雑さ異なるシステム間の統合が複雑化し、標準化されたアプローチが必要。 1. 主な目的（ PoEAA Patterns of Enterprise Application ） 1. エンタープライズアプリケーションの設計に関する知識の体系化 2. 複雑なビジネスロジックとデータ処理の効率的な実装方法の提供 3. スケーラブルで保守性の高いアプリケーション構築のための指針提供 EIP（Enterprise Integration Patterns） 1. 分散システム間の統合パターンの標準化 2. メッセージングシステムを使用した効果的な統合方法の提供 Architecture

38.

アーキテクチャスタイルの役割ソフトウェアシステムの複雑化と多様化が大きく影響して発展解決しようとした課題システム全体の一貫性が保てないスケーラビリティの要件に対応できないチーム間の連携が困難長期的な進化が難しい目指すゴールシステム全体の構造を決定し、一貫した設計を提供するスケーラビリティを確保し、システムの成長に対応するチーム間の協調とコミュニケーションを促進する長期的なシステムの進化を支援する

39.

アーキテクチャスタイルの役割ソフトウェアシステムの複雑化と多様化が大きく影響して発展解決しようとした課題システム全体の複雑性管理大規模システムの全体構造を簡素化し、理解しやすくする必要。 2. スケーラビリティとパフォーマンスの最適化システム全体のスケーラビリティを向上させ、大規模なデータ処理や高負荷に対応する必要。 3. 分散システムの課題への対応ネットワーク遅延、部分的な障害、データの一貫性など、分散システム特有の問題に対処する必要。 4. 異種システム間の統合異なる技術や標準を使用するシステム間の効果的な統合方法が求められた。 1. 主な目的システムの全体的な構造を定義 2. コンポーネント間の関係を明確にする 3. アーキテクチャ特性をカバーする 4. 経験豊富なアーキテクト間の共通言語として機能する 5. システムの品質属性（パフォーマンス、スケーラビリティ、セキュリティなど）を達成する 6. コンポーネントや機能の再利用性を向上させる 7. システム内のコンポーネントや外部システムとの統合を容易にする 8. 将来的な変更や拡張に対する柔軟性を確保する 1.

40.

アーキテクチャスタイルの役割ソフトウェアシステムの複雑化と多様化が大きく影響して発展解決しようとした課題システム全体の複雑性管理大規模システムの全体構造を簡素化し、理解しやすくする必要。 2. スケーラビリティとパフォーマンスの最適化システム全体のスケーラビリティを向上させ、大規模なデータ処理や高負荷に対応する必要。 3. 分散システムの課題への対応ネットワーク遅延、部分的な障害、データの一貫性など、分散システム特有の問題に対処する必要。 4. 異種システム間の統合異なる技術や標準を使用するシステム間の効果的な統合方法が求められた。 1. 主な目的システムの全体的な構造を定義 2. コンポーネント間の関係を明確にする 3. アーキテクチャ特性をカバーする 4. 経験豊富なアーキテクト間の共通言語として機能する 5. システムの品質属性（パフォーマンス、スケーラビリティ、セキュリティなど）を達成する 6. コンポーネントや機能の再利用性を向上させる 7. システム内のコンポーネントや外部システムとの統合を容易にする 8. 将来的な変更や拡張に対する柔軟性を確保する 1.

41.

相互補完の効果各概念は独立ではなく、相互に補完役割・効果設計原則アーキテクチャパターンアーキテクチャスタイル - モジュール構造の一貫性 - システム全体の整合性品質の確保 -- コードの品質基準変更容易性の確保 - 再利用性の向上 - 長期的な保守性 - コンポーネントの実装方針 - システム構造の大枠決定実装の指針 -- 具体的な実装の判断基準コードレベルの品質確保 - インターフェースの定義 - 主要コンポーネントの特定 - モジュール単位の変更管理 - 大規模な変更の制御変更への対応 -- 局所的な変更の容易さテスタビリティの確保 - 依存関係の制御 - 進化の方向性の提供

42.

相互補完の効果各概念は独立ではなく、相互に補完役割・効果設計原則アーキテクチャパターンアーキテクチャスタイル - モジュール構造の一貫性 - システム全体の整合性品質の確保 -- コードの品質基準変更容易性の確保 - 再利用性の向上 - 長期的な保守性 - コンポーネントの実装方針 - システム構造の大枠決定実装の指針 -- 具体的な実装の判断基準コードレベルの品質確保 - インターフェースの定義 - 主要コンポーネントの特定 - モジュール単位の変更管理 - 大規模な変更の制御変更への対応 -- 局所的な変更の容易さテスタビリティの確保 - 依存関係の制御 - 進化の方向性の提供協調して機能することで、より堅牢で適応性の高いソフトウェア設計が可能

43.

ボトムアップの重要性下位の概念が上位の品質を支える補完関係により以下を実現一貫性のある設計判断が可能に各レベルでの品質確保変更に強いシステムの実現長期的な保守性の向上

44.

ボトムアップの重要性下位の概念が上位の品質を支える補完関係により以下を実現一貫性のある設計判断が可能に各レベルでの品質確保変更に強いシステムの実現長期的な保守性の向上組み合わせにより実用的な設計を実現

45.

設計概念の歴史的発展なぜこれらの設計概念が生まれて来たのか？

46.

年代ハードウェア依存時代 1960-1970 : 設計原則の萌芽構造化プログラミングの登場モジュール化、カプセル化の概念確立ソフトウェアの複雑性に対する初期の対応

47.

年代パッケージソフトウェアの台頭 1980-1990 : 原則の体系化とパターンの出現【設計原則の確立】 1988: CRC（Class-Responsibility-Collaboration） 1995: SOLID 原則（Robert C. Martin） 1999: DRY, YAGNI 等の原則【デザインパターンの体系化】 1987: Kent Beck & Ward Cunningham がパターン言語を提唱 1994: GoF 本「Design Patterns」出版オブジェクト指向設計の知見を集約

48.

年代：サービスの時代 2000 SaaS/Web エンタープライズパターンの体系化【アーキテクチャパターンの整理】 1996〜2009: Pattern-Oriented Software Architecture（POSA）シリーズ広範なシステムアーキテクチャパターンを扱う [1] 2002: Patterns of Enterprise Application Architecture (PoEAA) エンタープライズアプリケーションの知見集約 2004: Enterprise Integration Patterns(EIP) [2] システム統合のパターン化 1. 基本的なアーキテクチャパターンから始まり、分散コンピューティングからリソース管理、パターン言語まで幅広いトピックをカバーしています ↩︎ 2. アーキテクチャパターンのカタログとしてまとめられています ↩︎

#p19
#p24

49.

年代以降：クラウドネイティブ時代 2010 アーキテクチャスタイルの進化マイクロサービスイベント駆動アーキテクチャサーバーレスアーキテクチャ

50.

年代以降：クラウドネイティブ時代 2010 アーキテクチャスタイルの進化マイクロサービスイベント駆動アーキテクチャサーバーレスアーキテクチャクラウド時代の新たな課題に対応続々とXXXアーキテクチャが出現してくる

51.

ソフトウェアの形態と開発スタイルの変遷

52.

年代：ハードウェア依存時代 1960-1970 専用ハードウェアでのみ動作する組み込み型システムを、少人数でウォーターフォール型の開発で作り上げる時代【ソフトウェアの形態】メインフレーム専用のソフトウェア顧客固有のカスタムシステムハードウェアの付属品的な位置づけ【開発スタイル】ウォーターフォール型少人数での開発ハードウェア仕様に強く依存

53.

年代：ハードウェア依存時代 1960-1970 専用ハードウェアでのみ動作する組み込み型システムを、少人数でウォーターフォール型の開発で作り上げる時代【ソフトウェアの形態】メインフレーム専用のソフトウェア顧客固有のカスタムシステムハードウェアの付属品的な位置づけ【開発スタイル】ウォーターフォール型少人数での開発ハードウェア仕様に強く依存利用形態が限定的。ワンオフで作りきり、修正ができない

54.

年代：パッケージソフトウェアの台頭 1980 各 PC にインストールして利用するパッケージを、バージョン管理とリリース計画に基づくチーム開発で進める時代【ソフトウェアの形態】パッケージソフトウェアクライアント/サーバーシステム汎用的な業務アプリケーション【開発スタイル】複数バージョンの管理チーム開発の一般化品質管理プロセスの確立

55.

年代：パッケージソフトウェアの台頭 1980 各 PC にインストールして利用するパッケージを、バージョン管理とリリース計画に基づくチーム開発で進める時代【ソフトウェアの形態】パッケージソフトウェアクライアント/サーバーシステム汎用的な業務アプリケーション【開発スタイル】複数バージョンの管理チーム開発の一般化品質管理プロセスの確立利用形態が多様化。ソフトウェアも大規模化する。開発スタイルも複雑化。

56.

年代：エンタープライズ化 1990 大規模な業務システムをコンポーネント単位で開発・カスタマイズし、組織全体に展開する反復型開発の時代【ソフトウェアの形態】エンタープライズパッケージ Web ベースの ERP/CRM カスタマイズ可能なプラットフォーム【開発スタイル】コンポーネントベース開発反復型開発の導入グローバル開発チーム

57.

年代：エンタープライズ化 1990 大規模な業務システムをコンポーネント単位で開発・カスタマイズし、組織全体に展開する反復型開発の時代【ソフトウェアの形態】エンタープライズパッケージ Web ベースの ERP/CRM カスタマイズ可能なプラットフォーム【開発スタイル】コンポーネントベース開発反復型開発の導入グローバル開発チームパッケージソフトウェア時代からSaaS時代への重要な過渡期カスタイマイズも入り、システムに求められる要件も高度化

58.

年代：サービスの時代 2000 SaaS/Web ブラウザを通じて継続的に進化するサービスを、アジャイル開発による迅速な機能改善で実現する時代【ソフトウェアの形態】 SaaS モデル Web アプリケーションサブスクリプションベース【開発スタイル】アジャイル開発継続的デリバリーフィーチャー単位の開発

59.

年代：サービスの時代 2000 SaaS/Web ブラウザを通じて継続的に進化するサービスを、アジャイル開発による迅速な機能改善で実現する時代【ソフトウェアの形態】 SaaS モデル Web アプリケーションサブスクリプションベース【開発スタイル】アジャイル開発継続的デリバリーフィーチャー単位の開発の普及新興のWebアプリケーションフレームワークがたくさん生まれた Ruby on Rails

60.

年代以降：クラウドネイティブ時代 2010 クラウド上のサービス群を組み合わせて利用するシステムを、DevOps による自動化と分散開発で構築する時代【ソフトウェアの形態】クラウドネイティブアプリケーションマイクロサービス API エコノミー【開発スタイル】 DevOps コンテナベース開発インフラのコード化

61.

年代以降：クラウドネイティブ時代 2010 クラウド上のサービス群を組み合わせて利用するシステムを、DevOps による自動化と分散開発で構築する時代【ソフトウェアの形態】クラウドネイティブアプリケーションマイクロサービス API エコノミー【開発スタイル】 DevOps コンテナベース開発インフラのコード化インフラのコード化モバイルアプリ化や、Single Page Applicationも台頭してきた

62.

変化の本質変化のまとめ変化の方向性提供形態開発スタイルチーム構造アーキテクチャパッケージソフトウェア時代パッケージ販売ウォーターフォール少人数チームモノリシックサービス時代サブスクリプション反復型/アジャイル大規模チームコンポーネントベース SaaS/Web クラウドネイティブ時代従量課金/サービス連携継続的デリバリー分散自律チームマイクロサービス

63.

ソフトウェア開発の進化 1960-1970 1980 2000 以降 2010 ハードウェア依存時代 💻 パッケージソフトウェア 📦💻🖥 サービス 🌐🔗💡 🌈☁🔬🚀🌍 専⽤システム汎⽤的なアプリケーション分散・接続型サービスグローバル・柔軟なシステム SaaS/Web クラウドネイティブメインフレーム専⽤カスタムシステムハードウェア依存パッケージソフトウェアクライアント/サーバーシステム複数バージョン管理 Webアプリケーションサブスクリプションモデル継続的デリバリーマイクロサービスコンテナ・サーバーレス DevOps・継続的統合

64.

ソフトウェア開発の進化 1960-1970 1980 2000 以降 2010 ハードウェア依存時代 💻 パッケージソフトウェア 📦💻🖥 サービス 🌐🔗💡 🌈☁🔬🚀🌍 専⽤システム汎⽤的なアプリケーション分散・接続型サービスグローバル・柔軟なシステム SaaS/Web クラウドネイティブメインフレーム専⽤カスタムシステムハードウェア依存パッケージソフトウェアクライアント/サーバーシステム複数バージョン管理 Webアプリケーションサブスクリプションモデル継続的デリバリーマイクロサービスコンテナ・サーバーレス DevOps・継続的統合ソフトウェアはよりリッチで大規模化する考慮する要素も増え、複雑さが増し、開発の難易度も高まり続けている

65.

変化の方向性これらの変化に対応するため、設計概念も領域が拡大するビジネスモデルの変化一時販売 → 継続的な収益カスタマイズ → セルフサービスクローズド → オープン連携 2. 開発プロセスの変化長期計画 → 短期サイクル品質保証 → 継続的改善固定要件 → 柔軟な適応 3. 技術的な変化密結合 → 疎結合単一障害点 → 分散システム手動運用 → 自動化 1.

66.

なんで変化していったの？🤔

67.

ビジネスや環境の変化に追従するため📈 現在のソフトウェア開発と似ていませんか？

68.

変化し続けるものを作り続けている🛠️ 設計概念もその中で生み出された

69.

目的も同じ🎯 ビジネスの変化に追従できるソフトウェア設計が求められる

70.

大きな泥団子を作っている場合ではない茹でガエルになってはいけない

71.

大きな泥団子 Big ball of mud 明確なアーキテクチャや設計思想がなく、場当たり的に継ぎ足し修正を繰り返した結果、まるで泥団子のように内部構造が複雑に入り組んでしまったソフトウェアシステムのこと【特徴】理解困難: システム全体の構造が把握しにくく、一部を修正するだけでも全体に影響が及ぶため、変更や機能追加が困難保守性の低下: コードが整理されておらず、可読性が低いため、バグが発生しやすく、修正にも時間がかかる技術的負債の蓄積: 場当たり的な修正を繰り返すことで、システムの内部構造がますます複雑化し、長期的な開発効率を著しく低下させる「技術的負債」が蓄積する

72.

実践的なアプローチ

73.

いつ、何を考えるか？💭

74.

設計原則

75.

常に意識し続けるもの🧠

76.

常に意識し続けるもの🧠

77.

設計原則常に意識し続けるものコーディング時の判断基準レビュー時の評価基準リファクタリングの指針新規コード作成時のガイドライン

78.

アーキテクチャパターン

79.

フレームワーク全盛時代にイチから考えることは少ない🧩

80.

アーキテクチャパターンは戦術的に扱う 🏗️ 既に誰かが通ってきた道

81.

アーキテクチャパターンは戦術的に扱う 🏗️ 既に誰かが通ってきた道

82.

フレームワーク選定時に概ね決まる☑️

83.

アーキテクチャパターンフレームワーク選定時に概ね決まる問題解決のためのツールボックスとして捉える過去の経験から得られた成功事例に基づいて体系化されている。実践的な知識として活用 MVC パターンはフルスタックフレームワークなら大体ある Laravel なら ActiveRecord パターン（Eloquent） Symfony なら Data Mapper パターン（Doctrine）必要に応じて取捨選択フレームワークを薄く使う

84.

アーキテクチャスタイル

85.

アーキテクチャスタイルは戦略的に扱う 💡 戦略は各システム・ビジネスの事情から生まれるもの

86.

アーキテクチャスタイルは戦略的に扱う 💡 戦略は各システム・ビジネスの事情から生まれるもの

87.

判断が一番むずかしい😵‍💫 なぜなら最も抽象度が高い設計判断になる。決定の影響が全体に及ぶ為

88.

理想は「僕が考えた最強のアーキテクチャ」を考え抜いて作り込むこと💪 オレオレアーキテクチャを熟成したものがスタイルになる

89.

但し、プロジェクト初期は過度に目指さない！⚖️ コアドメインの見極めが重要

90.

原則ベースの継続的改善していくのがいいのでは？🧭

91.

Takuto Wada @t_wada · Follow "「クリーンアーキテクチャみたいなやつ」は最初から目指すのではなくて、原理原則ベースでリファクタリングしていくと次第に近づいていくもの" これが伝わって欲しい

92.

一つの事例

93.

段階的にリアーキテクチャしたお話サービス間でもが適用できる！ DIP

94.

記事を通して伝えたいこと今回は時間の都合ですべてはお話できませんアーキテクチャはフラクタル構造を持つ同じパターンが異なる粒度で繰り返し現れるシステムは階層的に構成されるアプリケーション、パッケージ、コンポーネント、クラス、関数、式、文各レイヤーには構造とアーキテクチャがあり、SOLID 原則が適用可能設計原則という基礎から、必然的にアーキテクチャが導かれる

95.

記事を通して伝えたいこと今回は時間の都合ですべてはお話できませんアーキテクチャはフラクタル構造を持つ同じパターンが異なる粒度で繰り返し現れるシステムは階層的に構成されるアプリケーション、パッケージ、コンポーネント、クラス、関数、式、文各レイヤーには構造とアーキテクチャがあり、SOLID 原則が適用可能設計原則という基礎から、必然的にアーキテクチャが導かれる

96.

アーキテクチャスタイルはいつ考えるべきか？組織ビジネスの転換点で検討する / 【タイミング】【アプローチ方法】チーム規模の拡大時小規模な時は設計原則に集中チーム間の責務分離が必要に必要なタイミングで戦略的に判断独立したデプロイの必要性ビジネスの成長に合わせた漸進的な改善ビジネス要件の変化時スケーラビリティ要件の変化新規ドメインの追加（新規プロジェクト立ち上げ時も）リファクタリングの契機技術的負債の蓄積。保守性の課題

97.

アーキテクチャスタイルはいつ考えるべきか？組織ビジネスの転換点で検討する / 【タイミング】【アプローチ方法】チーム規模の拡大時小規模な時は設計原則に集中チーム間の責務分離が必要に必要なタイミングで戦略的に判断独立したデプロイの必要性ビジネスの成長に合わせた漸進的な改善ビジネス要件の変化時オーバーエンジニアリングを避け、必要なスケーラビリティ要件の変化新規ドメインの追加（新規プロジェクト立ち上げ時タイミングで適切な投資判断チームの成長を考慮した判断を行うも）リファクタリングの契機技術的負債の蓄積。保守性の課題

98.

設計概念の向き合い方今回一番伝えたいこと【ボトムアップの重要性】設計原則という最も具象的な概念が基礎原則の理解と実践が、より大きな設計の質を支える基礎なしには、上位の概念も形骸化する【アーキテクチャはフラクタル構造】同じ設計原則が異なる粒度で現れるシステムの規模に関係なく、同じ原則が品質を支える

99.

設計概念の向き合い方今回一番伝えたいこと【ボトムアップの重要性】設計原則という最も具象的な概念が基礎原則の理解と実践が、より大きな設計の質を支える基礎なしには、上位の概念も形骸化する【アーキテクチャはフラクタル構造】同じ設計原則が異なる粒度で現れるシステムの規模に関係なく、同じ原則が品質を支える原則の深い理解がパターンやスタイルの適切な選択につながるアーキテクチャスタイルを自然な帰結として捉える

100.

まとめ

101.

設計概念を実践で活かすために相互関係性を理解し、バランスよく組み合わせる設計原則を基礎として日々のコーディングやレビューでの判断基準として活用チーム内での共通言語として定着させる継続的な改善の指針として活用アーキテクチャは段階的に小規模なうちは原則に集中ビジネスの成長に合わせて発展必要なタイミングで戦略的に判断

102.

継続的な進化のためにアーキテクチャスタイルはシステム全体の構造やコード配置の設計指針となる実践のポイント完璧な設計を目指すのではなく、変化に強い設計を目指すオーバーエンジニアリングを避け、必要に応じて段階的に改善チームの理解度とビジネスの要件をバランス Key Message 設計原則という基礎が、より大きな設計の質を支えるアーキテクチャは自然な帰結として導かれるもの実践を通じた継続的な学びと改善を心がける

103.

進化的アーキテクチャとなる変化を前提としたシステム設計のアプローチ継続的な改善と発展アーキテクチャスタイル全体的な⽅針アーキテクチャパターン再利⽤可能な解決策設計原則具象的・直接的な指針抽象度

104.

進化的アーキテクチャとなる変化を前提としたシステム設計のアプローチ継続的な改善と発展アーキテクチャスタイル全体的な⽅針アーキテクチャパターン再利⽤可能な解決策設計原則具象的・直接的な指針らせん状に進化するイメージ抽象度

105.

付録

106.

参考資料 & 書籍紹介した書籍や、学習に使えるページ【書籍】「TECHNICAL MASTER はじめてのPHP エンジニア入門編」 Pattern-Oriented Software Architecture Patterns of Enterprise Application Architecture Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions 【資料】 Patterns of Enterprise Application Architecture - Martin Fowler’s Bliki (ja) Table of Contents - Enterprise Integration Patterns

107.

ご清聴ありがとうございました

設計原則、アーキテクチャパターン、アーキテクチャスタイルの違いって何？いつどう向き合ったらいいの？を考えてみる

katzumi

関連スライド

ActiveRecordパターンの呪縛を学びほぐして挑むクリーンアーキテクチャへの入り口

リリース戦略を支えるCI/CDパイプライン

APIシナリオテストを書くべき10の理由

クリーアーキテクチャでのアンチパターン

実装と乖離させないスキーマ駆動開発フロー / OpenAPI Laravel編

APIテストでもカバレッジ測定したい！

各ページのテキスト