Zenn
Open4

読書備忘録まとめ

技術書
ゆるふうぇいとゆるふうぇいと

良いコード/悪いコードで学ぶ設計入門

個人的に残しておきたい内容をメモ

第6章

Interfaceを用いた条件分岐の省略(ストラテジーパターン)

  • Interfaceを利用することで、instance of を用いた条件分岐を消去できる
  • Interfaceの実装クラスによって処理の切り替えを行わせる
  • いわゆる「ストラテジーパターン」
    Before)変数strategyの型に応じた処理を行わせようとしている。メソッドの引数もObjectでよくない
    public void strategyTest(Object strategy){
      if(strategy instanceof StrategyOne){
          System.out.println("戦略1を実施");
          return;
      }

      if (strategy instanceof StrategyTwo){
          System.out.println("戦略2を実施");
          return;
      }
  }
    After) Interfaceを利用し、条件分岐をを除去
    • StrategyというInterfaceを新たに定義し、それをimplementしたクラスを引数として受け付ける
      public void strategyTest(Strategy strategy){
    strategy.doaction();
  }

      public interface Strategy {
    void doaction();
  }

Interfaceを用いた条件分岐の省略(ポリシーパターン)

  • 条件処理そのものをInterfaceとして定義する
  • 同一の構造を持つ複数の条件処理を同一扱いできるようになり、IF文を何個も並べる、ということがなくなる。
  • 条件処理(ルール)を定義するInterfaceと、それを管理するポリシークラスを利用する
    イメージ)
// ポリシークラス
public class Policy {
    Set<JudgeRuleIF> rules;

    public Policy(){
        rules = new HashSet<>();
    }

    public void add(final JudgeRuleIF rule){
        rules.add(rule);
    }

    // 検証対象に対し、全てのルール(条件判定)をかける
    public boolean allJudge(String target){
        for(JudgeRuleIF rule : rules){
            if(!rule.judge(target)){
                return false;
            }
        }
        return true;
    }
}


// 条件処理(ルール)を定義用Interface
public interface JudgeRuleIF {
    boolean judge(final String target);
}


// 条件処理(ルール)の実態・・・①
public class NormalRule implements JudgeRuleIF{
    @Override
    public boolean judge(final String target) {
        return false;
    }
}

// 条件処理(ルール)の実態・・・②
public class HiperRule implements JudgeRuleIF {
    @Override
    public boolean judge(final String target) {
        return false;
    }
}

// 条件を使って色々やる
public static void main(String[] args){
        // NormalRuleだけ満たしてればOKなポリシー
        Policy normalPolicy = new Policy();
        normalPolicy.add(new NormalRule());

        // NormalJudgeとHiperRuleの両方を満たす必要があるポリシー
        Policy hiperPolicy = new Policy();
        hiperPolicy.add(new NormalRule());
        hiperPolicy.add(new HiperRule());
}
ゆるふうぇいとゆるふうぇいと

ソフトウェアアーキテクチャの基礎

読んだ感想メモとか、思ったこととか、色々
1章～14章は別途

15章 スペースベースアーキテクチャ

・インメモリデータグリッドを利用したアーキテクチャ
・Hazelcastが有名らしい・・・
・DBから読み込んだ情報を複数のインスタンス間でキャッシュとして共有することで、DBへのアクセスを最小限にできる
・あるインスタンスがDBからデータを読み込んだら、それを共有する他インスタンスが持つキャッシュにレプリケートすることで実現。データレプリケーション
・キャッシュのレプリケーション時に衝突が発生する可能性がある。事前に更新レートやインスタンス数、キャッシュサイズを検討し、衝突率を最小限に抑えることが必要。
・アプリケーションをクラウド環境にデプロイし、DBをオンプレ環境に置いておく、と言ったことが可能。クラウド環境のアプリからは、データポンプを介してオンプレ環境のDBとやりとりする

16章 オーケストレーション駆動サービス指向アーキテクチャ

全体的によくわからん・・・再読する
・サービスレベルでの再利用を目的
・チームが再利用を主眼にシステムを構築すると、コンポーネント間で大量の結合が発生する

17章 マイクロサービスアーキテクチャ

・分散アーキテクチャ。目的は分類
・マイクロサービス = ドメインによって分割されたアーキテクチャの概念。ドメイン or サブドメイン
・ドメイン駆動設計を物理的に具現化
・ドメイン単位での分割
・コレオグラフィ・・・各サービスは中央のメディエータを介さず、必要に応じて他のサービスを呼び出す
・オーケストレーション・・・中央のメディエータが各サービスの呼び出しを管理

・サービス横断でのトランザクション管理
　→基本は避ける

・再利用と結合はトレードオフ
　アーキテクチャの目標が高度な分離であるなら、再利用より複製による分離を優先するべき

・ドメイン駆動に関する理解の深堀が必要・・・

18章 適切なアーキテクチャスタイルを選ぶ

・アーキテクチャスタイルの選択 = トレードオフに関する分析・思考の集大成
判断基準
　・ドメイン
　・構造に影響を与えるアーキテクチャ特性
　・データアーキテクチャ
　・組織的な要員
　・プロセス、チーム、および運用上の関心ごとに関する知識
　・ドメインアーキテクチャの同型性

上記を踏まえて決定すること
　・モノリスか、分散か？
　・データをどこに置くべきか？
　・サービス間の通信は同期型か、非同期型か？
　　・標準は「同期型」