Pythonで実現する堅牢なシステム設計〜イミュータブルがもたらす恩恵〜

Pythonで実現する堅牢なシステム設計イミュータブルがもたらす恩恵

自己紹介氏名経歴加藤雅也 2024/04/01 〜 Recustomer株式会社普段はバックエンド開発に従事

本セッションについて対象目的本セッションで話さないこと Webアプリケーションで堅牢なシステム設計を行いたい人堅牢なシステム設計を行う上での一つの選択肢を増やしてもらいたい Pythonの基本文法 Webシステム設計の基本的なお話

2 3 目次ミュータブル・イミュータブルとは 1 本発表の背景 4 イミュータブルデータモデルとは活用事例

ミュータブルなオブジェクトを利用してシステム設計をしていたこれまでのシステム設計本発表の背景顕在化してくる問題点状態遷移の不透明さバグの温床になる「予期せぬ変更」複雑化するにつれ保守性が低下 https://gihyo.jp/magazine/wdpress/archive/2022/vol130 解決策イミュータブルモデルの導入
引用：

ミュータブル / イミュータブルとは？ミュータブル一度作られたオブジェクトの中身（値や構造）を変更できる代表的な例 list dict set
class（特に指定がない場合）イミュータブル一度作られたオブジェクトの中身（値や構造）を変更できない代表的な例 int str float tuple None

ミュータブル / イミュータブルとは？ミュータブル 1 2 3 4 5
6 7 8 9 10 11 12 13 # リストは変更可能 [ , , ] ( ( )) # 例：140220164169920 # 値の追加 . ( ) ( ) # [1, 2, 3, 4] ( ( )) # 140220164169920 (同じID) # 値の変更 [ ] ( ) # [99, 2, 3, 4] ( ( )) # 140220164169920 (同じID) my_list id my_list my_list append my_list id my_list my_list my_list id my_list = 1 2 3 4 0 = 99 print print print print print メモリ上では同じオブジェクトが変更される 99 2 3 4 1 2 3 id: 140220164169920 id: 140220164169920 イミュータブル 1 2 3 4 5 6 7 8 9 10 # 整数は変更不可能 ( ( )) # 例：9784960 # 新しい値を代入 ( ) # 6 ( ( )) # 9785024 (異なるID) # 実際には新しいオブジェクトが作成されている x id x x x x id x = 5 = + 1 print print print メモリ上では新しいオブジェクトが作成される 5 6 id: 9784960 id: 9785024

ミュータブル / イミュータブルとは？注意点 1 2 3 >>> =
1 2 3 >>> 1 0 = 4 >>> t t t ( , [ , ]) [ ][ ] ( ) # (1, [4, 3]) print イミュータブルなオブジェクト内のミュータブルオブジェクトは変更可能補足イミュータブルのオブジェクトはオブジェクトの値を操作するための関数が用意されていない 1 2 3 4 5 6 7 >>> = 1 2 >>> 0 = 3 1 < > 0 = 3 ~^^^ t t Traceback most recent call last File line module t TypeError object does support item assignment ( , ) [ ] ( ): , , [ ] : "<python-input-11>" in 'tuple' not

ミュータブルの危ないところ１関数のデフォルト引数にミュータブルオブジェクトを指定するとそれが共有され続ける問題点 1 2 3 4 5 6
7 8 9 10 11 12 13 14 15 def return 'apple' print 'banana' print 'cherry' print item items items append item items result1 add_item item result1 result2 add_item item result2 result3 add_item item result3 add_item( , []): . ( ) # 1回目の呼び出し ( ) ( ) # ['apple'] # 2回目の呼び出し - 空のリストを期待するが... ( ) ( ) # ['apple', 'banana'] 予想外! # 3回目の呼び出し - さらに積み重なる! ( ) ( ) # ['apple', 'banana', 'cherry'] = = = = = = = Pythonのデフォルト引数は関数定義時に一度だけ評価されるミュータブルなデフォルト引数（リスト、辞書など）は全ての関数呼び出しで共有される関数呼び出し時ではなく関数定義時に作られた同一オブジェクトが使われるそのため、前の呼び出しでの変更が次の呼び出しに影響するなぜこうなるのか？関数定義時１回目の呼び出し２回目の呼び出し３回目の呼び出し何が起きているか？ apple apple banana apple banana cherry [ ]

