Terraformはコードをどう配置するかというルールがありません。
だからといって自由にコードを書いてしまうと、コードを管理しづらくなったり、メンバーがコードの変更をキャッチアップしづらくなってしまいます。

Terraformのコードを扱うときは、どう管理するかというルールを定めることが大切です。
この記事では、Terraformにおけるディレクトリ構成の例を示します。

## この記事の目的

この記事の読者の対象はTerraformの基礎を理解している方で、Terraformのコードをどう設計または改善するかについて考えている方です。
ディレクトリの構成例にふれることで、プロダクトにあった構造をみつける参考になればと思います。

## 背景

Terraformはインフラをコードで定義し構築の自動化を行うソフトウェアです。
公式なプロバイダでAWSやGCPのリソース定義をできるのはもちろん、コミュニティプロバイダを使うことでSentryやStripeといったサービスの定義も行えます。
Terraformを使うことで、インフラを宣言的に管理できます。
バージョン管理を行えば差分がわかりやすくなり、コードを共有するメンバーもキャッチアップしやすくなります。

一方でTerraformを使うサービスや環境、プロバイダやリソースがふえたときに、基準となる指針がないと、コードがちらばりわかりづらくなってしまいます。
再利用できそうな、同じ責務をもつモジュールの存在に気づけないかもしれません。
こういった問題を起こさないような、チームにあった指針を決めることが大切になります。

## Terraformにおけるディレクトリ構成とは

この記事でいうディレクトリ構成とは「Terraformのコードをどう配置するか」をいいます。
`main.tf`や`variables.tf`、`outputs.tf`などのtfファイルやモジュールの構成をどうするか。
サービスや環境の種類をどう定義するか。
この課題をディレクトリ構成といいます。

### ディレクトリ構成の要件

この記事では、次の要件を満たすディレクトリ構成について示しています。

* メンバーがルールを把握しやすいこと
* コードを変更しやすいこと
* 複数のサービスに対応できること
* 複数の環境に対応できること
* 再利用性があること

## この記事の前提

この記事の前提として「Terraformのコードをひとつのチームで管理していること」を想定しています。
ひとつのチームで管理しきれない規模になるようであれば、リポジトリを分割するなどの戦略が必要になると思います。

