
## 概要

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

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

## 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の選定も運用を考えた現実的なラインで判断できたので良い経験になった。


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


## 概要

CTIで設計したテーブルをアプリケーションに落とし込むために[Delegated types](https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html)を利用したのでその振り返り

## 背景

- サブクラスごとに異なるカラムを使う前提があった
- 今後の拡張時に既存処理の影響を与えずにロジックを記述できるようにしたかった
- そのため、STIよりかはCTI（MTI）的にサブクラスごとにテーブルを分けてその状態を実現したかった
- STIのような共通インターフェースでサブクラスにアクセスしたかった

要は、サブクラスごとにテーブルを分けたいけれど、STIのように共通インターフェースでサブクラスにアクセスしたかった。

最初は[https://max.engineer/mti#multiple-table-inheritance-simulated](https://max.engineer/mti#multiple-table-inheritance-simulated)などを見て、メタプロで実現しようと考えていた。

ただ、納期が迫っていたのでメタプロでやり切れるのか不明瞭だったのと、今後の保守性 / 拡張性まで考えると懸念があった。

調査した結果、[https://stackoverflow.com/a/63273663](https://stackoverflow.com/a/63273663) でどうやらMTIがRails6.1.0からネイティブサポートされたという情報を見つけた。それが[Delegated types](https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html)。

メタプロよりネイティブサポートされた機能を使う方がベターだと考え、これを使って実装をしていこうと決断。（そのためにRailsのバージョンまで上げた）

## 詳細

[Delegated types](https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html)は委譲（Delegate）を使って、スーパークラスから具象サブクラスへアクセスできるようにしている。

クラス設計は下記のようになる。

まず、スーパークラスとしてEntryが存在しており、具象サブクラスとして`Message` / `Comment`が存在している。

スーパークラスには`delegated_type`の宣言をしており、サブクラスには`Entryable`モジュールをincludeしている。

```ruby
# Schema: entries[ id, account_id, creator_id, created_at, updated_at, entryable_type, entryable_id ]
class Entry < ApplicationRecord
  belongs_to :account
  belongs_to :creator
  delegated_type :entryable, types: %w[ Message Comment ]
end

module Entryable
  extend ActiveSupport::Concern
  included do
  has_one :entry, as: :entryable, touch: true
  end
end
```

```ruby
# Schema: messages[ id, subject, body ]
class Message < ApplicationRecord
  include Entryable
end

# Schema: comments[ id, content ]
class Comment < ApplicationRecord
  include Entryable
end
```

スーパークラスの`entryable_id`に具象サブクラスのプライマリID、`entryable_type`にサブクラスのtypeが格納される。

スーパークラス側の`delegated_type`メソッドの`types`オプションで許可するtypeを定義できる。

上記例では、`Message`と`Comment`typeのみ許可することになっている。

この時、スーパークラスとサブクラスのレコードは下記のようになっている。

```plaintext
[1] pry(main)> Entry.first
=> #<Entry:0x0000ffff7c3996b8
    id: 1,
    account_id: 1,
    creator_id: 1,
    entryable_id: 1,
    entryable_type: "Comment"
    created_at: Wed, 26 Oct 2022 07:04:34 UTC +00:00,
    updated_at: Mon, 28 Nov 2022 05:42:32 UTC +00:00,
    >
    [1] pry(main)> Comment.first
=> #<Comment:0x0000ffff7c3996b8
    id: 1,
    content: "content"
    >
```

これにより、下記のようにスーパークラスから`entryable`インターフェースを経由して具象サブクラスにアクセスできる。（ifによるtype分岐などは必要としない。尋ねるな命じよ(Tell, Don't Ask!)）

```ruby
Entry.first.entryable
# => Comment.first

Entry.first.entryable.id
# => Comment.first.id

Entry.first.entryable.content
# => Comment.first.content
```

## まとめ

[Delegated types](https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html) を選定することで新たな知見を得られたのが良かった。

STIとCTIの違いを抑えられただけでなく、Railsのアップグレード（[こちら](https://kdevlog.com/posts/7oo2u06co)の記事）についても知見を得られたのもGood。


Kdevlog

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

2022年振り返り

Debianバージョンについて

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

Delegated typesを利用した際の知見