設計を形作る機能、ルール、関係者、および流れ。
実際の問題に対する十分なアーキテクチャ
私たちは、マイクロサービス、レイヤー構造、パターンをデフォルトで推奨するわけではありません。構造は、チームが維持できないような運用を生み出すことなく、変更コストを削減するものでなければなりません。
- 変更を加えるたびに、あまりにも多くのモジュールとチームに影響が及ぶ。
- 統合によって内部構造が露呈し、頻繁に不具合が発生する。
- データには明確な所有者や信頼できる情報源が存在しない。
- プラットフォームは、制御不能な複雑さを加えることなく成長しなければならない。
- 書き換え、抽出、モジュール化の決定には、共通の基準が欠けている。
作業によって残されるもの
最終的な範囲は、入手可能な証拠と低減すべきリスクに基づいて合意される。
依存関係、境界、データ、統合、および関連する負債。
費用、価値、リスク、および条件を考慮した代替案。
構成要素、契約、責任、および意思決定記録。
依存関係と価値に基づいて順序付けられた小さな変更。
新たな決定を審査し、その効力低下を防ぐための規則。
最初から最後まで、明確な意思決定が示される
コンテクスト
目標、領域、チーム、制約。
モデル
流れ、境界、データ、そして契約。
オプション
技術面と運用面におけるトレードオフ。
決断
経路、記録、および審査基準。
文脈に応じて決定すべきことは何か
普遍的な推奨を避けるため、条件と制限を明確に定めています。
決めるのは、境界、納品、規模、チーム、そして業務運営であり、ファッションではない。
批判的論理は、相応の独立性を保つ。
所有権と一貫性は、構成要素図よりも重要である。
始める前に質問があります
範囲、証拠、作業方法に関する回答。
図表は提供してもらえますか？
はい、決定事項、状況、責任分担を含めて考える必要があります。図だけでは実行可能なアーキテクチャとは言えません。
既存の提案書をレビューしていただけますか？
はい。私たちは、前提、リスク、運用能力、そして導入経路に疑問を投げかけます。
建築とは、書き換えを意味するのか？
いいえ。私たちは通常、事業を守るための段階的な方法を模索します。
社内チームは参加しますか？
そうあるべきだ。その知識と能力が、何が持続可能かを決定するからだ。
この決定に関連するコンテンツ
診断、処置、または関連する経験を継続してください。
最初の会話
PHPアプリケーションに必要なものについて話し合いましょう
状況、主な阻害要因、そして求める結果についてお聞かせください。初期評価に必要な質問を返信いたします。
- 商業的な義務は一切ありません
- チームとの直接連絡
- お客様の個人情報は第三者に販売されることはありません。