また、Terraformには[Workspaces](https://www.terraform.io/docs/state/workspaces.html)というしくみがあります。
ただ、この記事ではWorkspacesには言及しません。
Workspacesは差分を吸収するためのコードが必要になり、わかりづらくなると考えているためです。

次章でディレクトリ構成を示していますが、これは例にすぎません。
最適なディレクトリ構成はサービスの種類やチームの状況によって異なり、ただひとつの正解はないと考えています。
重要なのはチーム内で指針をもつことです。
チームにあった指針を決めるときの参考になればと思います。

## ディレクトリ構成のベストプラクティス

ここではa.example.comとb.example.comという2つのサービスがあり、それぞれステージングと本番環境をもっていると想定します。
このときのディレクトリ構成を示します。

### 動作環境

この記事にあるコードは、次のバージョンで動作を確認しています。

| 名前 | バージョン |
| - | - |
| Terraform | 0.12.29 |

### ディレクトリ構成

まずディレクトリ構成を示し、次節でこの構成をもとにした設計指針を示します。
モジュールはAWS S3やHerokuなど、エントリポイントから参照されるものをいくつか示しています。

```
▼ modules
  ▼ aws-s3-bucket
      main.tf
      outputs.tf
      variables.tf
  ▶ heroku
  ▶ sentry
  ▶ stripe
▼ services
  ▼ a.example.com
    ▼ staging
        main.tf
    ▼ production
        main.tf
  ▶ b.example.com
```

### ディレクトリ構成の設計指針

上記ディレクトリ構成をもとに、設計指針の例を示します。

**最小限のモジュールをひとつの単位としてmodules下に配置する**。
たとえば「S3のバケットをつくる」「HerokuのWeb Dynoを起動する」など。
このときバケット名などは変数として定義します。
こうすることで再利用性が高まり、各サービスから参照しやすくなります。

**サービスをservices下に、各環境をサービスの下に配置する**。
たとえば`services/a.example.com/staging`。
サービス×環境のエントリポイントがすぐわかります。

**モジュールは3つのtfファイルのみをもつ**。
`main.tf`と`outputs.tf`、`variables.tf`の3つ。
これは[公式ドキュメント](https://www.terraform.io/docs/modules)にある最小限の構成で、名前の決め方やファイルのもつ役割がわかりやすくなります。

**エントリポイントにはバックエンドやプロバイダ、モジュール定義のみを行う**。
できるだけモジュールとして定義し、エントリポイントから使用することで、定義場所のゆらぎがなくなり、再利用性をもたせることができます。

## 備考

上記のディレクトリ構成例において、a.example.comとb.example.comを管理するメンバーが大きく異なる場合はリポジトリをわけた方がよいと思います。
またa.example.comとb.example.comで技術スタックが大きく異なる場合もわけた方がよいかもしれません。
ステートの規模も分割の基準になると思います。

## まとめ

モジュールをわけ、サービス×環境ごとにエントリポイントをもたせるディレクトリ構成例を示しました。
この構成にすることでサービスや環境、モジュールがふえても柔軟に対応することができます。

チーム内でディレクトリ構成の設計指針をもつことで、コードを変更するときの指針になり、またキャッチアップしやすくなります。
チームにあった構成をみつける参考になればと思います。

Terraformはコードをどう配置するかというルールがありません。だからといって自由にコードを書いてしまうと、コードを管理しづらくなったり、メンバーがコードの変更をキャッチアップしづらくなってしまいます。Terraformのコードを扱うときは、どう管理するかというルールを定めることが大切です。この記事では、Terraformにおけるディレクトリ構成の例を示します。

Terraformにおけるディレクトリ構成のベストプラクティス

技術ブログの記事やドキュメントは、構成や書き方しだいでわかりやすさを大きく改善できます。
筆者はこれまでに技術書の執筆や技術ブログの運営、ドキュメントの執筆をとおしてたくさんの記事を書いてきました。
この経験をとおして得た、技術記事を書く上でおさえるべきポイントについて示します。

## この記事の目的

対象となる読者はエンジニアの方で、とくに「技術記事をどう書けばいいかわからない、伝わるか不安」という方を想定しています。
技術ブログの記事やドキュメント（以下「技術記事」とする）を書くときの指針となるポイントについて示します。
この記事をとおして、よりわかりやすい記事を書けるようになることを目的とします。

## 技術記事とは

技術記事とは技術ブログの記事やドキュメントなど、書き手の経験をもとにした体系的な知見や、課題とそれに対する解決策を示したものなどをいいます。
書き手自身の知識の定着やメモになるのはもちろん、読んだ人に技術的な知見を提供する役割をもちます。
また「自分がその知識をもっている」ということを周知することでブランディングにもなります。

## 背景

前章のとおり技術記事は書き手にも読み手にもメリットのある重要な文書です。
記事の存在だけで十分に価値があるといえます。
一方で「用語が難しい」「再現性がない」「いつ書かれたものかわからない」など、読む上で理解しづらい記事があるのも事実です。
せっかく書くならわかりやすい記事を書けるようになろう、というのがこの記事の主旨です。

## ポイントをおさえることでできること

この記事に示すポイントをおさえることで、次のことができるようになります。

* わかりやすい記事になる
* 読み手が記事を読むべきか、読まなくていいかすぐ判断できる
* 再現性があり、いつでも何度でも参照可能なリソースになる

## ユースケース

この記事に示すポイントは、次のような文書を書くときに有用です。

* 技術ブログの記事: たとえばデザインパターンについての記事や、バグとその解決策について示した記事
* ドキュメント: チームで採用したインフラアーキテクチャの構成図と、それにいたった背景

## 技術記事を書く上でおさえるべきポイント

技術記事を書くときのポイントを「構成」「書き方」「記事の表示方法」の3つにわけて示します。
以下は体系的な知見を技術記事にするときの例ですが、バグに関する記事などほかのものにも応用できます。

### 構成について

**ひとつのことのみを書く**: ひとつの記事に複数の本題があると長くなりわかりづらくなる。記事を分けて参照するようにする。

**結論を最初に書く**: 技術記事は読みものではなくインプットや課題解決が目的。タイトルに対するアンサーがなかなかこないとわかりづらくなる。もちろん例外として月刊誌のような読みものもある

**目的や対象を書く**: 誰にどういう課題があって、この記事でなにを示すか、読むとどうなるかを書く。ここで書いた読者対象にあわせて用語を使い分ける。

**前提をそろえる**: 「アーキテクチャ」でもインフラなのかソフトウェア設計なのか、文脈によって変わってくる。認識がずれないよう、はじめに説明する。

**再現性をもたせる**: ソフトウェアならバージョン、外部APIなら投稿日や更新日など、記事にある条件なら必ず再現するようにする。


### 書き方について

**アウトラインを書き、推敲する**: いきなり書きはじめると構成がまとまらなくなる。アウトラインで全体像を描き、推敲でブラッシュアップした上で書きはじめる。

**文を短く切る**: ひとつの文が長いと読みづらくなる。ひとつひとつの文を短くしたり、不要な表現を削除したりする。

**平易な表現にする**: 想定している読者の技術レベルにあわせて、むずかしい単語を別の表現に変えたりする。


### 記事の表示方法について

**投稿日、更新日を表示する**: 技術の変化ははやいため、いつ書かれたかはとても重要な情報になる。単に表示するのではなくわかりやすく表示すべき。

**著者を表示する**: その情報は信頼できるのかの判断材料になる。また記事の内容に問題があったときにコンタクトするためにも重要な情報になる。

**目次を表示する**: 全体でどれくらいの長さか、どんな構成か、読むべきかどうかをなんとなく把握できる（このブログの目次は実装中です）。


## 備考

筆者自身のストーリーがあった方が伝わりやすい、よみやすいこともあります。
上記ポイントをベースに肉づけしていくといいと思います。

また、技術記事の書き方についてはGoogleが「[Technical Writing](https://developers.google.com/tech-writing)」として文書を公開しています。
あわせて読むとよりわかりやすい記事を書くことにつながります。

## まとめ

この記事では、技術記事をわかりやすく再現性のあるものにするためのポイントについて示しました。

技術記事には価値があります。
ポイントをおさえるのもそうですが、まずは書いて公開すること、そしてなにより消さないことが大切だと思います。

技術ブログの記事やドキュメントは、構成や書き方しだいでわかりやすさを大きく改善できます。筆者はこれまでに技術書の執筆や技術ブログの運営、ドキュメントの執筆をとおしてたくさんの記事を書いてきました。この経験をとおして得た、技術記事を書く上でおさえるべきポイントについて示します。

技術記事をわかりやすく書くためにおさえるべきポイント

複数のActiveRecordモデルをまたぐふるまいや、外部APIとのやりとりといったビジネスロジックは、コントローラに書くと肥大化してしまいます。
モデル層の変更の影響を受けやすくなり、ユニットテストが書きづらく、また再利用性がないという問題もあります。

Interactorオブジェクトを導入することでこの問題を解決できます。
ビジネスロジックをカプセル化する責務をもつのがInteractorオブジェクトです。
このInteractorオブジェクトについて以下に示します。

## Interactorオブジェクトとは

Interactorオブジェクトとは「**デザインパターンのひとつで、ビジネスロジックをカプセル化するためのモデル層に属するクラス群**」です。
ひとつのInteractorオブジェクトはひとつの責務をもちます。
「ひとつの責務」とは、たとえば「記事を投稿する」「決済を行う」という、それ以上分割できない責務です。
またInteractorオブジェクトを使うための共通のインタフェースが定義されます。

Interactorオブジェクトと同じ役割として、Serviceオブジェクトがあります。
ただ、Railsの文脈で語られるServiceオブジェクトは定義があいまいで、特定のルールをもちません。
ルールがないとインタフェースが統一されず、また複数の責務をもってしまうといった問題が生じます。

Interactorオブジェクトはビジネスロジックをカプセル化する役割をもち、インタフェースや責務に関するルールがあるため、コードの秩序を保つことができます。

## Interactorオブジェクトの必要性

Interactorオブジェクトはひとつのみの責務をもち、インタフェースが共通なので、使い方を予測することができます。
複雑なビジネスロジックをコントローラに書くと肥大化してしまい、またモデルの変更を受け、テストが書きづらく、再利用性もありません。
Interactorオブジェクトはモデルの変更の影響を受けず、テストしやすく、再利用性もあります。
このためビジネスロジックを記述するためのデザインパターンとしてInteractorオブジェクトが有用になります。

## Interactorオブジェクトのユースケース

Interactorオブジェクトは、次のようなビジネスロジックを書くときに適用されます。

* 複数のActiveRecordモデルを操作する処理。ただし各Interactorは単一の責務になるようにする
* 外部APIとやりとりする処理

## InteractorオブジェクトのためのGem

RailsでInteractorオブジェクトを導入するためのGemとして、[collectiveidea/interactor](https://github.com/collectiveidea/interactor)があります。
コード例は次章で示すとして、機能について示します。

Interactor GemはInteractorオブジェクトのインタフェースを提供します。
具体的にはInteractorをincludeしたクラスに`#call`を定義し、ここにビジネスロジックを書きます。
フックもあるため、処理を実行する前後にログ出力などの処理をはさむこともできます。

また、Interactor Gemの大きな特徴のひとつとしてOrganizerという機能があります。
これは複数のInteractorからなるInteractorを構成するための機能です。
各Interactor間はContextというオブジェクトを共有します。

ロールバックの機能も備えています。
たとえばOrganizer内のひとつのInteractorが外部APIを叩くとき、その後のInteractorが失敗したときのロールバック処理を記述できます。
Organizer全体をトランザクション下で実行することで、データの整合性を保つことができます。

## Interactorオブジェクトの例

Interactorオブジェクトの例として、ショッピングカートのビジネスロジックについて見てみます。
ユーザが注文するときに、注文の確定、決済のための外部APIの実行、配送レコードの作成を行います。
この例ではInteractor Gemを使用しています。
また、具体的な処理や本質でないコードは省略します。

### 動作環境

この記事で示す例は次の各環境で動作を確認しています。

| 名前 | バージョン |
| - | - |
| Ruby | 2.7.1 |
| Ruby on Rails | 6.0.3.2 |

### テーブル定義

この記事で示す例のテーブル定義は次のものを想定しています。

| Table | Column | Type | Not Null |
| - | - | - | :-: |
| order | id | integer | ◯ |
| | amount| integer | ◯ |
| delivery | id | integer | ◯ |
| | order_id | integer | ◯ |

### コントローラ

まずInteractorオブジェクトのインタフェースを確認するために、利用側であるコントローラの例を示します。
次のように、Interactorオブジェクト（ここではOrganizer）の`#call`を呼びます。
ここで渡す引数は`context`としてInteractorオブジェクト内で共有できます。

```ruby
class OrdersController < ApplicationController
  def update
    load_order

    context = ConfirmOrderOrganizer.call(order: @order, params: order_params)

    if context.success?
      redirect_to root_path
    else
      flash.now[:alert] = context.message
      render :edit
    end
  end

  private

  def load_order
    @order = current_user.orders.find(params[:id])
  end

  def order_params
    params.require(:order).permit(:amount)
  end
end
```

### Organizer

次にOrganizerです。
Organizerは複数のInteractorを構成するクラスです。
ここでは「注文内容を更新する」「外部APIを叩く」「配送レコードを作成する」という各Interactorの使用を定義しています。

Organizerはフックを使用してInteractor全体に対しトランザクションを張ることができます。
このトランザクションは再利用性があるので、モジュール化してもいいかもしれません。

```ruby
class ConfirmOrderOrganizer
  include Interactor::Organizer

  organize UpdateOrderInteractor, PayFeeInteractor, CreateDeliveryInteractor

  around do |organizer|
    ActiveRecord::Base.transaction do
      organizer.call
    end
  end
end
```

### Interactor

最後にInteractorオブジェクトです。
次のように、Interactorオブジェクトの実行に失敗したときは、Contextオブジェクトの`#fail!`にエラー用のオブジェクトを渡します。
これにより、使用側（この例でいうコントローラ）の`context.success?`が`false`になり、エラー用のオブジェクトをとおしてユーザにエラー内容を表示することができます。

```ruby
class UpdateOrderInteractor
  include Interactor

  delegate :order, :params, to: :context, private: true

  def call
    return if order.update(params)

    context.fail!(message: '...')
  end
end
```

決済は外部APIを叩く想定です。
外部APIの実行に対するロールバックはActiveRecord::Baseのトランザクションではできません。
このとき`#rollback`を定義すると、後続のInteractorオブジェクトが失敗したときにロールバック処理を実行してくれます。

```ruby
class PayFeeInteractor
  include Interactor

  def call
    # Pay
  end

  def rollback
    # Cancel
  end
end
```

配送レコード作成は次のとおりです。
このようにContextオブジェクトをとおしてInteractor間でオブジェクトを共有することができます。

```ruby
class CreateDeliveryInteractor
  include Interactor

  delegate :order, to: :context, private: true

  def call
    delivery = Delivery.new(order: order)

    if delivery.save
      context.delivery = delivery
    else
      context.fail!(message: '...')
    end
  end
end
```

以上となります。
もちろんOrganizerはなくてもいいです。
この場合はInteractorオブジェクトを直接実行することになります。

以上のように、Interactorオブジェクトはひとつのクラスにひとつの責務をもち、また共有のインタフェースをもつため、ビジネスロジックをシンプルに書くことができます。

## Interactorオブジェクトの設計ルール

以上の内容をもとに、Interactorオブジェクトの設計ルールについてまとめます。
InteractorオブジェクトとOrganizerオブジェクトそれぞれについてまとめます。

### Interactorオブジェクト

* `app/interactors`にファイルを配置する
* 接尾辞にInteractorをつける
* 単一の責務のみをもつ
* クラス名から予測可能なビジネスロジックを書く
* ロールバック可能にする
* Organizerでの使用を想定しているとしても、単一のInteractorとして使用可能にする（他のInteractorに依存しない）
* テストを書く

### Organizerオブジェクト

* `app/interactors/organizers`にファイルを配置する
* 接尾辞にOrganizerをつける
* 必要に応じてトランザクションを張る
* テストを書く

ビジネスロジックをコントローラに書くと肥大化し、モデル層の変更の影響を受けやすくなる、などの問題が生じます。Interactorオブジェクトはビジネスロジックをカプセル化する責務をもち、肥大化などの問題を解決できます。このInteractorオブジェクトについて示します。

Railsのデザインパターン: Interactorオブジェクト

RailsのデザインパターンのひとつにQueryオブジェクトがあります。
これはコントローラからActiveRecordモデルに対する絞り込みなどの操作を、ひとつの責務としてクラスに切り出すパターンです。
コントローラの肥大化を防ぎ、またテストが書きやすくなります。
このQueryオブジェクトについて示します。

## Queryオブジェクトとは

以下、ActiveRecord::Relationを単にRelationと表記します。
Queryオブジェクトは「**Relationに対し結合や絞り込み、ソートなどの操作を定義し、Relationを返すクラス**」です。
ActiveRecordモデルのscopeとして設定することで、チェーンの一部として使用できるようになります。

よく見られるQueryオブジェクトの例として、Relationではなく配列などほかのクラスを返すものがあります。
ただ、クラスやデザインパターンからはインタフェースや返り値が予想できるべきです。
「QueryオブジェクトはRelationを返す」というルールのもとに設計することで、コードの品質が保たれることにつながります。

## Queryオブジェクトの必要性

Queryオブジェクトは「コントローラからクエリ操作の責務を分離し、ActiveRecordモデルと疎結合に保つため」に必要なデザインパターンです。

コントローラからクエリを操作する場合、複雑なクエリは長くなり、肥大化してしまいます。
また正しいRelationが取得できているかのテストが書きづらくなります。
再利用性もありません。

たとえば「1日以内に記事を投稿したユーザの一覧」を取得するコードを見てみます。
コントローラに書くと、次のようになります。

```ruby
class UsersController < ApplicationController
  def index
    @users = User.joins(:posts)
      .where(
        posts: {
          published_at: 1.day.ago..
        }
      )
      .order(created_at: :desc)
  end
end
```

この例ならまだいいですが、これに「PVが100以上の記事を書いたユーザ」「フォロワーが3人以上ついたユーザ」のように条件がふえていくと、コントローラがどんどん肥大化していきます。

コントローラの責務はモデル層に命令を出し、ビュー層にデータを渡すことにあります。
モデル層の操作を組み立てることではありません。
コントローラがモデル層の知識を知りすぎると、モデル層の変更の影響を受けてしまいます。

Queryオブジェクトは、コントローラからクエリ操作の責務を分離し、クラス間を疎結合に保つためのデザインパターンです。

## Queryオブジェクトの例

ここでは、上述したユーザ一覧の例をQueryオブジェクトで書いてみます。

### 動作環境

この記事にあるコードは次の各バージョンで動作を確認しています。

| 名前 | バージョン |
| - | - |
| Ruby | 2.7.1 |
| Ruby on Rails | 6.0.3.2 |

### コントローラ

まず、Queryオブジェクトの使われ方を把握するために、コントローラを見てみます。
コントローラからは次のようにActiveRecordモデルのscopeとして呼び出します。
引数として日付を指定しています。

```ruby
# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def index
    @users = User.recently_posted(3.days)
  end
end
```

### ActiveRecordモデル

次にActiveRecordモデルです。
scopeとしてQueryオブジェクトを渡しています。
AcitveRecordモデルのscopeにすることで、「返ってくるのがそのモデルのRelationである」ことが自明になるというメリットがあります。

```ruby
# app/models/user.rb
class User < ApplicationRecord
  scope :recently_posted, RecentlyPostedUsersQuery
end
```

### Queryオブジェクト

最後にQueryオブジェクトです。
QueryオブジェクトのベースとなるQueryクラスと、それを継承したRecentlyPostedUsersQueryクラスを定義しています。

ActiveRecordモデルのscopeとしてオブジェクトを渡すと、そのオブジェクトの`#call`メソッドが呼ばれます。
これを`#new`に委譲することで、Queryオブジェクトの`#call`が実行される仕組みです。
`#call`に引数を定義することで、コントローラから渡せるようになります。

```ruby
# app/queries/query.rb
class Query
  class << self
    delegate :call, to: :new
  end

  def call
    raise NotImplementedError
  end

  private

  attr_reader :relation
end

# app/queries/recently_posted_users_query.rb
class RecentlyPostedUsersQuery < Query
  DEFAULT_FROM = 1.day

  def initialize(relation = User.all)
    @relation = relation
  end

  def call(from = DEFAULT_FROM)
    relation
      .joins(:posts)
      .where(
        posts: {
          updated_at: from.ago..
        }
      )
  end
end
```

以上となります。
コントローラからRelationに対する操作の責務をひとつのクラスに分離できました。
ActiveRecordモデルに変更があってもコントローラへの影響がなくなり、またテストも書きやすくなりました。

## Queryオブジェクトのルール

以上の内容をもとに、Queryオブジェクトを設計するときのルールについてまとめます。

* ファイルは`app/queries`に配置する
* ベースとなるQueryクラスを定義する
* 接尾辞にQueryをつける
* クラス名から返るRelationが予想できる名前にする
* `#call`を定義し、ActiveRecord::Relationクラスのオブジェクトを返す
* ActiveRecordモデルのscopeをとおして**のみ**使用する。これにより、返るオブジェクトのクラスが自明となる
* `#call`は副作用のないメソッドにする

### アンチパターン

Queryオブジェクトの例として、ひとつのクラスに複数のpublicメソッドを定義する例を見かけます。
これはひとつのクラスに複数の責務をもつことになります。
ある責務の変更が別の責務のメソッドに影響を及ぼすため、避けるべきだと考えます。

ひとつの責務をひとつのクラスに切り出し、単一責任の原則を守って設計することで、保守しやすいコードにすることができます。

RailsのデザインパターンのひとつであるQueryオブジェクトは、コントローラからActiveRecordモデルに対する絞り込みなどの操作を、ひとつの責務としてクラスに切り出すパターンです。コントローラの肥大化を防ぎ、またテストが書きやすくなります。このQueryオブジェクトについて示します。

Railsのデザインパターン: Queryオブジェクト

Ruby on Railsでフォームを扱うとき、ロジックをコントローラやビューに書くとコードの肥大化につながります。
またテストが書きづらく、モデルの変更による影響を受けやすいという問題もあります。

Formオブジェクトを採用することで、コントローラやビューにちらばるロジックをひとつのクラスにカプセル化できます。
ユーザのフォームからの入力を扱うときに採用する価値のあるデザインパターンです。
これについて示します。

## Formオブジェクトとは

まず、この記事におけるFormオブジェクトについて定義します。
Formオブジェクトはモデル層に属するクラス群で、**コントローラ層からユーザの入力を受けとり整形・検証し永続化する責務**をもちます。
また**ビュー層に表示するためのデータを提供する**、という役割もあります。

FormオブジェクトはActiveRecordモデルと1対1の場合もありますが、そうでなくてもかまいません。
複数のActiveRecordモデルの場合もあれば、対応するActiveRecordモデルがない場合にも採用できます。

## Formオブジェクトの必要性

Formオブジェクトはフォームの責務をカプセル化し、コントローラやビューを疎結合に保つために必要なデザインパターンです。

ユーザの入力の整形や永続化をコントローラだけで行うと、コントローラが肥大化してしまいます。
この原因はコントローラがモデル層の知識をもちすぎるためにあります。
このときビューもフォームを表示するための知識をもつことになるため、コントローラと同じような問題が起こってしまいます。
このことは単一責任の原則に反し、**モデル層の変更がコントローラやビューに影響を及ぼす**ことになります。

逆にActiveRecordモデルにこういった責務をもたせると、今度はActiveRecordモデルがフォームの知識を持ちすぎてしまいます。
フォームという独立した責務があるのであれば、これをひとつのクラスにカプセル化する、というのがFormオブジェクトの役割です。

Formオブジェクトにより、コントローラはFormオブジェクトの`#save`のようなたったひとつのインタフェースのみを使うため、クラス間を疎結合に保てます。
ビューもRailsのフレームワークに則った方法でフォームを表示できます。

FormオブジェクトはActiveRecordモデルの`#save`や`#update`のような単純な命令以外のことをするフォームに有用です。
たとえば複数のActiveRecordモデルを操作したり、複数の子レコードをつくるといったものがあたります。
また、フォームのふるまいに関するユニットテストが書きやすいというメリットもあります。

## Formオブジェクトのユースケース

Formオブジェクトは、たとえば次のようなケースに適用できます。
ユーザの入力があり、ActiveRecordモデルの単純な`#save`や`#update`の命令で完結しない処理を行う場合に検討します。

* **サインアップ処理**: ユーザの作成と他ユーザのフォローを同時に行うなど、複数のActiveRecordモデルを作成する
* **複数のタグを作成**: 複数の子レコードを作成するとき。`accepts_nested_attributes_for`を使うような場面だけど使いたくないとき
* **ブログの検索フォーム**: Elasticsearchへのリクエストなど、ActiveRecordモデルを使用しない場合

## Formオブジェクトの例

Formオブジェクトの例を、ブログの記事作成フォームをとおして示します。
全体的な使い方を示せるよう、「作成・更新どちらにも対応」「検証」「複数の子要素を作成」をふまえています。

要件として、記事はタイトルと本文をもち、また複数のタグをもちます。
制約としてタイトルが必須、またタグは1つ以上の入力を必要とします。
これを1つのトランザクション下で行います。

説明しやすいよう、タグはカンマ区切りでひとつの入力欄に記述する形式をとっています。

### 動作環境

この記事で示すコードは、次の各バージョンにおいて動作を確認しています。

| 名前 | バージョン |
| - | - |
| Ruby | 2.7.1 |
| Ruby on Rails | 6.0.3.2 |

### テーブル設計

ブログの記事作成フォームを設計する上で、次のようなテーブルを想定したコード例を示します。

| Table | Column | Type | Not Null |
| - | - | - | :-: |
| posts | id | integer | ◯ |
| | name | string | ◯ |
| | content | text | - |
| tags | id | integer | ◯ |
| | name | string | ◯ |
| taggings | post_id | integer | ◯ |
| | tag_id | integer | ◯ |

### コントローラ

まずコントローラを示し、Formオブジェクトのインタフェースを確認します。
その上でFormオブジェクト、ビューを示していきます。
なお、ActiveRecordモデルやルーティング、例外処理など、本質でないコードは省略しています。

次のコードは記事の作成・編集を行うコントローラです。
フォームを扱うとき、一般的にはActiveRecordモデルのインスタンスをビューに渡しますが、代わりにFormオブジェクトのインスタンスを渡しています。
Formオブジェクトの初期化時に、`#create`と`#update`のときはユーザの入力を渡しています。
また編集画面の`#edit`と`#update`には編集対象となる`@post`オブジェクトを渡しています。

```ruby
class PostsController < ApplicationController
  def new
    @form = PostForm.new
  end

  def create
    @form = PostForm.new(post_params)

    if @form.save
      redirect_to posts_path, notice: 'The post has been created.'
    else
      render :new
    end
  end

  def edit
    load_post

    @form = PostForm.new(post: @post)
  end

  def update
    load_post

    @form = PostForm.new(post_params, post: @post)

    if @form.save
      redirect_to @post, notice: 'The post has been updated.'
    else
      render :edit
    end
  end

  private

  def post_params
    params.require(:post).permit(:title, :content, :tag_names)
  end

  def load_post
    @post = current_user.posts.find(params[:id])
  end
end
```

### Formオブジェクト

次に本題のFormオブジェクトです。
Formオブジェクトは、ユーザの入力と`post`オブジェクトを受け取り、作成・更新処理を行います。

```ruby
class PostForm
  include ActiveModel::Model

  attr_accessor :title, :content, :tag_names

  validates :title, presence: true
  validates :split_tag_names, presence: true

  delegate :persisted?, to: :post

  def initialize(attributes = nil, post: Post.new)
    @post = post
    attributes ||= default_attributes
    super(attributes)
  end

  def save
    return if invalid?

    ActiveRecord::Base.transaction do
      tags = split_tag_names.map { |name| Tag.find_or_create_by!(name: name) }
      post.update!(title: title, content: content, tags: tags)
    end
  rescue ActiveRecord::RecordInvalid
    false
  end

  def to_model
    post
  end

  private

  attr_reader :post

  def default_attributes
    {
      title: post.title,
      content: post.content,
      tag_names: post.tags.pluck(:name).join(',')
    }
  end

  def split_tag_names
    tag_names.split(',')
  end
end
```

Formオブジェクトのコードについて解説します。
まず[ActiveModel::Model](https://github.com/rails/rails/blob/v6.0.3.2/activemodel/lib/active_model/model.rb)をincludeしています。
これは値の代入やバリデーション、コールバックなど、モデルのふるまいをするための、Formオブジェクトに必要となるモジュールです。

`#initialize`ではFormオブジェクトの値を初期化しています。
`#super`はActiveModel::Modelの`#initialize`を呼び出しており、書き込みメソッド（`#title=`など）を用いて値を代入しています。
つまり、Formオブジェクトで用いる値は書き込みメソッドを定義する必要があります。

また、更新にも対応する場合は`#default_attributes`のように保存済みのレコードをもとに値を設定する必要があります。
更新に対応しない場合は`#initialize`を定義する必要はありません。
この場合はActiveModel::Modelの`#initialize`により自動で値の初期化を行ってくれます。

値に書き込みメソッドだけでなく読み取りメソッドも定義しているのは、**ビューのフォームに必要なため**です。
たとえば`form.text_field :title`は`PostForm#title`から値を取得します。
フォームの内容に応じてメソッドを定義する必要があります。

`#persisted?`と`#to_model`はビューの表示（`#form_with`）に必要なメソッドです。
`#persisted?`は作成・更新に応じてフォームのアクションを`POST`・`PATCH`に切り替えてくれます。
また`#to_model`はアクションのURLを適切な場所（ここでは`posts_path`や`post_path(id)`）に切り替えてくれます。

バリデーションについては、ここでは`presence`のみを検証しています。
ActiveRecordモデルと同じく、`#validate`を用い独自のバリデーションを設定できます。
`errors`オブジェクトにエラーを追加すれば、`#valid?`での検証失敗時にユーザにフィードバックを表示することもできます。

### ビュー

最後にビューについて示します。
次の内容は`posts/_form.html.erb`です。
`posts/new.html.erb`と`posts/edit.html.erb`から`@form`を`form`として渡す想定です。

Formオブジェクトに`#persisted?`と`#to_model`を定義したことで、作成・更新画面に応じてフォームの内容を切り替えてくれます。

```erb
<%= form_with model: form, local: true do |form| %>
  <%= form.text_field :title %>
  <%= form.text_area :content %>
  <%= form.text_field :tag_names %>
  <%= form.submit %>
<% end %>
```

以上です。
これまでの内容で記事を作成・更新でき、あわせて複数のタグを登録できるようになりました。

Formオブジェクトを使わないと、上記のロジックがコントローラやモデル、ビューに散らばることになります。
Formオブジェクトにより、フォームのロジックをひとつのクラスにカプセル化できました。

## Formオブジェクトのルール

これまでの内容をもとに、Formオブジェクトを設計するときのルールについてまとめます。

* [ActiveModel::Model](https://github.com/rails/rails/blob/v6.0.3.2/activemodel/lib/active_model/model.rb)をincludeする
* クラス名は接尾辞を`Form`にする（例：`PostForm`）
* `#save`や`#search`など、クラス名から推測可能な単一の処理用メソッドを定義する。失敗時に`false`を返す
* `#persisted?`と`#to_model`に反応するようにする
* バリデーションを実装する。ただしActiveRecordモデルとの整合性に気をつける
* Formオブジェクトがもつべき責務を明確にし、肥大化しないようにする。たとえばレコード作成時にメールで通知するのはモデル層でなくコントローラ層で行う

Formオブジェクトは、コントローラやビューにちらばるフォームのロジックをひとつのクラスにカプセル化します。ユーザのフォームからの入力を扱うときに採用する価値のある、Ruby on Railsのデザインパターンのひとつです。このFormオブジェクトについて示します。

Railsのデザインパターン: Formオブジェクト

機密情報管理サービスとは、ひとことでいうと機密情報のためのキーバリューストアです。
代表的なものとして[AWS Secrets Manager](https://aws.amazon.com/jp/secrets-manager)や[Systems Managerパラメータストア](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-parameter-store.html)、[Hashicorp Vault](https://www.vaultproject.io)があります。
TerraformやAnsibleなどでインフラを構築するときに、機密情報管理サービスを用いることで安全性を高めることができます。

この記事では上記3つのサービスについて、Infrastructure as Codeの文脈で比較します。
またプロダクトにあった選び方について述べます。

## 用語の定義

まず、この記事における用語の定義について示します。

### 機密情報とは

機密情報とは「意図しない第三者に知られると悪用されるおそれのある情報」をいいます。
パスワードやAPIキーなどがあてはまります。
機密情報が漏洩すると、たとえばサーバに不正にアクセスされ、個人情報を取得されるおそれがあります。
あるいは、クラウドリソースを消費され、巨額の費用を請求されるかもしれません。

機密情報をソースコード内に直接記述すると、バージョン管理システムをとおして意図しない人に公開される可能性があります。
機密情報管理サービスを用いることで、このような問題を防ぐことにつながります。

### 機密情報管理サービスとは

機密情報管理サービスとは「機密情報を暗号化し、安全に保管した上で、権限をもったユーザにAPIをとおして提供する機能をもつキーバリューストア」です。
パスベースのものが広く使われており、たとえば次のようにパスをキーとして値を格納します。

| キー | 値 |
| -: | :- |
| `/example-com/production/google-api-key` | `abcde…` |

値はAES-256などのアルゴリズムで暗号化されます。
AWSなどの信頼できるマネージドサービスを用いることで、暗号化された値を安全に保管できます。
また、値へのアクセス権限をポリシーにより管理する仕組みがあります。

## 機密情報管理サービスの要件

機密情報管理サービスには代表時なものにSecrets Managerとパラメータストア、Vaultがあると述べました。
これらサービスがIaCという文脈で満たすべき要件として、次のことがあります。

1. 暗号化されること
2. 安全に保管されること
3. アクセス権限を管理できること
4. APIにより情報を取得できること

この4つの項目を上記サービスはすべて満たしています。
たとえば暗号化について、Secrets ManagerとパラメータストアはAWS Key Management Service (KMS)、VaultはAES-256を用いて暗号化します。

機密情報が保管されるストレージバックエンドについては、Secrets Managerとパラメータストアはマネージドになります。
VaultはS3やAzure、PostgreSQLなどクラウドやリージョン、ストレージを自由に選択できます。

権限管理について、Secrets ManagerとパラメータストアはAWS Identity and Access Management (IAM)によりポリシーベースでアクセス権限を管理できます。
Vaultもポリシーを[HCL](https://github.com/hashicorp/hcl)で定義できます。

## 比較項目

次にプロダクトにあったサービスを選ぶ基準として、コスト、シークレットローテーション、パスワード生成という3つの項目で上記サービスを比較します。

| 項目 | Secrets Manager | パラメータストア | Vault |
| -: | :-: | :-: | :-: |
| コスト | 有料 | 基本的に無料 | 無料/有料 |
| シークレットローテーション | ◯ | - | ◯ |
| パスワード生成 | ◯ | - | ◯ |

まずコストについて、Secrets Managerは機密情報1つにつき$0.4/月、また10,000回のAPIコールあたり$0.05かかります。
パラメータストアは標準パラメータは無料、アドバンストパラメータは機密情報1つにつき$0.05/月かかります。
機密情報の基本的なユースケースにおいては標準パラメータの利用で問題ありません。
パラメータの種類については「[パラメータ層の管理](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/parameter-store-advanced-parameters.html)」をお読みください。

VaultはOSSを利用する場合はサーバ代やメンテナンスコストがかかります。
SaaS版は問い合わせによる料金開示となります。

シークレットローテーションとは、機密情報を定期的に自動で変更する機能で、安全性の向上に役立ちます。
Secrets ManagerとVaultが対応しています。
パスワードを生成する機能もSecrets ManagerとVaultのみが対応しています。

## サービスごとの特徴

上記比較項目以外にも、サービスごとの特徴があります。
機密情報管理サービスを選ぶ上での重要なポイントになります。
以下に特徴を示します。

### Secrets Manager

Secrets ManagerのシークレットローテーションはAmazon RedshiftといったAWS各サービスと統合しやすいという特徴をもっています。
また、Amazon VPCエンドポイントをサポートしているため、機密情報がパブリックインターネットに送信されることを防げます。

そのほか、AWS CloudTrailを用いてログ監査ができます。
CloudWatchやIAMとの統合もしやすいです。
また、Secrets ManagerにはSLA99.9%が設定されています。

### パラメータストア

Secrets Managerと同じくVPCエンドポイントをサポートしていたり、CloudTrailやIAMなどと統合することができます。
SLAは標準パラメータには設定されていませんが、アドバンストパラメータにはSecrets Managerと同じレベルが設定されています。

スロットルについて、パラメータストアは1秒間に最大1,000リクエストがサポートされています。
インフラ構築という文脈では十分な数値といえます。

### Vault

Vaultのアーキテクチャはバックエンドストレージを信頼しておらず、Vaultサーバをとおるすべてのデータはセキュリティバリアという機構により自動的に暗号化されます。
セキュリティバリアからデータが読みとられると改ざんが検出されるなど、安全性を高める仕組みがあります。

またVaultサーバへのアクセスキーはShamir's Secret Sharingというアルゴリズムで分割されます。
これを複数の端末に配置することで、安全性を向上させることができます。

VaultにはDynamic Secrets: 有効期限つきの認証情報を動的に生成して安全性を高める機能があります。
たとえば有効期限つきのIAMユーザを作成できます。

## 選び方

パラメータストアはInfrastructure as Codeに必要な最低限の機能をもっています。
無料で使用できるため、パラメータストアをベースに考えます。

シークレットローテーションやパスワード生成の機能が必要で、AWSのその他サービスを利用しており、かつ有償サービスも採用可能な場合はSecrets Managerが候補になります。

Vaultはもっとも高機能ですが、その分学習コストがかかります。
OSS版の場合は運用コストも考慮しなければなりません。
セキュリティに対する要件が高かったり、Dynamic SecretsなどVaultでしか対応が難しい機能がある場合にはVaultの採用を検討するとよいでしょう。

Terraformなどでインフラを構築するときに安全性を高めるための機密情報管理サービスについて、AWS Secrets Manager、Systems Managerパラメータストア、Hashicorp Vaultの3つを比較します。

IaCにおける機密情報管理サービス比較: Secrets Manager, パラメータストア, Vault

バッチ処理はプログラムの実行方式のひとつで、まとまった処理を一度に行います。時間がかかる処理や定時処理などに有用で、ビジネス側の要件を満たすために重要な役割をもちます。

このバッチ処理の設計にはいくつか重要なポイントがあります。このポイントについて以下に示します。

## バッチ処理とは

![バッチ処理とは](//images.ctfassets.net/pppgbgujcovf/6eUcA9vLljkbwlCXlhwrpi/6b0129d679076d95d16b84eda778e2b5/about-batch-processing.png)

まず、この記事におけるバッチ処理の定義について示します。バッチ処理とは「入力があり、その入力を加工し出力するプログラム」をいいます。たとえばデータベースから処理対象となるデータを取得し、データを変更した上で更新するプログラムがバッチ処理にあたります。

この処理はなんらかのトリガーによって起動します。たとえば時間がトリガーとなって起動します。

## バッチ処理が満たすべき要件

次にバッチ処理が満たすべき要件を定めます。この記事で示す各ポイントは、次の要件を満たすことを目的とします。

* ビジネス側の要件を満たすこと
* 問題をできるだけ起こさないこと
* 処理の状況を把握できること
* 異常時にリカバリできること
* リソースの消費を抑えること

## 抑えるべきポイント

上記の要件を満たすために、バッチ処理を設計する上で抑えるべきポイントは次のとおりです。各ポイントごとに書いていきます。

1. ビジネス側の要件を明確にする
2. Dry Runできるようにする
3. APIを叩く処理はリトライする
4. 外的要因に依存しないようにする
5. テストコードを書く
6. ログを出力する
7. コミュニケーションツールに通知する
8. 冪等性をもたせる
9. 処理対象を引数で指定できるようにする
10. リソースの消費を減らす

### 1. ビジネス側の要件を明確にする

バッチ処理にはビジネス側の要件があります。いつはじまっていつ終わるのか、どの処理の後にはじめるのか。処理対象はなにか。どういう処理をし、どう出力するのか。こういった要件を明確にした上で設計に入ります。

### 2. Dry Runできるようにする

バッチ処理を実行する際のオペレーションミスを防ぐため、Dry Runの仕組みをとりいれます。

バッチ処理はビジネス上重要な処理であることが多いです。処理対象を間違えるとリカバリをする必要があります。場合によってはメンテナンスモードに入ることになります。これはユーザのUXを低下させてしまいます。

このような問題を防ぐため、処理を実行する前にふるまいをチェックする仕組みをつくります。正しい処理対象に正しい処理が行えるか。これを標準出力をとおして確認できるようにします。

より安全な運用をするために、バッチ処理のデフォルトのふるまいをDry Runにすることも検討します。

### 3. APIを叩く処理はリトライする

APIの利用制限にひっかかるとバッチ処理全体が失敗してしまいます。これを防ぐため、APIを叩く処理はリトライするようにします。

APIによってはRate Limitなどのリクエストに関する制限があります。あるいはAPIが一時的にダウンしているかもしれません。リトライを行うことでことで、処理全体が成功する可能性を高めることができます。

リトライの時間間隔はExponential Backoffという手法が有用です。

### 4. 外的要因に依存しないようにする

処理が外的要因に依存すると、それが利用不能になった場合にバッチ処理全体が失敗してしまいます。可能な限り依存しないようにします。

たとえばバッチ処理内で運用者にSlackで通知したとします。この通知を同期的に行うと、エラーハンドリングしない限りバッチ処理全体が失敗します。通知の失敗が許容できるケースでは失敗してもいいようにします。具体的には非同期での実行などの方法をとります。

### 5. テストコードを書く

バッチ処理も、アプリケーションのコードと同じくテストコードを書きます。このことが問題の防止につながります。

テストコードは処理のふるまいを定義し、テストによって正しくふるまっているかを検証します。これを継続的にテストすることで、バッチ処理の品質を保つことができます。

### 6. ログを出力する

バッチ処理に問題が発生したとき、その調査やリカバリにログを利用します。このためログはバッチ処理において重要な役割を果たします。

ログを設計する際は5W1Hを意識すると効果的です。バッチ処理をいつ開始したか、いつ終了したか。処理対象はなにか。どういう処理を行ったか、行わなかったか。なぜその対象なのか。どの処理か──これは一意の処理IDをログに付与すると、ログ監視ツールで調査しやすくなります。

また、エラーが発生したときはスタックトレースをログに記録します。

### 7. コミュニケーションツールに通知する

バッチ処理の状況を把握するために、処理内の主要なポイントでSlackなどのコミュニケーションツールに通知します。これによりバッチ処理が正しく動作していることを確認できます。問題が発生したときにはすぐ気づくことができ、リカバリ作業に移行できます。

この通知はエンジニア以外のメンバーにもわかりやすい形で通知します。こうすることで、ユーザへのフォローまで含めたリカバリを行うことができます。

### 8. 冪等性をもたせる

バッチ処理は、何度実行しても一度処理した対象を二重に処理しないようにします。「何度実行しても同じ結果が得られる性質」を冪等性といいます。冪等性をもたせることで、処理が失敗したときに再度処理すれば未処理のもののみ処理にかけることができます。

### 9. 処理対象を引数で指定できるようにする

未処理のデータを指定して処理にかけられるよう、処理対象を引数で指定できるようにします。バッチ処理が失敗したとき、処理されたものと未処理のものが出てきます。未処理のもののみ再実行できるとリカバリしやすくなります。

これは冪等性をもたせることが難しいバッチ処理に対して特に効果的です。

また、Dry Runと組み合わせることも有用です。今後実施予定のバッチ処理を、処理対象を指定した上で事前に確認できるようになります。

### 10. リソースの消費を減らす

バッチ処理は、その性質上コンピューティングリソースを消費しやすいです。できるだけ消費を減らせるよう、実装上の工夫をします。

たとえばデータベースにある大量のレコードを扱うとき、全件をメモリ上に展開すると多くのリソースを消費してしまいます。この場合、分割して処理することを検討します。

またトランザクションも有用ですが、大量のデータに対するトランザクションはデータベースリソースの消費につながります。適切な粒度で行う必要があります。

## おわりに

![バッチ処理を設計する上で抑えるべきポイント](//images.ctfassets.net/pppgbgujcovf/6UENtMZ6qz8aN11xADtVnU/4c50c03629cb43f89c0c9ba8f972570e/points-on-designing-batch-processing.png)

以上のポイントを意識して実装することで、ビジネス側の要件を満たしつつ、問題が起きづらいバッチ処理を運用することができます。問題が起きたときにも対処しやすいため、可能な限りポイントを抑えるようにします。

バッチ処理はプログラムの実行方式のひとつで、まとまった処理を一度に行います。時間がかかる処理や定時処理などに有用で、ビジネス側の要件を満たすために重要な役割をもちます。

このバッチ処理の設計にはいくつか重要なポイントがあります。このポイントについて以下に示します。

バッチ処理を設計する上で抑えるべきポイント

「上位のモジュールは下位のモジュールに依存してはならない」という原則。
下位のモジュールに依存すると、モジュールが変更されたときに影響を受けてしまう。
各モジュールの間に抽象クラスを導入し、各モジュールはこの抽象クラスに依存することで、モジュールを疎結合に保てる。

依存性逆転の原則

「クライアントにとって不要なインタフェースに依存することを強制してはならない」という原則。
依存するインタフェースがふえると、インタフェースの変更による影響を受けやすくなる。
責務に応じてインタフェースを分けるよう設計する。

インタフェース分離の原則

「サブクラスはスーパークラスに置き換え可能であるべき」という原則。
置き換えられないということは、つまりサブクラスへの知識をもつということ。
これは密結合の原因となってしまう。
スーパークラスの知識のみをもち、サブクラスは置き換え可能であるように設計することで、クラスを疎結合に保てる。

リスコフの置換原則

「クラスは拡張に対して開いていて、修正に対して閉じているべき」という原則。
コードの変更は、既存のクラスを修正するのではなく、新しくコードを追加することによって行うよう設計する。
これにより既存のクラスが影響を受けなくなる。

オープン・クローズドの原則

「クラスのもつ責務はひとつであるべき」という原則。
責務が複数あると、その責務の数だけクラスを変更する理由が生じる。
このとき、ある責務に対する変更が、関係ない別の責務に影響を与えてしまう。
複数の責務をもつクラスは最小限にし、クラスには単一の責務だけをもたせるよう設計する。

単一責任の原則

Web APIのための規格。
APIリクエストのためのクエリ言語と、APIの仕様を記述するためのスキーマ言語からなる。
必要なリソースのみをクエリに記述するため、結果が予測可能となる。
またひとつのリクエストで多くのリソースを取得できるため、ネットワーク接続が遅い環境下に対応しやすい。

GraphQL

Webページの情報を提供するための標準化されたデータ形式。
Googleがページをクロールする際、より正確に情報を収集できるようになる。
また検索結果に画像などのコンテンツを表示できるようになる。

構造化データ

アプリケーションの実行モデルのひとつで、サーバの運用が不要なモデルのこと。
イベント駆動により、実行に必要なサーバが立ち上がる。
従量課金制によるコスト削減や、サーバのアップデート・スケーリングといった管理が不要になるなどのメリットがある。
これにより開発者がプロダクトの価値向上にリソースを使うことができるようになる。

Posts