15. 1. Componentization via Services
2. Organized around Business Capabilities
3. Products not Projects
4. Smart endpoints and dumb pipes
5. Decentralized Governance
6. Decentralized Data Management
7. Infrastructure Automation
8. Design for failure
9. Evolutionary DesignArchitecture
16. 1. Componentization via
Services
•Library: プログラムにリンクされ、インメモリ
で実行可能な関数呼び出し
•Service: Web API リクエスト、RPC によっ
て連携できる独立したプロセス
•Library を一箇所で抱えずにそれぞれ Service
として独立させていこうという考え方
18. 1. Componentization via
Services
• Service 単位で適切な QA テストがされていれば、不具合
リスクはさほど高くない(ゼロではないので検知と迅速な
対応が必要)
• 全てが public interface、後方互換を維持しない変更が必
要になったときのコミュニケーションコストが高い
• API バージョンによる複数エンドポイント提供は双方に負
担がかかり、負債化しやすいのでなるべく避けている
(version はとりあえず Endpoint に入れておくが、極力
version 1 だけでいく方針)
19. 2. Organized around
Business Capabilities
•UI 担当、ミドルウェア担当、DBA のような職
能でチームを分断せず、ビジネス毎にクロスファ
ンクショナルなチームを構成すべき
•このようなチーム境界と相性がよい
• 元々、ビジネス単位のチーム構成はクロスファンクショナ
ルになっている
20. 3. Products not Projects
•開発が終わったら運用担当にお任せで Project
終了ではなく、その Product を所有する感覚
で運用にも継続的に関わるべき
• You build, you run it (Amazon)
• 自社サービスを運営する組織は元々このような考え方になっ
ているケースが多い