ミュータブルの危ないところ１回避策１の実装例デフォルトは Noneにして、関数内で新しいリストを作成するイミュータブルなオブジェクトをデフォルト引数に使用する 1 2 3 4
5 6 7 8 9 def None if is None return print "apple" print "banana" print "cherry" item str items list str list str items items items append item items add_item add_item add_item add_item( : , : [ ] ) [ ]: : [] . ( ) ( ( )) # ['apple'] ( ( )) # ['banana'] ← 期待どおり独立 ( ( )) # ['cherry'] = -> =

ミュータブルの危ないところ２問題点リストや辞書を代入すると、コピーではなく参照が渡されるため、片方を変更するともう片方も変更される reference 1 2 3 4 参照共有のメモリ図解 original
2つの変数が同じメモリ位置を参照している 1 2 3 4 5 6 7 8 9 10 11 12 13 # 配列の参照共有問題 [ , , ] # 参照を共有 . ( ) # 変更を加える [ , , , ] # 意図せず元のリストも変わる [ , , , ] ( ) ( ) # 同じオブジェクト >>> = 1 2 3 >>> = >>> 4 >>> 1 2 3 4 >>> 1 2 3 4 >>> == original reference original reference append reference original id original id reference True listの場合

ミュータブルの危ないところ２回避策参照の共有による意図しない変更を防ぐため、オブジェクトをコピーしてから操作するコピー方法浅いコピー (Shallow Copy) 深いコピー (Deep Copy)
1 2 3 4 5 6 7 # リストの場合 . () # または ( ) # 辞書の場合 . () new_list original_list copy new_list list original_list new_dict original_dict copy = = = 1 2 3 import copy new_obj copy deepcopy original_obj = . ( ) 入れ子になったミュータブルオブジェクトも完全にコピー大きなオブジェクトのコピーはメモリ消費が増えるため、適切な場面で使用する

ミュータブル・イミュータブルのメリット / デメリットミュータブルメリットデメリット中身をその場で変えられるため効率的参照を共有していると他の変数からも影響を受ける状態管理が複雑になりやすい
メモリの再割り当てが少ない更新処理が直感的で実装しやすいイミュータブルメリットデメリット安全性が高く、意図しない変更や追加が起きない新しい値を作るときはコピーが必須なのでメモリ使用量が増える可能性がある副作用が少なく、テストしやすい

注意点：実行時に型の強制はされない 1 2 3 4 5 6 7 8 9
from import True class print dataclasses dataclass frozen Order name str o Order name type o name @dataclass( ) : : ( ) ( ( . )) # <class 'int'> = = =1000 dataclass 基本情報特徴 Pythonの標準ライブラリデータを格納するクラスを宣言的に定義する __init__, __repr__, __eq__, 比較演算子などを自動生成ユースケースビジネスロジック薄めのデータ構造の定義で活用 frozen=Trueにより、属性の追加・変更を防止 1 2 3 4 5 6 7 8 from import True class dataclasses dataclass frozen Order id str customer_id str product_id str ordered_at datetime @dataclass( ) : : : : : = コード例

Pydantic 基本情報特徴外部ライブラリデータを格納するクラスを宣言的に定義するデータの自動変換と型強制ユースケース外部データ（API）の検証と変換で利用型アノテーションによる強力なバリデーション実行時に型が異なる場合はエラーとなる
1 2 3 4 5 6 7 # 期待する型でない値を導入するとエラーが発生する ( , ) # ValidationError: 1 validation error for Order # name # Input should be a valid string [type=string_type, # #input_value=10000, input_type=int] # For further information visit https:// #errors.pydantic.dev/2.11/v/string_type o Order id name = = =10000 '0001' 1 2 3 4 5 6 7 8 from import class True pydantic BaseModel ConfigDict Order BaseModel model_config ConfigDict frozen id str name str , ( ): # イミュータブルにする ( ) : : = = コード例

