Pythonによるアーキテクチャパターン

付録E. バリデーション

、これらのテクニックについて教えたり話したりしていると、何度も出てくる質問がある。それはドメインモデルのビジネスロジックに属するのか、それともインフラの問題なのか？

どんなアーキテクチャの質問でもそうだが、答えは「場合による」だ！

最も重要な考慮点は、システムの各部分がシンプルになるように、コードをうまく分離しておくことだ。無関係な細部でコードを乱雑にしたくないのだ。

そもそもバリデーションとは何なのか？

バリデーションという言葉を使う場合、通常は、ある演算子の入力が特定の基準に合致するかどうかをテストするプロセスを意味する。 基準に合致する入力は有効、合致しない入力は無効とみなされる。

入力が無効な場合、演算子は続行できず、何らかのエラーで終了しなければならない。言い換えれば、バリデーションとは前提条件を作成することである。前提条件をシンタックス、セマンティクス、プラグマティクスの3つのサブタイプに分けることが有効であることを発見した。

構文を検証する

言語学において構文とは、文法的な文の構造を支配する規則セットのことである。例えば英語では、「Allocate three units ofTASTELESS-LAMP to order twenty-seven」という文は文法的に正しいが、「hat hat hat hat wibble」というフレーズは文法的に正しくない。私たちは文法的に正しい文を、よく形成された文と表現することができる。

これは我々のアプリケーションにどのようにマッピングされるのだろうか？構文規則の例をいくつか挙げてみよう：

• Allocate コマンドは、注文ID、SKU、数量を持たなければならない。

• 整数は正の整数である。

• SKUは文字列である。

これらは受信データの形状と構造に関する規則である。SKUやオーダーIDのないAllocateコマンドは有効なメッセージではない。これは "Allocate three to. "というフレーズと等価性である。

私たちは、システムのエッジでこれらの規則を検証する傾向がある。私たちの経験則では、メッセージ・ハンドラーは常に、整形式で必要な情報をすべて含むメッセージだけを受信すべきである。

一つの選択肢は、バリデーション・ロジックをメッセージ・タイプそのものに置くことだ：

メッセージクラスのバリデーション(src/allocation/commands.py)

from schema import And, Schema, Use


@dataclass
class Allocate(Command):

    _schema = Schema({  
        'orderid': int,
         sku: str,
         qty: And(Use(int), lambda n: n > 0)
     }, ignore_extra_keys=True)

    orderid: str
    sku: str
    qty: int

    @classmethod
    def from_json(cls, data):  
       data = json.loads(data)
       return cls(**_schema.validate(data))

schema ライブラリーを