Domain Driven Design #Software Design ドメイン（事業領域）ファーストでプロダクト設計を行う考え方 エリック・エヴァンスのドメイン駆動設計にて初めて紹介された

#Blog #Software Design Martin FowlerによるDependency Injectionの概念を定義した記念碑的な記事（2004年1月23日公開） 背景 それまで軽量コンテナフレームワークは「Inversion of Control（IoC）」という用語で説明されていたが、Fowlerは「IoCはフレームワークの一般的な特性であり包括的すぎて混乱を招く」と指摘。IoC推進者との議論を経て、より具体的な「Dependency Injection」という用語を作成した 主な内容 DIの定義：別のオブジェクト（アセンブラ）が、クラスのフィールドに適切な実装を注入するアプローチ。サービス構成の責任と使用の責任を分離する 3つの実装パターン： Constructor Injection（コンストラクタ注入）：PicoContainerで採用。オブジェクト生成時に依存関係を明示 Setter Injection（セッター注入）：Spring Frameworkで採用。初期化後に依存関係を設定 Interface Injection（インターフェース注入）：Avalonで使用。注入用インターフェースを実装 影響 この記事により「Dependency Injection」という用語が確立され、以降のフレームワーク設計やソフトウェアアーキテクチャに大きな影響を与えた。Spring Frameworkも当初は「IoC」を使用していたが、後に「DI」という用語を採用 https://martinfowler.com/articles/injection.html 日本語訳：https://kakutani.com/trans/fowler/injection.html

#Software Design Single responsibility principle Open/Closed principle Liskov substitution principle Interface segmentation principle Dependency inversion principle の頭文字を取った原則。オブジェクト指向プログラミングの文脈で語られる 2000年にRobert C. Martinによって原則群が発表された

#Software Design #モジュラモノリス #ドメイン駆動設計 参考 Shopifyはいかにしてモジュラモノリスへ移行したか

#Software Design #Martin Fowler Patterns of Enterprise Application Architecture https://speakerdeck.com/dnskimo/pofeaadekao-erusaasbatukuendofalsezuo-rifang

#Software Design #Team Organization コンウェイの法則に対して、開発チームの組織構造を変更して、望ましいソフトウェア設計を目指すという考え方 マイクロサービスが注目されるようになった2015年頃にコンウェイの法則が再評価され生まれた

#Software Design #API Architecture DDDにおける境界づけられたコンテキストに対応する形でサービスを用意し、サービス間通信を行う設計パターン マイクロという名前の通り、サービスインターフェースが小さく疎結合になっていて各サービスの責務が凝集されていることが望ましい

#Software Design #Cloud Native The Twelve-Factor Appを現代のクラウドネイティブ環境向けに拡張した方法論。Kevin Hoffmanによって著され、オリジナルの12要因を15要因に拡張している。 追加された3つの新要因 2. API First - サービス設計において、実装前にAPIインターフェースを定義し契約駆動開発を促進 API Architecture 14. Telemetry - メトリクス、ログ、トレースの収集を通じた包括的な監視機能 Observability 15. Authentication and Authorization - 認証・認可をアプリケーション設計の第一級の関心事として組み込む Authentication Authorization 既存要因の改訂 Kubernetes ConfigMap/Secretsなどコンテナ時代の設定管理や、Infrastructure as Code（IaC）による環境構築など、現代的なベストプラクティスを反映した注釈が追加されている。 https://www.vmware.com/docs/ebook-beyond-the-12-factor-app

#Software Design 境界づけられたコンテキスト DDDにおいて、集約（モジュール）の集合に対して定めるドメインモデリング上の境界 以下、原著から抽出 モデルが適用されるコンテキストを明示的に定義すること。明示的な境界は、チーム編成、そのアプリケーションに特有の部分が持つ用途、コードベースやデータベーススキーマなどの物理的な表現などの観点から設定すること。その境界内では、モデルを厳密に一貫性のあるものに保つこと。ただし、境界の外部の問題によって注意を逸らされたり、混乱させられたりするのを避けること。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P344

#Software Design SOLID原則の1つであり、オブジェクト指向プログラミングにおける一般的なプラクティス コードの部品は1つだけのことを行い、他のことは行ってはならないということ

Authors Dan North, 和智 右桂 #Blog #BDD #ドメイン駆動設計 #Software Design Blog

#Greg Young #Software Design #CQRS pdf

#Documentation #Software Design DDDにおいて、ドメインエキスパートと開発者、またその周辺のステークホルダーが共有する言語 以下、原著から抽出 モデルを言語の骨格として使用すること。チーム内のすべてのコミュニケーションとコードにおいて、その言語を厳格に用いることを、チームに約束させること。図やドキュメント、そして何より会話の中では同一の言語を使用すること。 ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり、開発者は、設計を妨害することになるあいまいさや不整合に目を光らせるべきである。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P26-27 また同一の単語でも異なるユビキタス言語として定義するケースもあり、境界づけられたコンテキストを明示にした上で、どのコンテキストで用いる言語なのかを決定する

