DDDで考えるマイクロサービスのバリデーション - Qiita

テクノロジーカテゴリーの変更を依頼記事元:

qiita.com/hikouki

14 usersがブックマークコメント

コメント

3

記事へのコメント3件

注目コメント
新着コメント

tinsep19 AによりBのルールが変わるがフォームなら、フォームが異なる複数のモデルを作る可能性がある(=Factory)なので、境界の違う業務知識じゃないかな。

2017/12/15 リンク

efcl バリデーションをどこで行うかという話

DDD

2017/12/15 リンク

yo-iida DDDのバリデーション

DDD

2017/12/14 リンク

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

規約違反を報告

アプリのスクリーンショット

いまの話題をアプリでチェック！

バナー広告なし
ミュート機能あり
ダークモード搭載

アプリをダウンロード

関連記事

DDDで考えるマイクロサービスのバリデーション - Qiita

この情報は古いです。リライトしました。 http://hikouki.hateblo.jp/entry/2019/05/31/164944 この記事... この情報は古いです。リライトしました。 http://hikouki.hateblo.jp/entry/2019/05/31/164944 この記事は CrowdWorks Advent Calendar 2017 の14日目です。エンジニアリーダーの @hikouki です。 0からDDDでアプリケーションを立ち上げ中ですが、バリデーションの壁にぶち当たったので、「バリデーション」はどう扱えばいいのか考えてみました。ここでは、ユーザー(外部システム)入力値に対する検証に限定します。どこでユーザー入力値を検証するべきかユーザー入力値のバリデーションは全て、Presentersion層で行うべきだと考えました。理由は、「Application層に来た時点でユーザー入力値ではない」からです。なので、Application層の引数が不正な場合は、例外(内部エラー)として扱うようにし

ブックマークしたユーザー

pal2hmnk2022/04/25
kaido2017/12/29
JHashimoto2017/12/27
tinsep192017/12/15
clavier2017/12/15
efcl2017/12/15
Hiro_Matsuno2017/12/15
shigeaki1jp2017/12/14
minamijoyo2017/12/14
tsuyok2017/12/14
yo-iida2017/12/14

同じサイトの新着

同じサイトの新着をもっと読む

いま人気の記事

いま人気の記事をもっと読む

いま人気の記事 - テクノロジー

いま人気の記事 - テクノロジーをもっと読む

新着記事 - テクノロジー

新着記事 - テクノロジーをもっと読む

設定を変更しましたx