
## 概要

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。


Delegated typesを利用した際の知見


## 概要

自分の会社でproduction運用しているアプリケーションのRailsバージョンをアップグレードした際の振り返り

## 背景

新機能追加にあたってCTIでテーブル設計をして、[ActiveRecord::DelegatedType](https://api.rubyonrails.org/classes/ActiveRecord/DelegatedType.html)（以下DelegatedType）を利用したかった

ただ、DelegatedTypeはRails6.1.0からしか利用できないので、アップグレードが必要だった

## 詰まったこと

- `GLIBC_2.29`以上が必要だった
  - それに伴いRubyのバージョンをアップグレード
- PostgreSQLのバージョンが見当たらなかった

## GLIBC_2.29以上が必要だった

Railsを6.0.2から6.1.0にアップグレードした際、`nokogiri`インストール時に`GLIBC_2.29`がないと怒られた

```plaintext
ERROR: It looks like you're trying to use Nokogiri as a precompiled native gem on a system with glibc < 2.17:
  /lib/aarch64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /bundle/ruby/2.6.0/gems/nokogiri-1.13.8-aarch64-linux/lib/nokogiri/2.6/nokogiri.so) - /bundle/ruby/2.6.0/gems/nokogiri-1.13.8-aarch64-linux/lib/nokogiri/2.6/nokogiri.so
  If that's the case, then please install Nokogiri via the `ruby` platform gem:
    gem install nokogiri --platform=ruby
  or:
    bundle config set force_ruby_platform true
```

アプリケーションのRubyイメージ（`2.6.7-slim`）では、GLIBCが2.28であることから、GLIBC2.29以上が同梱されたイメージを利用する必要があった

そのため、Rubyのアップグレードも同時に行いイメージを`2.7.6-slim`にして、GLIBCを2.31にしたらinstallに成功

```plaintext
# ldd --version
ldd (Debian GLIBC 2.31-13+deb11u4) 2.31
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
```

良い機会だからRubyのアップグレードまで行ったが、GLIBCの指定バージョンをインストールするだけでも良かった

## PostgreSQLのバージョンが見当たらなかった

修正前は`deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main`で探していたが見つからないと怒られる

```plaintext
#5 33.87 Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
#5 34.28 OK
#5 35.11 cat: /tmp/Aptfile: No such file or directory
#5 35.11 Reading package lists...
#5 35.42 Building dependency tree...
#5 35.52 Reading state information...
#5 35.57 E: Unable to locate package postgresql-client-11
```

Rubyのimageを変えたのでDebianバージョンが変わったから見つからないのではと考えたらその通りだった

```plaintext
$ docker run --rm ruby:2.7.6-slim sh -c "cat /etc/*-release"
Unable to find image 'ruby:2.7.6-slim' locally
2.7.6-slim: Pulling from library/ruby
3d898485473e: Already exists
755e58a55855: Already exists
68a9083723f3: Already exists
b8edf3cdc5de: Already exists
93fc5708079e: Already exists
Digest: sha256:86f0a40ff15ddb9fbdc0a64bcf9ad4e048fec31a3e538a79a526b0461fca9bf8
Status: Downloaded newer image for ruby:2.7.6-slim
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUGREPORTURL="https://bugs.debian.org/"
```

`bullseye`だったので、`deb http://apt.postgresql.org/pub/repos/apt/ bullseye-pgdg main`で探すと見つかった

## まとめ

本番稼働しているアプリケーションのFWバージョンを上げるのは中々できないと思うのでとても良い経験になった
色々と詰まってしまったが、自分で一つ一つ調査して解決できた経験を次に活かしたい


Railsアップグレードをした際の知見


## 概要

STIとポリモーフィック関連の理解が混同していたので改めて整理した記事。

## STIとは

1つのテーブルを継承して複数のモデルを表現する形式。

### 具体例

carsテーブルとtrainsテーブルがvehiclesテーブルを継承すると仮定する。

クラス間の関係性は下図のようになる。

![STI Models](/images/sti_models.png)

STIはテーブル一つで表現するため、DBに存在するテーブルはvehiclesテーブルのみ。

![STI Table](/images/sti_table.png)

vehiclesテーブルのtypeカラムを使って、trains or carsの判別をする。

### メリット

- テーブルが増えない
- Railsの場合だと[STIをサポートしている](https://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html)ので実装容易性がある
- サブクラスのレコードを取得するためにJOINする必要が無い

### デメリット

- カラム数が多くなる
- 別のサブクラスで利用しなければnull値が増える
- 特定のサブクラスのみを参照すべき他テーブルの外部キー制約が、誤ったサブクラスを参照することを防げない

### 参考

[https://qiita.com/yebihara/items/9ecb838893ad99be0561](https://qiita.com/yebihara/items/9ecb838893ad99be0561)

## ポリモーフィック関連とは

複数のモデルから同じモデルを参照する際の関連付けの仕組み。

多態性という言葉より複数のモデルに対して共通のインターフェースを設けられる。

[https://guides.rubyonrails.org/association_basics.html#polymorphic-associations](https://guides.rubyonrails.org/association_basics.html#polymorphic-associations)

### 具体例

ProductモデルとEmployeeモデルはPictureモデルを参照すると仮定（railsガイドそのまま）

```ruby
class Picture < ApplicationRecord
  belongs_to :imageable, polymorphic: true
end

class Employee < ApplicationRecord
  has_many :pictures, as: :imageable
end

class Product < ApplicationRecord
  has_many :pictures, as: :imageable
end
```

picturesテーブルには参照元の親テーブルを表すカラム（`imageable_id` / `imageable_type`）を持たせる。

```ruby
class CreatePictures < ActiveRecord::Migration[7.0]
  def change
    create_table :pictures do |t|
      t.string  :name
      t.bigint  :imageable_id
      t.string  :imageable_type
      t.timestamps
    end
    add_index :pictures, [:imageable_type, :imageable_id]
  end
end
```

`@picture.imageable`を介して親テーブルにアクセスできる。

`@picture`がどの親に紐づいているかどうかの分岐が必要ない。（typeによる分岐等）

### メリット

- DRYに書ける
  - 中間テーブルを省いて相互に関連付けが可能
  - 共通インターフェースで関連付けが可能

### デメリット

- 外部キーを貼れないので参照整合性制約が担保されない

## まとめ

ポリモーフィックとSTIの言語の意味を考えると自然とどちらか分かる。

言語の意味をしっかり抑えようと思った。


STIとポリモーフィック関連の整理


## 所感

ドメイン駆動設計に関して本格的に学ぼうと思って読んだ1冊
ドメインモデルをうまく表現することの利点や技法などをバラバラだった知識をまとめられた印象
ビジネスドメインを丁寧にモデリングして扱えるようにしたい

## Chapter2

### 「システムに最適な値が必ずしもプリミティブな値であるとは限らない」

ドメイン固有の値をどう扱うと良いのかにフォーカスすることが大事。

イミュータブルであることによりデータの信頼性が向上されるし、それにより交換可能になる。（逆に言うと交換以外で値を変更できない）

クラスとして実装していくことで値オブジェクト固有のバリデーションロジックも内包できるというのも扱いやすくなるポイントかなとも思う。

### 値オブジェクトとして扱う基準

また、値オブジェクトとして扱うべきかどうかの判断基準として「そこにルールが存在しているか」「それ単体で取り扱いたいか」という点を筆者が重視しているという点も印象に残った。

ドメイン内で特別視されている（ドメイン固有の呼び名が付いているなど）の場合は、値オブジェクトになり得るのかなと思った。

値オブジェクトに関しては下記のpodcastもとても参考になる。

[https://anchor.fm/textafm/episodes/2--The-Power-of-Constraints-ejufu0](https://anchor.fm/textafm/episodes/2--The-Power-of-Constraints-ejufu0)

## Chapter3

### 値の同一性

- エンティティは識別子(ID)で同一性を判断
- 値オブジェクトは値で同一性を判断
  - 別のオブジェクトだとしても値が同じであれば同一とみなす

### エンティティの判断基準

「ライフサイクルが存在し、そこに連続性が存在する」ことがエンティティかどうかの基準。

作成されて誕生し、削除されて死を迎える。つまりCRUD処理が発生し得る可変なオブジェクト。

値オブジェクトは不変であるため、エンティティではないということが分かる。

### ドメインオブジェクトを定義するメリット

印象に残ったのは「仕様書というのはマクロな要件については有効であってもミクロな要件については無力であることが多い」ということ。

その通りであるし、そこまで記述する必要がないからそうなっているはず。

だからこそ、コードからその要件を汲み取りやすくしておく必要があるなと再認識した。

クラスにドメインオブジェクトのルールを記述して凝集度は高く保つというのは、ドキュメンテーションという文脈においても重要。

## Chapter4

### サービスへのロジック切り出しはドメインモデル貧血症を引き起こす

ドメインモデルの振る舞いをサービスに切り出しすぎると、ドメインモデルがデータだけを保持している無口なオブジェクトになってしまう。

れによってドメインモデル自身が語るべきことを語っていない状態が出来上がってしまう。

データと振る舞いが点在してしまうことで可読性や保守性に欠けてしまう。

そうならないために、ドメインモデルに不自然な振る舞いのみサービスに切り出すことが重要。

複数のモデルを横断する操作を行う際など、ドメインモデル固有ではないロジックが出てきた場合は検討の余地あり。

## Chapter5

### ビジネスロジックをより純粋なものに昇華する

リポジトリパターンを利用して永続化処理を抽象化して隠蔽することで、ビジネスロジックを簡潔にできる。

自分の会社のフロントエンドアプリケーションはリポジトリパターンを利用しており既知の知識としてある。

だからこそ、今一度下記のようなアンチパターンを実装してしまわないように意識したい。

[https://qiita.com/mikesorae/items/ff8192fb9cf106262dbf](https://qiita.com/mikesorae/items/ff8192fb9cf106262)

## Chapter6

### アプリケーションサービスはオブジェクトの操作に徹する

ドメインロジックの責務外の振る舞いを記述することに徹する。

サービスオブジェクトはロジックが雑多になりがち（ドメインロジックが記述されてる / 責務が複数等）なので、今一度サービスクラスを作る際は注意したいと思う。

[Qiitaのリンク](https://qiita.com/joker1007/items/25de535cd8bb2857a685)

## Chapter7

### 依存を避けるよりコントロールせよ

抽象に依存することが重要。依存関係逆転の原則。

抽象に依存することで変更箇所が最小になる。

改めて思うのは良い設計は変更容易性が担保されていること。

## Chapter12

### オブジェクトの境界線が秩序をもたらす

デメテルの法則（最小知識の原則）を元にコード設計する。

Wikipediaによると、デメテルの法則の基本骨子は下記である。

> 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべき

[デメテルの法則 - Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%A1%E3%83%86%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87)

つまり、他のオブジェクトの情報（どういう状態/値であるのか等）を知らなくて良いということ。

「尋ねるな、命じろ」というソフトウェアの格言があるが、その通りに設計していけばルールが漏れ出すのを防げる。

変更が面倒な時は大体同じロジックが書かれているので、改めて意識してコードを書いていきたい。

[Qiita](https://qiita.com/TakeshiFukushima/items/0b16aef3d320a2ccb7c3#%E8%A8%AD%E8%A8%88%E5%8E%9F%E5%89%87%E3%81%8C%E5%AE%88%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E4%BE%8B)

## Chapter13

### 仕様オブジェクトがドメインルールの点在を防ぐ

#### 仕様オブジェクトについて

ドメインの重要なルールだが処理が複雑になってしまうロジックを格納するオブジェクト

目的としては、ロジックの点在を防ぐこと。

例えば、こういったロジックはサービス層で実装されがちだが、それだとドメインルールが点在してしまう。

そういった状況を防ぐために仕様オブジェクトでロジックをラップする。

#### リポジトリのフィルターとしても機能する

リポジトリに仕様オブジェクトを渡してメソッドを呼び出すようにすることで、ドメイン知識を記述せずに済むようになる。

```java
// 仕様オブジェクト
public class CircleRecommendSpecification {
  private readonly DateTime executeDateTime;

  public CircleRecommendSpecification(DateTime executeDateTime) {
    this.executeDateTime = executeDateTime;
  };

  public bool IsSatisfiedBy(Circle circle) {
    if(circle.CountMembers() < 10) {
      return false;
    }
    return circle.Created > executeDateTime.AddMonths(-1);
  };
}

// リポジトリ
public class CircleRepository: CircleRepository {
  private readonly ICircleRepository circleRepository;
  private readonly DateTime now;

  public CircleGetRecommendResult GetRecommend(CircleGetRecommendRequest request) {
    var circleRecommendSpecification = new CircleRecommendSpecification(now);
    // リポジトリに仕様を引き渡して抽出(フィルタリング)
    var recommendCircles = circleRepository.Find(circleRecommendSpecification).Take(10).ToList();
    return new CircleGetRecommendResult(recommendCircles);
  };
}
```

## Chapter14

### レイヤーの隔離と責務の分割

本書ではドメイン駆動設計がアーキテクチャに求めることは、ドメインオブジェクトが渦巻くレイヤーを隔離して、ソフトウェア特有の事情からドメインオブジェクトを防衛することと説明されている。

レイヤードアーキテクチャやクリーンアーキテクチャなどのアーキテクチャも依存の方向を定めて、レイヤーごとに責務を分割している。

ドメイン駆動設計の文脈上で最も重要なのはドメインの隔離を促すこと。

## Chapter15

### 軽量DDDに陥らないこと

デザインパターンなどを盲目的に利用してそれで終わらないこと。

重要なのはドメインの本質に向き合い続けること。

ユーザーを知り対話を続けドメインを改善していくことを意識したい。

## まとめ

依存の方向性 / 責務の分割 / ロジック隠蔽を意識したいと思った。

パターンはある程度分かったが、エリックエヴァンスの書籍を読んで根本的な思想の部分を知りたい。


<書評> ドメイン駆動設計入門: ボトムアップでわかる!ドメイン駆動設計の基本


## 概要

先日社内のPRコードレビューを受けて、`Array#include?`より`Set#include?`の方が高速だということを知った

その時にソースを追ってみたまとめ

## 要約

- `Array#include?`は計算量が`O(n)`
- `Set#include?`は計算量が`O(1)`

## Array#include?

```c
VALUE
rb_ary_includes(VALUE ary, VALUE item)
{
  long i;
  VALUE e;
  for (i=0; i<RARRAY_LEN(ary); i++) {
    e = RARRAY_AREF(ary, i);
    if (rb_equal(e, item)) {
      return Qtrue;
    }
  }
  return Qfalse;
}
```

refs. [https://github.com/ruby/ruby/blob/master/array.c#L5417-L5430](https://github.com/ruby/ruby/blob/master/array.c#L5417-L5430)

```c
/**
 * This function is an optimised version of calling `#==`. It checks equality
 * between two objects by first doing a fast identity check using using C's
 * `==` (same as `BasicObject#equal?`). If that check fails, it calls `#==`
 * dynamically.  This optimisation actually affects semantics, because when
 * `#==` returns false for the same object obj, `rb_equal(obj, obj)` would
 * still return true.  This happens for `Float::NAN`, where `Float::NAN ==
 * Float::NAN` is `false`, but `rb_equal(Float::NAN, Float::NAN)` is `true`.
 *
 * @param[in] lhs          Comparison LHS.
 * @param[in] rhs          Comparison RHS.
 * @retval     RUBY_Qtrue   They are the same.
 * @retval     RUBY_Qfalse  They are different.
 */

VALUE rb_equal(VALUE lhs, VALUE rhs);
```

refs. [https://github.com/ruby/ruby/blob/master/include/ruby/ruby.h#L164-L178](https://github.com/ruby/ruby/blob/master/include/ruby/ruby.h#L164-L178)

説明によるとオブジェクト同士の比較ということ

```ruby
describe "rb_equal" do
  it "returns true if the arguments are the same exact object" do
    s = "hello"
    @o.rb_equal(s, s).should be_true
  end
  it "calls == to check equality and coerces to true/false" do
    m = mock("string")
    m.should_receive(:==).and_return(8)
    @o.rb_equal(m, "hello").should be_true
    m2 = mock("string")
    m2.should_receive(:==).and_return(nil)
    @o.rb_equal(m2, "hello").should be_false
  end
end
```

refs. [https://github.com/ruby/ruby/blob/master/spec/ruby/optional/capi/object_spec.rb#L764-L779](https://github.com/ruby/ruby/blob/master/spec/ruby/optional/capi/object_spec.rb#L764-L779)

念の為テストも確認して同値比較メソッドであることを確認

つまり`Array#include?`は1つずつ同値比較をしているので計算量が`O(n)`

## Set#include?

```ruby
# Returns true if the set contains the given object.
#
# Note that <code>include?</code> and <code>member?</code> do not test member
# equality using <code>==</code> as do other Enumerables.
#
# See also Enumerable#include?

def include?(o)
  @hash[o]
end
alias member? include?
```

refs. [https://github.com/ruby/ruby/blob/master/lib/set.rb#L397-L406](https://github.com/ruby/ruby/blob/master/lib/set.rb#L397-L406)

hashでのアクセスにより `O(1)`の計算量を実現していることが分かった

ちなみにSetはイニシャライズでhashとして扱われている

```ruby
def initialize(enum = nil, &block) # :yields: o
  @hash ||= Hash.new(false)
  enum.nil? and return
  if block
    do_with_enum(enum) { |o| add(block[o]) }
  else
    merge(enum)
  end
end
```

refs. [https://github.com/ruby/ruby/blob/master/lib/set.rb#L245-L255](https://github.com/ruby/ruby/blob/master/lib/set.rb#L245-L255)


Kdevlog

Delegated typesを利用した際の知見

Railsアップグレードをした際の知見

STIとポリモーフィック関連の整理

<書評> ドメイン駆動設計入門: ボトムアップでわかる!ドメイン駆動設計の基本

SetとArrayのinclude?の違い