システム設計でやってくこと

システムを作るとき設計でやることを並べる。これはアーキテクト・開発メンバー分けずに書いた。

要求の確認をする

やりたいことは何か?

それは正しい要求なのか?

誰に影響するのか?

要件を整理する

提供する機能を集める

それは要求を実現できるのか?

アーキテクチャ特性を想像する

機能以外の満たすべき特性はいろいろある

e.g.

セキュリティ

スケーラビリティ

可用性

耐障害性

可搬性（ポータビリティ）

設計する

実装の方向を定める

まずアーキテクチャを考える

構造を選ぶ

全体像を図にする

採用した方式の名前を記載する

アーキテクチャ特性を確認する

満たされる特性の一覧を明記する

システムに必要なアーキテクチャ特性と対応するか確認する

アーキテクチャ決定

要件に対応したコンポーネントを構造内に配置する

行わないコンポーネント間の結合を明示する

「こことここは直接通信しませんよー」とか

設計指針を文章にする

通信、開発言語、フレームワーク、ライブラリなどのガイドライン

開発者が決めるけど方針はあらかじめ定めると混乱がない

一緒にアプリケーションの設計をする

アーキテクト・開発者・ステークホルダーが緒にやる

コンテキストマップを作る　

ドメイン全体を整理する(戦略的DDDみたいな感じ)

ドメイン・サブドメイン・コアドメインなどを整理する

コンテキストを整理して対応付けを行う

サブドメイン内の整理をする(戦術的DDD)

ユビキタス言語を作っていく

定番のパターン・用語は便利

エンティティ・値・イベント

ファクトリ・リポジトリ

サービス

定番の用語じゃなくても採用すればいい

制約・ルール

大きな構造を与えることもある

レイヤ・Tier

エンティティ

ライフサイクルを整理する

ステートマシンとして表現してみる

CRUDの種類を整理する

データベース設計

データベースを選択する

エンティティのCRUDに対応したデータモデルを選ぶ

KVS, RDB, グラフ, ドキュメント, timeseries, ML, shared data structure in memory

アーキテクチャ特性を満たすか確認する

OLAP, OLTP, Stream processing, cache

上記とエンティティの設計を含めて繰り返す

スキーマを設計する

データベース選択と一緒に行う

正規化、非正規化、物理設計・論理設計、VIEW、MATERIALIZED VIEW、INDEX、PK

開発・運用体制を準備する

調査検討・承認の権限を決める

誰が(アーキテクト・開発チーム・ステークホルダ)

何を(フレームワーク・言語・ライブラリ)を提案・承認するのか

ドキュメントの置き場所を決める

ドキュメントのテンプレートを作る

ADR

設計

手順書

開発プロセス

各タスクは何ができてたら完了としてチームが受け入れるか定義する

e.g.

テストできている

レビューしている

追加・変更の正常性監視の方法が定義されている

exporter実装済み

alert ruleも定義済み(関連PRへのリンクあり)

テスト検証方法を定める

自動テスト・Lint・追加の検証(循環参照度・ベンチテスト)をCIで準備するなど

ガイドライン・アーキテクチャ決定の検証方法

メンバーが提案・改善を行う文化を育てる工夫を考える

朝一のもくもく会

会議体の整理

目的・頻度・準備

良い行動を促すための褒めること一覧を作る