Contents
KISSの法則
シンプルに保つ。
Keep It Simple! Stupid の略として知られるKISSの法則は、アーキテクチャ設計・ソフトウェア設計・プログラミング全てに通じるものです。
シンプルに、単純なようになるよう心がけようというものです。
コンウェイの法則
組織の設計するシステムは、その組織のコミュニケーション構造をそのまま反映した設計になる。
身近な例では、DDDを取り入れたいが、ドメインマスターと開発者が遠いため、トランザクションスクリプト型にならざるを得ない。
YAGNIの法則(You ain't gonna need it.)
必要になるまで作るべきではない。
SOLIDの原則
SRP、OCP、LSP、ISP、DIPの5つの原則の頭文字をとったもの。
- SRP: 単一責務の原則(Single Responsibility Principle)
- OCP: オープン・クローズドの原則(Open–Closed Principle)
- LSP: リスコフの置換原則(Liskov Substitution Principle)
- ISP: インターフェイス分離の原則(Interface Segregation Principle)
- DIP: 依存関係逆転の原則(Dependency Inversion Principle)
DRY原則(Don't repeat yourself)
重複コードを省く
THE TWELVE-FACTOR APP
THE TWELVE-FACTOR APPとは、次のようなWebアプリケーションやSoftware as a Serviceを作り上げるための方法論である。
・セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。
https://12factor.net/ja/
・下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。
・モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。
・開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。
・ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。
SpringBootでTWELVE-FACTORを満たすには?
I. コードベース | Githubでソースコード管理する。 |
II. 依存関係 | build.gradleで依存関係を定義する。 |
III. 設定 | application.properties(.yml)で環境変数を定義する。 |
IV. バックエンドサービス | アプリ以外のサービス(DBやS3など)とアプリを疎結合にしておく。 |
V. ビルド、リリース、実行 | |
VI. プロセス | |
VII. ポートバインディング | 組み込みtomcatを使用する。 .warを |
VIII. 並行性 | |
IX. 廃棄容易性 | |
X. 開発/本番一致 | 継続的デプロイしやすくなっていること。 開発環境で動作確認したら、すぐ本番に投入できるか。 |
XI. ログ | アプリから出すログは、ファイルではなくイベントストリームとすること。 |
XII. 管理プロセス | ・DBはflywayMigrateでDDLを管理する。 ・その他サーバの設定もコードで管理する。 |