dataclassとPydanticの棲み分けアダプターユースケースフロントエンドなどドメイン DBなど dataclass dataclass Pydantic
Pydantic

イミュータブルデータモデルとは概要特徴ミュータブルの思わぬバグを避け、堅牢なシステム設計を行う上でおすすめの手法 CRUDの中で「Update（更新）」がシステムの複雑さとバグを生み出す根源になっているという思想に基づいている。変更時に新しいオブジェクトを作成する状態の履歴が自然に残る

イミュータブルデータモデルとはイミュータブルの原則得られるメリット従来モデル vs イミュータブルモデル更新 = 上書き →
新バージョン追加オブジェクトは変更不可変更する代わりに新しいバージョンを作成すべての状態変化が記録として残る過去の状態を完全に復元可能変更の透明性と監査の容易さ従来の更新モデル上書きにより履歴が失われる履歴が完全に保持されるイミュータブルデータモデル v1 v1’ v1 v2 v3

実際にモデリングしてみよう

今回モデリングする要件顧客が商品を注文注文日時を記録注文発送発送日時を記録する

ミュータブルモデルの場合本筋ではないのでサクッと

ミュータブルモデルの特徴状態更新中心、履歴保持無しミュータブルモデルでは、テーブルが「現在の状態」のみを保持する単一エンティティに複数の状態情報を保存更新により過去の値が上書きされる複数の日時カラムが混在（注文日時、発送日時など） SQLAlchemy/Djangoなどの一般的なORMは、オブジェクトの状態変更を容易にするミュータブルな設計を前提としている従来のORMアプローチ

ミュータブルモデルのモデル例 1 2 3 4 5 6 7 8 9
10 11 12 class "ORDERED" "SHIPPED" class None None Status StrEnum ORDERED SHIPPED Order id int customer_id int product_id int status Status ordered_at datetime shipped_at datetime ( ): @dataclass : : : : : : : = = | = 注文テーブル設計例（ミュータブル）カラム名データ型 NULL許容 id UUID 不可 customer_id UUID 不可 product_id UUID 不可 status STRING 不可 ordered_at DATETIME 不可 shipped_at DATETIME 可モデル例 1 2 3 4 # 利用例 (...), # DBから復元したもの . . . . () # 発送済みに更新 order Order order status Status SHIPPED order shipped_at datetime now = = = 利用例

ミュータブルモデルのメリット/デメリットメリット「今の状態」を取得するクエリが簡単履歴不要なケースでは十分シンプルな設計で開発初期は速く進む NULLカラムや複数の日時属性が混在し、状態の変遷が不透明になります。システムの成長に伴い保守性が低下していきます。状態管理の課題デメリット
履歴が残らず、過去の真実を再現できない状態管理が複雑になりやすい NULLカラムが増えやすい短期的なセッション情報や、ステートレスな操作、履歴や監査が必要ないシステムに向いているユースケース

イミュータブルモデルの場合

イミュータブルデータモデリングのステップエンティティの抽出 1 エンティティの分類２イベントエンティティは１つの日時属性しか持たないようにする３リソースから隠れたイベントを抽出４非依存のリレーションを交差エンティティで表す
５

抽象的なものなので理解が難しい Step1. エンティティの抽出エンティティとは名前が付けられて他と区別できる対象明確かつ独立した存在を持つもの５W１H によるエンティティ抽出要件文書から以下の要素を抽出することで、エンティティとその属性の候補を特定する
W W W W W H Who（誰が）：顧客、管理者など What（何を）：商品、注文など When（いつ）：注文日時、発送日時など Where（どこで）：住所、店舗など Why（なぜ）：返品理由など How（どのように）：支払い方法などたとえば「顧客」「商品」「ショップ」などを、データとして扱える単位に抽象化したもの商品ショップ顧客

