
## 概要

半年前とかに読んだ[Java言語で学ぶデザインパターン入門第3版](https://www.hyuki.com/dp/) 感想まとめ

サンプルコードは書き慣れたTSで記述している(Javaは書き慣れていないので)

参考: [https://github.com/torokmark/design_patterns_in_typescript](https://github.com/torokmark/design_patterns_in_typescript)

## Adapterパターン

クラスのインターフェイスを、クライアントが期待する別のインターフェイスへ変換を実現するパターン

互換性のないインターフェースのためにできなかったクラス同士の連携が可能になる

## Singletonパターン

インスタンスが1つしか存在しないことを保証するパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/singleton](https://github.com/torokmark/design_patterns_in_typescript/tree/main/singleton)

#### Singletonパターンの定義

- コンストラクタは外部に公開しない
  - `new Singleton`が外部から不可能になる
- インタンス取得用のメソッドのみ外部公開する
  - 内部実装的にはFactory Methodのようになっている
  - インスタンスがすでに作成済み確認する

```typescript
namespace SingletonPattern {
  export class Singleton {
    private static singleton: Singleton;
    private constructor() {}
    public static getInstance(): Singleton {
      if (!Singleton.singleton) {
        Singleton.singleton = new Singleton();
      }
      return Singleton.singleton;
    }
  }
}
```

#### 呼び出し

```typescript
namespace SingletonPattern {
  export namespace Demo {
    export function show(): void {
      const singleton1 = SingletonPattern.Singleton.getInstance();
      const singleton2 = SingletonPattern.Singleton.getInstance();
      if (singleton1 === singleton2) {
        console.log('two singletons are equivalent');
      } else {
        console.log('two singletons are not equivalent');
      }
    }
  }
}
```

## Prototypeパターン

新しいインスタンスを作る際にクラスではなく既存のインスタンスから複製するパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/prototype](https://github.com/torokmark/design_patterns_in_typescript/tree/main/prototype)

#### Prototypeパターンの定義

- 複製対象クラスは自身を複製できるcloneメソッドをインターフェースとして持っている
- Builderクラスに複製対象クラスを表す文字列(ex. c1)を渡すと透過的に複製できる

```typescript
namespace PrototypePattern {
  export interface Prototype {
    clone(): Prototype;
    toString(): string;
  }

  export class Concrete1 implements Prototype {
    clone(): Prototype {
      return new Concrete1();
    }

    toString(): string {
      return 'This is Concrete1';
    }
  }

  export class Concrete2 implements Prototype {
    clone(): Prototype {
      return new Concrete2();
    }

    toString(): string {
      return 'This is Concrete2';
    }
  }

  export class Builder {
    private prototypeMap: { [s: string]: Prototype } = {};

    constructor() {
      this.prototypeMap['c1'] = new Concrete1();
      this.prototypeMap['c2'] = new Concrete2();
    }
    createOne(s: string): Prototype {
      console.log(s);
      return this.prototypeMap[s].clone();
    }
  }
}
```

### 呼び出し

```typescript
namespace PrototypePattern {
  export namespace Demo {
    export function show(): void {
      var builder: PrototypePattern.Builder = new PrototypePattern.Builder();
      var i = 0;
      for (i = 1; i <= 2; i += 1) {
        console.log(builder.createOne('c' + i).toString());
      }
    }
  }
}
```

### 所感

このコードでは複製時に`new`キーワード使っているので、生成コストは同じだと思った。

要件次第ではディープコピーを採用することになるので、そこのロジックは考えないといけないと思う。

また、生成時に複数のパラメータが必要な場合、生成コストはそこまで変わらないし、むしろ上がるのではと思う。

ただ、APIレスポンスをパラメータとしている場合は、複製する方がコスト低い(APIリクエストが発生しない)ので複製した方が良さそう。

## Abstract Factoryパターン

関連したオブジェクトの集まりを具象クラスを指定することなく生成できるようにしたパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/abstract_factory](https://github.com/torokmark/design_patterns_in_typescript/tree/main/abstract_factory)

### Abstract Factoryパターンの定義

基本的に`Abstract.*`はインターフェースとして定義されており、メンバの集合体となっている

`Concreate.*`_は_`Abstract.*`のインターフェースの中身を定義している

`Abstract.*`では最終的に生成するオブジェクトの形式だけを決めておいて*、*`Concreate.*`でオブジェクトの実際の中身を返している

```typescript
namespace AbstractFactoryPattern {
  export interface AbstractProductA {
    methodA(): string;
  }
  export interface AbstractProductB {
    methodB(): number;
  }

  export interface AbstractFactory {
    createProductA(param?: any): AbstractProductA;
    createProductB(): AbstractProductB;
  }

  export class ProductA1 implements AbstractProductA {
    methodA = () => {
      return 'This is methodA of ProductA1';
    };
  }
  export class ProductB1 implements AbstractProductB {
    methodB = () => {
      return 1;
    };
  }

  export class ProductA2 implements AbstractProductA {
    methodA = () => {
      return 'This is methodA of ProductA2';
    };
  }
  export class ProductB2 implements AbstractProductB {
    methodB = () => {
      return 2;
    };
  }

  export class ConcreteFactory1 implements AbstractFactory {
    createProductA(param?: any): AbstractProductA {
      return new ProductA1();
    }

    createProductB(param?: any): AbstractProductB {
      return new ProductB1();
    }
  }
  export class ConcreteFactory2 implements AbstractFactory {
    createProductA(param?: any): AbstractProductA {
      return new ProductA2();
    }

    createProductB(param?: any): AbstractProductB {
      return new ProductB2();
    }
  }

  export class Tester {
    private abstractProductA: AbstractProductA;
    private abstractProductB: AbstractProductB;

    constructor(factory: AbstractFactory) {
      this.abstractProductA = factory.createProductA();
      this.abstractProductB = factory.createProductB();
    }
    public test(): void {
      console.log(this.abstractProductA.methodA());
      console.log(this.abstractProductB.methodB());
    }
  }
}
```

#### 呼び出し

- `ConcreteFactory1`や`ConcreteFactory2`はどちらも`AbstractFactory`型なので、結局どのFactoryなのかクライアント側で気にする必要はない
- 気にする必要があるのは、生成されたオブジェクトが`test`メソッドを持つということだけ
- 生成ロジックは隠蔽されている

```typescript
namespace AbstractFactoryPattern {
  export namespace Demo {
    export function show() {
      // Abstract factory1
      var factory1: AbstractFactoryPattern.AbstractFactory =
        new AbstractFactoryPattern.ConcreteFactory1();
      var tester1: AbstractFactoryPattern.Tester =
        new AbstractFactoryPattern.Tester(factory1);
      tester1.test();

      // Abstract factory2
      var factory2: AbstractFactoryPattern.AbstractFactory =
        new AbstractFactoryPattern.ConcreteFactory2();
      var tester2: AbstractFactoryPattern.Tester =
        new AbstractFactoryPattern.Tester(factory2);
      tester2.test();
    }
  }
}
```

### 所感

単一責任の原則に従っているし、クライアントと生成ロジックが密結合しないのはメリットだと感じた

ただ、関連するオブジェクトの集まりが少ない場合は、普通に`Factory Method`パターンで良いと思った

似たUIが複数生成する必要がある場合は、このパターンを採用しても良さそう

仮にこのパターンを採用する場合、コードが複雑になるのは避けられないので、トレードオフを丁寧に評価する必要がある

## Bridgeパターン

抽象部分と実装部分を切り離し、両者を独立して変更できるようにしたパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/blob/main/bridge/bridge.ts](https://github.com/torokmark/design_patterns_in_typescript/blob/main/bridge/bridge.ts)

### Bridgeパターンの定義

![image of bridge pattern](https://images.microcms-assets.io/assets/29c265a7cc5e4ed284faac0e218d88e8/44f2a99ed7a84cd0b44c1a37ccf0d420/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202023-05-21%209.47.35.png?w=1000&h=348)

- `Abstraction`は実装から独立した操作を定義したクラス
  - `Implementator`への参照を保持し、メソッドを定義
- `RefinedAbstraction.*`は`Abstraction`クラスの具体的なサブクラス
  - `Abstraction`クラスで定義したメソッドの具体的な動作を定義
- `Implementor`は抽象化から独立した操作を定義したクラス
- `ConcreteImplementor.*`は`Implementor`クラスの具体的なサブクラス
  - `Implementor`クラスで定義したメソッドの具体的な動作を定義

```typescript
namespace BridgePattern {
  export class Abstraction {
    implementor: Implementor;
    constructor(imp: Implementor) {
      this.implementor = imp;
    }
    public callIt(s: String): void {
      throw new Error('This method is abstract!');
    }
  }

  // ... 以下のコードは省略 ...
}
```

### 呼び出し

```typescript
namespace BridgePattern {
  export namespace Demo {
    export function show(): void {
      var abstractionA: BridgePattern.Abstraction =
        new BridgePattern.RefinedAbstractionA(
          new BridgePattern.ConcreteImplementorA(),
        );
      var abstractionB: BridgePattern.Abstraction =
        new BridgePattern.RefinedAbstractionB(
          new BridgePattern.ConcreteImplementorB(),
        );

      abstractionA.callIt('abstractionA');
      abstractionB.callIt('abstractionB');
    }
  }
}
```

### 所感

ここまでやるかは別として、抽象と実装を切り分けることで、コアロジックと詳細なロジックを分離できる点はメリットだと思う
それにより変更容易性がある程度担保されている
デザインパターンは単一責任の原則が色濃く出ているなと思う

## Strategyパターン

同じインターフェースだが振る舞い(アルゴリズム)をユースケースごとに分離して実行できるようにしたパターン

### サンプルコード

[https://github.com/torokmark/design_patterns_in_typescript/tree/main/strategy](https://github.com/torokmark/design_patterns_in_typescript/tree/main/strategy)

### Strategyパターンの定義

- それぞれの振る舞い(アルゴリズム)を`Strategy.*`クラスに分離する
- `Strategy.*`クラスは`Strategy`インターフェースを持つ
- `Context`クラスは渡された`Strategy.*`クラスを呼び出す

```typescript
namespace StrategyPattern {
  export interface Strategy {
    execute(): void;
  }

  export class ConcreteStrategy1 implements Strategy {
    public execute(): void {
      console.log('`execute` method of ConcreteStrategy1 is being called');
    }
  }

  export class ConcreteStrategy2 implements Strategy {
    public execute(): void {
      console.log('`execute` method of ConcreteStrategy2 is being called');
    }
  }

  export class ConcreteStrategy3 implements Strategy {
    public execute(): void {
      console.log('`execute` method of ConcreteStrategy3 is being called');
    }
  }

  export class Context {
    private strategy: Strategy;

    constructor(strategy: Strategy) {
      this.strategy = strategy;
    }
    public executeStrategy(): void {
      this.strategy.execute();
    }
  }
}
```

### 呼び出し

```typescript
namespace StrategyPattern {
  export namespace Demo {
    export function show(): void {
      var context: StrategyPattern.Context = new StrategyPattern.Context(
        new StrategyPattern.ConcreteStrategy1(),
      );

      context.executeStrategy();

      context = new StrategyPattern.Context(
        new StrategyPattern.ConcreteStrategy2(),
      );
      context.executeStrategy();

      context = new StrategyPattern.Context(
        new StrategyPattern.ConcreteStrategy3(),
      );
      context.executeStrategy();
    }
  }
}
```

### 所感

個人的にはかなり現実的なパターンだと考えている。

生成ロジックの分離に重きを置いたPrototypeやFactory、Bridgeパターンより、Strategyパターンのような振る舞いを分離する方がコスパよく変更の影響範囲を最小化できそうな気がしている。

最初からPrototypeやFactoryパターンなどを実装しているプロジェクトは少ないと思っていて、そうなるとStrategyパターンで振る舞いを分離して置いた上で他のデザインパターンを適用していくという考え方もあるのでは。

## まとめ

デザインパターンを愚直に適用するのは良くないけれど、考え方自体を知っておくのはとても有用だと思う。

残りのデザインパターンは別記事にまとめる。

- Compositeパターン
- Visitorパターン
- Facadeパターン
- Mediatorパターン
- Proxyパターン
- Commandパターン
- Interpreterパターン


<書評> Java言語で学ぶデザインパターン入門第3版 第1弾


## 概要

本書籍では、オブジェクト指向や設計パターンなどソフトウェア設計に関する基本的な概念が紹介されている。

章ごとに読んだ感想を述べていく。

## CHAPTER1: 小さくまとめてわかりやすくする

ソフトウェアは常に変更され得るから、変更しやすいコードを書くには何を意識すべきかがまとめられている。

分かりやすさに主眼が置かれており、変数名を明確にしたり、値オブジェクトを使うことやイミュータブルなデータに関して言及されている。

「クラス名やメソッド名と業務の用語を一致させること」これはかなり大事。異音同義語があると認識のズレとか生まれやすいし、話していてツラミ感じる。

## CHAPTER2: 場合分けのロジックを整理する

ソフトウェア変更容易性を妨げるのが複雑なロジックなので、簡単に書こうという内容や方法がまとめられている。

メソッドに切り出すとか、ifのネスト、ガード節による早期returnなど。

switch文などで分けるより、クラス化しロジックをカプセル化して呼び出すだけにすると見通しが良くなるなど。

使う側のクラスが使われる先のクラスに関する知識が少ないほど疎結合になって良い。

Railsで開発しているとどうしても密結合になりがちなので、改めて意識したいと思った。

## CHAPTER3: 業務ロジックをわかりやすく整理する

1,2章が部品レベルの話だったが、この章ではアプリケーション全体の組み立てレベルでのロジックの分かりやすさについてまとめている。

ドメインオブジェクトをクラスとして管理していく際に下記のことに気をつける。

- メソッドをロジックの置き場所にする
  - getter / setterメソッドだけになっていないか？（=ドメインモデル貧血症）
- ロジックを、データを持つクラスに移動する
  - ロジックが点在していないか？共通化できないか？
- 使う側のクラスにロジックを書き始めたら設計を見直す
- メソッドを短くして、ロジックの移動をやりやすくする
- メソッドでは必ずインスタンス変数を使う
  - Railsの文脈だとクラス内のカラム等
  - 受け取った引数だけ使っているのであればそのクラスに定義する意味がない
- クラスが肥大化したら小さく分ける
- パッケージを使ってクラスを管理する

上記を組み立てる段階で、プレゼンテーション層にドメインロジックが書かれていないか？

アプリケーション層との結合はどうか？等の責務を意識していく。

基本的にドメインオブジェクトにロジックをまとめることで凝集性を高める方が好ましい。

## CHAPTER4: ドメインモデルの考え方で設計する

ドメインの関心事を適切にモデルに落とし込んで独立した単位として扱えるようにする重要性についてまとめられている。

ドメイン内のユビキタス言語を定めてクラス名に落とし込むことや、「コト」を中心に考えることで関心事を特定しやすくなるなど。

特に学びだったのがドメインオブジェクトの基本設計パターンと業務の関心事パターン

### ドメインオブジェクトの基本設計パターン

- 値オブジェクト
  - 数値、日付、文字列などをラップしてロジック整理する
- コレクションオブジェクト
  - 配列やコレクションをラップしてロジック整理
- 区分オブジェクト
  - 区分の定義と区分ごとのロジックを整理
- 列挙型の集合操作
  - 状態遷移ルールなどを列挙型の集合として整理

この4種類で業務ロジックを整理していくと業務ロジックがドメインモデルに集約できる。

### 業務の関心事パターン

- 口座パターン
  - 現在の値を表現し妥当性を管理
    - 数値の増減や現在の値を保持
    - 銀行の口座や在庫数量の管理など時系列が重要なパターン
- 期日パターン
  - 約束の期日と判断を表現
    - 期日が適切に守れているかを管理
      - 期限切れの場合はどうするかなどの表現
- 方針パターン
  - 様々なルールが複合する複雑な業務ロジックを表現
- 状態パターン
  - 状態と、状態遷移できる/できないを表現
    - 決済ステータスなどで利用される
      - ある状態ではどうなるべきなのかを表現

上記4種類が主な関心事パターンとして挙げられるが、ドメイン理解をしていくことが適切に関心事を扱えるようになるポイント。

異音同義語に注意したい。あと、話を深掘り真の課題を抽出すること。

## CHAPTER5: アプリケーション機能を組み立てる

サービスクラスに業務ロジックを書かないようにする。

防御的プログラミングの形式で多くのガード節があると、ドメインモデルにロジックを移すかクラスを用意するなりした方が良い。

あくまでサービスクラスは処理を呼び出すだけ。尋ねるな命じろ。

## CHAPTER6: データベースの設計とドメインオブジェクト

データベース設計がうまくいくとアプリケーションロジックも書きやすくなる。

NOT NULL制約だったり、一意性制約、外部キー制約など。詳細はSQLアンチパターンなどの書籍に譲る。

というよりDB設計の細かい話より、ドメインの中でテーブル単位をどう切り分けるのかという話の方が重要。

「コトの記録」を徹底すると本書には書かれている。

実体があるものはモデリングしやすいが、実体の無いものこそ業務ロジックの中ではモデリングすることが大事。

texta.fmというラジオでも和田さんが同じことをおっしゃっていた。

## CHAPTER7: 画面とドメインオブジェクトの設計を連動させる

汎用画面は複数の関心事が混ざっておりロジックを複雑にしてしまう。

何事も関心事の分離が肝とあるが、ビジネスサイドからは1つの画面で全部行いたいという要望もあるので落とし所は難しいなと思う。

逆に言うと、1つの画面で共通の関心事をまとめられていないという側面もあるのかもしれない。

複数の関心事が混ざっていることだけでなく、同じ関心事が複数画面に点在していないかも意識できると良さそう。

## CHAPTER8: アプリケーション間の連携

APIの粒度を適切に保つことが再利用性や利用容易性を高める。

本書では大は小を兼ねるAPIはビジネスの発展を阻害するとあるが、まさにその通りだと思う。

ユースケース上では不要なパラメータや戻り値など、複雑にする要因があると連携がスムーズにいかない。

将来的な拡張性も難しくしてしまうと感じる。

関心事の不一致が起きていないかどうかはこういう場面でも意識したい。

## CHAPTER9: オブジェクト指向の開発プロセス

オブジェクト指向らしく分析と設計を一体にすることで、変更が楽で安全なソフトウェア開発を進められる。

業務ロジックをドメインモデルに集約して整理することが肝。

分析工程と設計工程を分割せずに一貫して行うことや、コードが自己文書化すべき等の記載がある。

兎にも角にもドメインを深く理解してモデリングすることが大事。

## CHAPTER10: オブジェクト指向設計の学び方と教え方

オブジェクト指向設計の考え方を習得するには、リファクタリングが手っ取り早い。

コードの重複や巨大なメソッド/クラス、引数が多すぎるメソッドなどをリファクタリングすることでなぜ使いやすくなるのかを肌で感じることが大事。

話は少し逸れるが、最近は脱オブジェクト指向が主流になりつつあるような気がするので別途ブログにまとめたい。

## まとめ

再利用性が高くDRYなコードを書くのはもちろん、ドメインを適切にモデリングすることを意識したい。


<書評> 現場で役立つシステム設計の原則


## 2022年総括

技術的にできることが増え、仕事でも任されることが増えたことで全体的に充実した1年だった。
特に好きな技術領域ができてさらに学習意欲が高まったので、良い流れに乗れたと思っている。

## 技術的にやったこと

- TypeScriptの理解を深めた
- React周りのエコシステムの知見を貯めた
- CTIでテーブル設計した
- 色々なGemの選定をした
- Docker開発環境の改善をした
- Linuxの勉強を始めた
- 本番稼働しているRuby/Railsのアップグレードをした

特に印象に残っているのは2つ。

- TypeScriptの理解を深めた
- CTIでテーブル設計をした

この2つが特に印象に残っている。記事に書き下ろしている。

[type-challengesでeasyからmediumまで81問解いて学んだTSの型プログラミング](https://kdevlog.com/posts/0ok_nhfllo)

[Delegated typesを利用した際の知見](https://kdevlog.com/posts/delegated-types)

また、JavaScriptのエコシステムにかなり興味関心を持ち始めたのも大きな影響がある。

今まで業務でRuby / TypeScriptを書く中でどういう技術が好きというのは無かったが、昨年は明確にJavaScriptのエコシステムが好きだと認知できた。

大学時代にJavaScriptを使った講義で簡単なWebアプリケーションを作って動かした経験からWebの表現力に感銘を受けて、エンジニアという職業を志した。

その際の感銘というのが具体化して今の興味関心につながっていると考えている。

例えば、Webブラウザの仕組みやレンダリングのパフォーマンス、CDNや仮想DOM、WebAssemblyなどブラウザの表現力に根底から関わる部分に自分は興味があるのだと認知した。

この部分をもっと極めていきたいと考えている。

## 今年の目標

- JavaScriptエコシステムに関する技術的なインプット/アウトプットをする
- それに関するOSSにコミットする
- Rustを学ぶ（Denoを読めるようになりたい）


2022年振り返り


## 概要

DockerのRubyイメージを上げた時にpostgresql-client 11が見つからなかった
その際にDebianバージョンを知ったのでそのまとめ

## 詳細

解決策の詳細は[**Railsアップグレードをした際の知見**](https://kdevlog.com/posts/7oo2u06co){:target="\_blank"}という記事に譲るとして、ここではDebianバージョンの全体感についてまとめる。

### Debianのリリースカテゴリについて

[**https://www.debian.org/releases/**](https://www.debian.org/releases/){:target="\_blank"}によると、Debianはstable(安定版)、testing(テスト版)、unstable(不安定版)の3つのカテゴリに分けてリリースを管理している。

unstableで開発をしていき、testingで動作確認を行い、stableでプロダクションリリースを行う形とのこと。

現在のstableバージョンは`bullseye`であると[**公表**](https://www.debian.org/releases/stable/){:target="\_blank"}されている。現在のtestingバージョンは`bookworm`とのこと。

### DebianのLTS

DebianのLTSはそれぞれのリリースで3年間の全面サポートと LTS による2年間の延長サポートを想定できる。

例えば、現在のstableである`bullseye`は2021/8/14に初版リリースされたので、そこから約5年程度はサポートがあるということ。

詳しくはこちら[**https://wiki.debian.org/LTS**](https://wiki.debian.org/LTS){:target="\_blank"}

## まとめ

意識する回数は少ないかもしれないが、今知識として知れたことは良かったと思う。


Debianバージョンについて


## 概要

社内の新規アプリケーション開発時にマルチテナント対応をしたいという話になり、Railsでそれを実現するGemを選定して実装した際の振り返り

## 背景

PostgresqlのRLS([Row Level Security](https://www.postgresql.jp/document/9.6/html/ddl-rowsecurity.html))も考慮してテナントごとのデータを安全に扱いたかったため、それを前提にGemを探した

RLSのGemは [https://github.com/suus-io/rls_rails](https://github.com/suus-io/rls_rails) も候補としてあったが、DSLみが強くconfigが複雑になりそうだったので不採用。

色々探した結果、SmartHRさんがRLSのGemを公開したという[記事](https://tech.smarthr.jp/entry/2022/02/15/202241)を読んで、結果的にそのGem ([https://github.com/kufu/activerecord-tenant-level-security](https://github.com/kufu/activerecord-tenant-level-security)) を採用。

採用したGemが [https://github.com/citusdata/activerecord-multi-tenant](https://github.com/citusdata/activerecord-multi-tenant) でのマルチテナント実装を推奨していたため、それを元に進めた。

## 詳細

まず[usage](https://github.com/kufu/activerecord-tenant-level-security#usage)に書かれているようにconfigでテナント分離できる設定を追記。

```ruby
TenantLevelSecurity.current_tenant_id { MultiTenant.current_tenant_id }
```

その後下記手順で動作確認を行なった。

- テスト用のテーブルをマイグレーション（tenant_idをカラムにもたせる）
- テストレコードのINSERT
- Postgresql側でテストテーブルに参照権限を持ったテストユーザーを作成
- テストユーザーでのコネクション確立
- テナント分離動作確認

### 手順1: テスト用のテーブルをマイグレーション

usageに従いpolicyをテーブルに付与（tenant_idのカラムも持たせる）してマイグレーション

```ruby
class CreateEmployee < ActiveRecord::Migration[6.0]
  def change
    create_table :employees do |t|
      t.integer :tenant_id
      t.string :name
    end
    create_policy :employees
  end
end
```

DB側でもpolicyが付与されていることを確認

```plaintext
development=# d employees
                  Table "public.employees"
  Column   |         Type          | Collation | Nullable |               Default
-----------+-------------------+-----------+----------+---------------------------------------
  id       | bigint           |           | not null | nextval('employees_id_seq'::regclass)
  tenant_id | integer         |           |          |
  name      | character varying |           |          |
Indexes:
  "employees_pkey" PRIMARY KEY, btree (id)
Policies (forced row security enabled):
  POLICY "tenant_policy"
    USING (((tenant_id)::text = current_setting('tenant_level_security.tenant_id'::text)))
    WITH CHECK (((tenantid)::text = currentsetting('tenant_level_security.tenant_id'::text)))
```

### 手順2: テストレコードのINSERT

```ruby
2.times do |i|
  Employee.create(tenant_id: i+1, name: "e#{i+1}")
end;nil
```

この段階ではテナント分離されておらず全レコード取得できる

```plaintext
irb(main):003:0> Employee.all
  (0.2ms) SET tenant_level_security.tenant_id TO DEFAULT
  Employee Load (0.6ms)  SELECT "employees".* FROM "employees"
=> [#<Employee:0x0000ffffb2ef9770 id: 1, tenant_id: 1, name: "e1">, #<Employee:0x0000ffffb2c8acf0 id: 2, tenant_id: 2, name: "e2">]
```

### 手順3: Postgresql側でテストテーブルに参照権限を持ったテストユーザーを作成

テストユーザーにはSELECTだけ付与

```plaintext
$ CREATE USER user WITH PASSWORD 'password';
$ c development;
$ GRANT SELECT ON employees To user;
```

### 手順4: テストユーザーでのコネクション確立

ActiveRecordの[establish_connection](https://api.rubyonrails.org/classes/ActiveRecord/ConnectionHandling.html#method-i-establish_connection)を利用してテストユーザーでコネクション確立

```plaintext
irb(main):017:1* app_user_config = {
irb(main):018:1*   adapter: "postgresql",
irb(main):019:1*   encoding: "UTF8",
irb(main):020:1*   database: "development",
irb(main):021:1*   username: "user",
irb(main):022:1*   password: "password",
irb(main):023:1*   host: "db",
irb(main):024:1*   port: 5432,
irb(main):025:0> }
=> {:adapter=>"postgresql", :encoding=>"UTF8", :database=>"development", :username=>"user", :password=>"password", :host=>"db", :port=>5432}
irb(main):026:0> ActiveRecord::Base.establish_connection(app_user_config)
```

### 手順5: テナント分離動作確認

tenant_idが1のレコードのみ返却される

```plaintext
irb(main):016:1* TenantLevelSecurity.with(1) do
irb(main):017:1*   Employee.pluck(:name)
irb(main):018:0> end
  (0.9ms) SHOW tenant_level_security.tenant_id
  (0.5ms) SET tenant_level_security.tenant_id TO DEFAULT
=> ["e1"]
```

これだけではまだ使い物にならないので、実装時に裏側でコネクション確立するような実装や明示的にコネクション抜ける方法も考えないといけない。

## まとめ

RLSという単語を初めて知ったので新しい知見を得られた。Gemの選定も運用を考えた現実的なラインで判断できたので良い経験になった。


Kdevlog

<書評> Java言語で学ぶデザインパターン入門第3版第1弾

<書評> 現場で役立つシステム設計の原則

2022年振り返り

Debianバージョンについて

マルチテナント対応のGemに触れた話

Kdevlog

<書評> Java言語で学ぶデザインパターン入門第3版 第1弾

<書評> 現場で役立つシステム設計の原則

2022年振り返り

Debianバージョンについて

マルチテナント対応のGemに触れた話

<書評> Java言語で学ぶデザインパターン入門第3版第1弾