Software Design
-
ドメイン駆動設計Domain Driven Design #Software Design ドメイン(事業領域)ファーストでプロダクト設計を行う考え方 エリック・エヴァンスのドメイン駆動設計にて初めて紹介された
-
オブジェクト指向入門 第2版 原則・コンセプト
-
マスタリングAPIアーキテクチャ
-
SOLID#Software Design Single responsibility principle Open/Closed principle Liskov substitution principle Interface segmentation principle Dependency inversion principle の頭文字を取った原則。オブジェクト指向プログラミングの文脈で語られる 2000年にRobert C. Martinによって原則群が発表された
-
モジュラモノリスで表現する複雑なドメイン領域と境界#Software Design #モジュラモノリス #ドメイン駆動設計 参考 Shopifyはいかにしてモジュラモノリスへ移行したか
-
オニオンアーキテクチャ
-
PofEAA#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 境界づけられたコンテキスト DDDにおいて、集約(モジュール)の集合に対して定めるドメインモデリング上の境界 以下、原著から抽出 モデルが適用されるコンテキストを明示的に定義すること。明示的な境界は、チーム編成、そのアプリケーションに特有の部分が持つ用途、コードベースやデータベーススキーマなどの物理的な表現などの観点から設定すること。その境界内では、モデルを厳密に一貫性のあるものに保つこと。ただし、境界の外部の問題によって注意を逸らされたり、混乱させられたりするのを避けること。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P344
-
単一責任の原則#Software Design SOLID原則の1つであり、オブジェクト指向プログラミングにおける一般的なプラクティス コードの部品は1つだけのことを行い、他のことは行ってはならないということ
-
BDDとDDDAuthors: Dan North, 和智 右桂 #BDD #ドメイン駆動設計 #Software Design Blog
-
CQRS Documents by Greg Young#Greg Young #Software Design #CQRS pdf
-
ユビキタス言語#Documentation #Software Design DDDにおいて、ドメインエキスパートと開発者、またその周辺のステークホルダーが共有する言語 以下、原著から抽出 モデルを言語の骨格として使用すること。チーム内のすべてのコミュニケーションとコードにおいて、その言語を厳格に用いることを、チームに約束させること。図やドキュメント、そして何より会話の中では同一の言語を使用すること。 ドメインエキスパートは、ドメインについての理解を伝えるには使いにくかったり不適切だったりする用語や構造に異議を唱えるべきであり、開発者は、設計を妨害することになるあいまいさや不整合に目を光らせるべきである。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P26-27 また同一の単語でも異なるユビキタス言語として定義するケースもあり、境界づけられたコンテキストを明示にした上で、どのコンテキストで用いる言語なのかを決定する
-
契約による設計#オブジェクト指向プログラミング #Programming #Software Design 契約による設計事始め
-
オブジェクト指向プログラミングObject Oriented Programming #Software Design #Programming
-
モノリスからマイクロサービスへ
-
Blog/Conway's Law#Software Design #Team Organization コンウェイの法則についてMartin Fowlerが書いたブログ 逆コンウェイ戦略やDDDとの関連についても触れている https://martinfowler.com/bliki/ConwaysLaw.html
-
Blog/Microservice Premium#Software Design Martin Fowlerが2015年に書いたブログ 当時過熱していたマイクロサービス化ブームに警鐘を鳴らす形で、全てのケースにマイクロサービスが適するわけではない点が示された https://martinfowler.com/bliki/MicroservicePremium.html
-
Blog/Microservices#Software Design マイクロサービスについてMartin Fowler,James Lewisが2014年に書いたブログ マイクロサービスを9つの特徴で表現している Componentization via Services Organized around Business Capabilities Products not Projects Smart endpoints and dumb pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for failure Evolutionary Design https://martinfowler.com/articles/microservices.html
-
クリーンアーキテクチャ
-
モジュラモノリス#Software Design DDDの境界づけられたコンテキストの概念に従って、モノリス内で明確に境界が分かれたコンテキストをそれぞれモジュール化する 例としてコンテキスト間のI/FはProtocol Buffersにて定義し、ヘキサゴナルアーキテクチャにおけるアダプタ層のみ公開することで、境界を跨いだ依存解決を許さない等の方法がある
-
DDD/集約#Software Design DDDにおいて不変条件を適用するエンティティや値オブジェクトのようなオブジェクトのグループ単位 原文は以下 エンティティと値オブジェクトを集約の中にまとめ、各集約の周囲に境界を定義すること。各集約に対してルートとなるエンティティを1つ選び、境界の内部に存在するオブジェクトへのアクセスはそのルートを経由して制御すること。外部のオブジェクトが参照を保持できるのは、ルートのみとすること。内部のメンバに対する一時的な参照を渡してよいのは、単一の操作で使用する時だけだ。ルートがアクセスを制御するので、内部が知らないうちに変更されることはなくなる。この取り決めにより、どんな状態変化においても、集約内にあるオブジェクトと集約全体に対して、不変条件をすべて強制することが現実的になる。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P127
-
DDD/エンティティ#Software Design DDDにおいて同一性を持つオブジェクトの呼び名 原文は以下 オブジェクトの中には、主要な定義が属性によってなされないものもある。そういうオブジェクトは同一性のつながりを表現するのであり、その同一性は、時間が経っても、異なるかたちで表現されても変わらない。そういうオブジェクトは属性が異なっていても、他のオブジェクトと一致しなければならないことがある。また、あるオブジェクトは、同じ属性を持っていたとしても、他のオブジェクトと区別しなければならない。同一性を取り違えるとデータの破損につながりかねない。 Eric Evans | エリック・エヴァンスのドメイン駆動設計 | P89
-
ヘキサゴナルアーキテクチャ
-
実践ドメイン駆動設計
-
良いコードとは何か#Software Design 特に結合度と凝集度について参考になる研修資料 キーワード 技術的負債 クリーンアーキテクチャ
-
DevOps capabilities/Loosely coupled teams#Software Design DevOps capabilitiesの1つ、Fast Flowに分類される DORA | Capabilities: Loosely coupled teams
-
DevOps capabilities/Empowering teams to choose tools#Software Design DevOps capabilitiesの1つ、Climate for Learningに分類される 仕事の満足度に寄与し、ツールやテクノロジーをチームに強制するとチームによる実験が制限されてしまう DORA | Capabilities: Empowering teams to choose tools
-
実践クリーンアーキテクチャ#Software Design #成瀬 允宣 クリーンアーキテクチャを実装レベルで実践するドキュメント 実践クリーンアーキテクチャ │ nrslib
-
エリック・エヴァンスのドメイン駆動設計