Step1. エンティティの抽出注文システムの要件例顧客商品注文注文日時記録発送発送日時
記録がをするとき、をする。されたときに、をする。要件文書に対して、関連する5W1Hに下線を引き、エンティティを抽出する抽出のコツ抽出されたエンティティ候補 Who 注文日時、発送日時 When How 注文、商品 What ー Where 顧客ー

Step2. エンティティを分類モデリングにおけるエンティティ分類エンティティをリソース、イベントの2つに分類するリソースエンティティイベントエンティティ特徴：日時属性を持たない定義：「もの」としての実体を表す
例：顧客、商品、注文例：発送特徴：日時属性を持つ定義：「できごと」としての実体を表す「請求予定日」のように将来の予定を表すものや、「有効期限」「適用開始日」のようにデータのライフサイクルを表すものは、ここでいう"日時"属性ではない。イベントエンティティの注意点エンティティ分類注文日時、発送日時リソースエンティティイベントエンティティ顧客、注文、商品

Step3. イベントエンティティには１つの日時属性しか持たないようにするイベントエンティティの基本原則イベントエンティティは「何かが起きた事実」を表現 1つの日時属性のみを持つイベントエンティティは1つの日時属性しか持たない複数の状態変化を別イベントに分離複数の日時が必要な場合は、別々のイベントエンティティに分割避けるべき設計
推奨される設計 OrderEvent ordered_at shipped_at OrderEvent ordered_at ShippedEvent shipped_at

Step4. リソースに隠れたイベントを抽出リソースからのイベント抽出とは隠れたイベントの例リソースエンティティを見たとき、「このリソースがどのように変化するか」を考え、リソースの更新のトリガーとなるイベントを明確に抽出商品情報の更新 → 商品更新イベント顧客情報の変更
→ 顧客情報更新イベントこれらもイベントとしてモデリングが必要になる可能性が高い更新日時が必要になるものはイベントの存在を疑う

Step5. 非依存のリレーションシップを交差エンティティで表す非依存である場合に、一方のエンティティのキーをもう一方に外部キーとして持たせてしまうと強い依存関係が生まれる注文ID 請求書ID 注文ID 注文請求書注文ID
請求書ID 注文請求書請求書エンティティが注文エンティティに依存する形となる複数注文を１つの請求書で支払う要件などが登場すると複雑になる 1:1 / 1:N / N:1 / N:N すべて対応締め請求、部分請求など複雑な要件にも対応しうる注文ID 請求書ID 注文請求

モデル例 1 2 3 4 5 6 7 8 9
10 @dataclass( ) : : : @dataclass( ) : : : frozen OrderedEvent order_id OrderId occurred_at datetime frozen ShippedEvent order_id OrderId occurred_at datetime = = True class True class エンティティ 1 2 3 4 5 @dataclass( ) : : : : frozen Order id int customer_id int product_id int =True class イベント

実際の利用フロー Order 自体は変わらず、「発送されたという事実（イベント）」が追加されるだけ注文が生成されるとき発送が完了したとき 1 2 3 4
5 6 7 8 9 10 11 12 13 from datetime datetime order 　　　　 id 　　　　 customer_id 　　　　 product_id ordered_event 　　　　 order_id order id 　　　　　 occurred_at datetime import = = 1 = 1 = 1 = = = Order OrderId CustomerId ProductId OrderedEvent now ( ( ), ( ), ( ) ) ( . , . () ) 1 2 3 4 5 order # DBから復元 shipped_event order_id order id occurred_at datetime = ... = = = ShippedEvent now ( . . () )

イミュータブルモデルのメリット/デメリットメリット過去の事実の再現が可能状態の整合性がシンプル状態の拡張が容易更新の都度データが積み重なるので、通常に比べて多くなる。データの定期的な削除などが必要になる可能性はある。データ量の課題データ量が多くなる
デメリットクエリが複雑になりやすい監査、分析、再現や非同期的な拡張が重要ユースケース