#オブジェクト指向プログラミング #Programming #Software Design 契約による設計事始め

Object Oriented Programming #Software Design #Programming

#Blog #Software Design #Team Organization コンウェイの法則についてMartin Fowlerが書いたブログ 逆コンウェイ戦略やDDDとの関連についても触れている https://martinfowler.com/bliki/ConwaysLaw.html

#Blog #Software Design Martin Fowlerが2015年に書いたブログ 当時過熱していたマイクロサービス化ブームに警鐘を鳴らす形で、全てのケースにマイクロサービスが適するわけではない点が示された https://martinfowler.com/bliki/MicroservicePremium.html

#Blog #Software Design マイクロサービスについてMartin Fowler,James Lewisが2014年に書いたブログ マイクロサービスの9つの特徴について説明している https://martinfowler.com/articles/microservices.html

#Software Design DDDの境界づけられたコンテキストの概念に従って、モノリス内で明確に境界が分かれたコンテキストをそれぞれモジュール化する 例としてコンテキスト間のI/FはProtocol Buffersにて定義し、ヘキサゴナルアーキテクチャにおけるアダプタ層のみ公開することで、境界を跨いだ依存解決を許さない等の方法がある

#Software Design Microservicesのブログの中で説明されたマイクロサービスについての9つの特徴 9つの特徴 1. Componentization via Services（サービスによるコンポーネント化） - サービスを独立してデプロイ・置き換え可能なソフトウェアユニットとして扱う 2. Organized around Business Capabilities（ビジネス機能による組織化） - 技術層ではなくビジネス能力を中心にチームを編成し、UIからデータベースまで一つのチームが担当する 3. Products not Projects（プロジェクトではなくプロダクト志向） - “開発したものを自分たちで運用する“という哲学のもと、チームが長期的責任を持つ 4. Smart endpoints and dumb pipes（スマートエンドポイント、ダムパイプ） - 複雑なロジックはサービス内に置き、通信機構（HTTP、メッセージング）はシンプルに保つ 5. Decentralized Governance（分散ガバナンス） - 各チームが独立してプログラミング言語やデータベース技術を選択でき、中央集約的な標準化を避ける 6. Decentralized Data Management（分散データ管理） - 各サービスが独自のデータベースを管理し、結果整合性を活用する 7. Infrastructure Automation（インフラストラクチャ自動化） - 継続的デリバリーと自動デプロイメントを支援するツールやパイプラインへの投資を重視する 8. Design for failure（障害設計） - サービス障害に対応するため、回路ブレーカーパターンなどを使い、システムの耐障害性を確保する 9. Evolutionary Design（進化的設計） - サービス境界は変更時の複雑さに基づいて設定され、時間とともに柔軟に調整される想定で設計する

#Software Design DDDにおいて不変条件を適用するエンティティや値オブジェクトのようなオブジェクトのグループ単位 原文は以下 エンティティと値オブジェクトを集約の中にまとめ、各集約の周囲に境界を定義すること。各集約に対してルートとなるエンティティを1つ選び、境界の内部に存在するオブジェクトへのアクセスはそのルートを経由して制御すること。外部のオブジェクトが参照を保持できるのは、ルートのみとすること。内部のメンバに対する一時的な参照を渡してよいのは、単一の操作で使用する時だけだ。ルートがアクセスを制御するので、内部が知らないうちに変更されることはなくなる。この取り決めにより、どんな状態変化においても、集約内にあるオブジェクトと集約全体に対して、不変条件をすべて強制することが現実的になる。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P127

#Software Design DDDにおいて同一性を持つオブジェクトの呼び名 原文は以下 オブジェクトの中には、主要な定義が属性によってなされないものもある。そういうオブジェクトは同一性のつながりを表現するのであり、その同一性は、時間が経っても、異なるかたちで表現されても変わらない。そういうオブジェクトは属性が異なっていても、他のオブジェクトと一致しなければならないことがある。また、あるオブジェクトは、同じ属性を持っていたとしても、他のオブジェクトと区別しなければならない。同一性を取り違えるとデータの破損につながりかねない。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P89

#Software Design #Programming オブジェクトやコンポーネントの依存関係を外部から注入する設計パターン クラスが必要とする依存オブジェクトを自身で生成せず、外部のアセンブラ（DIコンテナなど）から提供される。これにより、クラス間の結合度が低下し、テスト容易性、柔軟性、再利用性が向上する

#Software Design 特に結合度と凝集度について参考になる研修資料 キーワード 技術的負債 クリーンアーキテクチャ

#Software Design DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Loosely coupled teams

#Software Design DevOps capabilitiesの1つ、Climate for Learningに分類される 仕事の満足度に寄与し、ツールやテクノロジーをチームに強制するとチームによる実験が制限されてしまう DORA | Capabilities: Empowering teams to choose tools

#Software Design #成瀬 允宣 クリーンアーキテクチャを実装レベルで実践するドキュメント 実践クリーンアーキテクチャ │ nrslib