ユースケース図とSRP(単一責任の原則)
モチベーション クリーンアーキテクチャに則り作られた自分の個人開発のプロダクトが単一責任の原則(SRP)を満たしているのか不安になり、ユースケース図を書くことにしました。その際クリーンアーキテクチャ用のユースケース図を思いついたので共有いたします。 以降このクリーンアーキテクチャ用のユースケース図をアクター図と呼ぶことにします。 おそらく他のアーキテクチャ等でも流用可能だと思うので、気に入ったら是非使ってみてください。 単一責任の原則(SRP)とは 単一責任の原則とは何か？ 色々な言われ方をします。 一つの関数はたった一つのことを行うべき クラスが担う責任は、たった一つに限定すべき 等 これらを言い換えると、以下のように言えます。 モジュールを変更する理由はたった一つであるべき ここで毎度おなじみのボブおじさんが以下のように補足します。 「システムの変更ってのは、ユーザーやステークホルダー
CloudWatchダッシュボードを利用してオートスケール環境の稼働状態を可視化してみた | DevelopersIO
はじめに AWSチームのすずきです。 Webアプリの実行環境としてオートスケール管理のEC2、RDS、ELBを利用するLAMP構成のシステムで、 CloudWatchダッシュボードを利用した、AWSリソースの稼働確認を試みる機会がありましたので、 紹介させていただきます。 環境 構成図 オートスケール設定 スケジュール設定を利用して、システムが利用されない夜間帯にスケールイン、EC2稼働数を抑制する設定としています。 日中はターゲットの追跡スケーリングを利用、ELB配下の1台のEC2あたりのリクエスト数、CPU負荷を一定以下に保つ設定としています。 CloudWatchダッシュボード ELB、EC2、RDSの稼働状態を確認できるダッシュボードを作成しました。 ELBリクエスト数 RequestCount ELBに到達したリクエストの合計数をAZ毎に表示します。 MultiAZ構成の各AZが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - vaga/hugo-theme-m10c at 3094e3f118f9004d00880a03cd85e1c8bb295367