Recustomerの紹介返品キャンセルのCSおよび倉庫業務を自動化返品キャンセルお届け日時 3月16日(水) 17:00 - 19:00 配達完了
配送状況配送業者ヤマト運輸受取り日時を変更注文番号 PAL#002 追跡番号 12345678900 お届け先東京都千代田区 3月29日 07:27 am 配達完了日本, 東京都港区購入後の配送追跡から新たな顧客接点を創り出す配送追跡

返品のフロー顧客が返品申請返品申請日時を記録返品申請返送返送日時を記録する返品承認ストアが返品を承認承認日時を記録返品拒否
ストアが返品を拒否拒否日時を記録

元々のモデル例 1 2 3 4 5 6 7 8 9
10 11 12 13 @dataclass( ) : : : : : : : : : : : frozen ReturnOrder id int order_id int customer_id int product_id int status int requested_at datetime approved_at datetime rejected_at datetime completed_at datetime reject_reason str = | | | | True class None None None None 注文テーブル設計例（ミュータブル）一部幅の都合で省略カラム名データ型 NULL許容 id int 不可 order_id int 不可 status int 不可 requested_at datetime 不可 approved_at datetime 可 rejected_at datetime 可 completed_at datetime 可 reject_reason datetime 可注文テーブル設計例（ミュータブル）

エンティティの抽出、分類リソースエンティティイベントエンティティ Customer Product Order ReturnOrder Requested Approved Rejected
Complete エンティティの分類リソースエンティティ候補イベントエンティティ候補顧客商品注文返品返品申請返品承認返品拒否返送エンティティの抽出

モデル例 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 @dataclass( ) : : : : : : @classmethod ():... ( : ) : ( . , ): # このときに既存のオブジェクトを更新するのではなく、 # 新しくオブジェクトを作成している ( . , ..., ) frozen ReturnOrder id UUID order_id OrderId customer_id CustomerId product_id ProductId activity Requested Approved Rejected Completed activity Approved ReturnOrder isinstance self activity Requested Exception obj ReturnOrder id self id activity activity obj = | | | -> = = = True class def def if not raise return initialize set_approved エンティティモデル 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 # イベントエンティティ @dataclass( ) : : @dataclass( ) : : @dataclass( ) : : : @dataclass( ) : : frozen Requested created_at datetime frozen Approved created_at datetime frozen Rejected created_at datetime reason str frozen Completed created_at datetime = = = = True class True class True class True class イベントモデル

実際の利用方法 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 class def def Usecase return_order_repository execute return_order ReturnOrder return_order_repository new_obj return_order set_approved activity Approved created_at datetime now return_order_repository obj new_obj : ( : ... ): ... : # DBから返品申請済の返品を取得する : ... # DBから取得した返品注文のステータスを変更する . ( ( . ())) # DBに永続化させる ....( ) __init__ = = = = = 返品申請を承認するユースケース

まとめ状態遷移の不透明さ過去の真実を再現できない拡張時の複雑さミュータブル設計の問題点整合性が取れた状態遷移過去の真実を再現できる拡張の容易性イミュータブルデータモデリングイミュータブルデータモデルは複雑なビジネスロジックを持つWebアプリケーションの堅牢性を向上させます

参考 https://gihyo.jp/magazine/wdpress/archive/2022/vol130 WEB+DB PRESS Vol.130：

Pythonで実現する堅牢なシステム設計 〜イミュータブルがもたらす恩恵〜

Pythonで実現する堅牢なシステム設計 〜イミュータブルがもたらす恩恵〜

More Decks by Masaya

Featured

Transcript

Pythonで実現する堅牢なシステム設計〜イミュータブルがもたらす恩恵〜

Pythonで実現する堅牢なシステム設計〜イミュータブルがもたらす恩恵〜