サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
qiita.com/j5ik2o
本題に入る前に、値オブジェクトの表明を使って検証を実装する方法に、必要な検証(バリデーション)と表明(アサーション)の違いについて以下にまとめる。 検証(バリデーション) 以下のブログ記事によると、3種類のバリデーションがあるようです バリデーションには3種類のバリデーションがある 〜 セキュアなアプリケーションの構造 〜 が、日常的にはこのあたりは区別せずに「入力値の確認」と認識していると思います。厳密に表現すると「入力値が要件を満たしているか妥当性を確認すること」になります。Error, Defect, Fault, Failureの定義と解釈のエラー(Error)のカテゴリ。 以下は、バリデーションロジックの一例。値が満たすべき要件を確認するロジックを記述しますが、場合によっては複数の検証を組み合わせて一つの検証を行うことがあります。 object Validators { type
Help us understand the problem. What are the problem?
こんにちは。 最近、こんなツイートしたのですが、ドメインオブジェクトではなくアプリケーションサービス1などにドメインロジックが書かれてしまうことがあります。 アプリケーションサービスはドメインロジックを配置する場所ではない、それはドメインオブジェクトの役割。アプリケーションサービスは進行役。ここを間違うから簡単にドメインモデル貧血症になってしまうんだと思います。 — かとじゅん (@j5ik2o) August 18, 2019 最近、以下の書籍(以下 増田本)をマジメに読み直しました(笑)。ドメインモデル貧血症2を回避して、ドメインロジックをドメインオブジェクトに凝集させる方法に関して、増田本にいろいろ書いてあったので、そのエッセンスと僕の考察を交えて解説したいと思います3。 詳しい内容は以下の増田本を読んでください! コード例はScalaですが難しい表現がないので、Scalaが分からな
背景 集約とリポジトリなどをアプリケーションサービスやコントローラから呼び出し、書き込みや読み込みの要求を実装することがよくあります。ほとんどの場合、トランザクション整合性の観点から考えると、書き込み要求は集約単位になりますが、読み込みは結果整合性も含めると、複数種の集約を合成した、いわゆるリードモデルを返すことが多いです。この記事では、このリードモデルに起こるN+1問題とCQRSの関連性についてまとめたいと思います。 リードモデルを返す処理 みなさんは、どのようにしてリードモデルを構築していますか? いろいろな方法がありますが、ここでは以下に観点を絞ってみたい。 複数種のリポジトリを使って集約を取得し、リードモデル用DTOに詰め直す リポジトリを使わず、ストレージに対応したDAOで、JOINするような問い合わせを行う 対象のドメイン 話をわかりやすくするために、想定のドメインが必要ですね
このエントリーは、 「ドメイン駆動設計 #1 Advent Calendar 2018」の24日目の記事です。 23日目は、@smdmts さんの「ユビキタス言語と境界付けられたコンテキストを構築する目的とは」でした。 DDD本で触れられている、モデリングパラダイムについて考えを晒します。 まずはモデリングパラダイムについて考えましょう。 目的 「モデリングパラダイム」という言葉をどういう意味を持つのでしょうか。それは、以下の二つの単語で構成されます。 モデリング 広義の意味での模型(モデル)を組み立てる事を言う。 パラダイム ある時代のものの見方・考え方を支配する認識の枠組み。 「モデルを組み立てるための認識の枠組み」と考えてよいでしょう。 DDD本の用語解説では、以下の説明があります。モデリングの「枠組み」や「スタイル」と解釈して問題なさそうです。 ドメインにおける諸概念を切り取る特定
集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話 - kbigwheelのプログラミング・ソフトウェア技術系ブログ 個人的に、非常に面白い記事なので、私見を晒したいと思います。 「上の何が問題?」 のコード例について(細かい指摘) このコードは、ユーザーリポジトリを呼び出す時点で、ドメイン層ではなくアプリケーションサービスの責務に見えます(一般的にドメインオブジェクトは永続化責務を持たないためです)。あと、以下の理由もあり、createは使わない方がよいと思います。createは生成責務に見えるのでユーザファクトリではないでしょうか? あと、Repository#createは、リポジトリなのに生成責務あるの?と誤解しやすいので、Repository#putとか#storeとかのがよいと思いますよw — かとじゅん (@j5ik2o) 2018年11月30日 はい。本
設計するとき、「このオブジェクトの責務は何だろうか?」とか「この責務に名前をつけるなら何か?」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。 責務とは 困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven design)」の原則に従うことが大きいとされています。 この書籍によると、「責務」には以下が含まれるそうです。 「4.1 責務とは何か」 オブジェクトが行う動作 オブジェクトが持つ知識 オブジェクトが他に影響を与える主要な判断 これらの言葉を身近な言葉で置き換える
Scala関西Summit2018に参加してきました。忘れないうちにセッションの感想などをメモとして残しておきます。 初の2days開催とのことで、初日は以下のセッションを見ました。あ、僕も登壇者だったので最後のセッションは僕の自身の感想など含めてます。 http4sとcats-effectで可愛らしい、関数型らしいアプリケーションを書こう!٩(๑^o^๑)۶ circeから学ぶ Generic Programming 入門 ZOZOSUITの裏側はScalaで動いてるよ! セッションを見ずにブース担当 Akkaを分散トレーシングで見てみよう PHPエンジニアによるScalaエンジニアへの転身とその手引き Scalaでつくる証券会社とスタートアップ 自分の登壇枠 セッションの感想 http4sとcats-effectで可愛らしい、関数型らしいアプリケーションを書こう!٩(๑^o^๑)۶ ス
ドメインオブジェクトを中心としたClean Architectureは、どういうレイヤー構成にするとよいか、簡単にまとめてみた。 イメージ たぶん、こんな感じになるはず。通常は円状に表現するが、わかりにくいので層状に書いてみた。 赤い部分の層は、直接依存の方向が上から下です。グレー部分の層は、契約だけが定義された独立した層で、ユースケース層やインターフェイス層から依存できるものとします。 インターフェイス(アダプタ)層 内外とのデータ形式の変換が主な役割 コントローラ、プレゼンター(内部から外部へデータ形式を変換する責務),ゲートウェイ(外部と通信する責務。DBやRPC) ユースケース層 アプリーケーション層ともいう アプリケーション固有のビジネスルールをカプセル化する ドメイン層 Clean Architecture本では、中心にはエンティティとだけ書かれているが、DDDでは中心はドメイ
ScalaでDIコンテナというとGoogle Guiceを使っている人が多いと思うけど、僕は最近airframeを使い始めました。 何がどう違うのというのは以下の記事を読んで欲しい。個人的には、Scalaで使うための設計が前提になっているかが大きいと思っています。Guiceでもいいけど、無邪気に使っているとJava前提のライブラリはハマることもあるし、Scalaの独自機能に対するケアもないので…。 使い方はQuick Startを読んでください。たけぞえさんのブログ記事 「Scala用のDIライブラリAirframeを試してみた」 でも紹介されています。1 以上、終了でもよかったのですが、日本語で簡単に解説しておきます。 最低限知っておくとよいのは、Design, Sessionです。あとは、DIコンテナがサポートするLife Cycleはドキュメントをみてください。DesignとSess
昔書いた記事ですが、今回は続編です。 DDDのリポジトリのインターフェイスをどのように設計すべきか 過去の実装は一旦捨てて書き直してみました。 scala-ddd-base/reboot 前回と比べて改善した点は以下です。 Try, Futureなどの個別の型向けのtraitを作らない IO用コンテキストをリポジトリメソッドから追い出した 型パラメータの数を減らす 型クラスとTagless Final 同期版、非同期版というようにトレイトや実装を分けていくと複雑になりがちなので、以下のようしました(実装は???ですが、詳細はgithubを参照してください) 型パラメータはM[_]だけになります。高階型というやつです。ID型は抽象型メンバーにすることで型パラメータの数を減らしました。 trait UserAccountRepository[M[_]] extends AggregateSin
ケースクラスをJSON化するときにフィールド名を自動的にスネークケースにする方法(circe-generic-extras)Scalacirce 目的 できるだけEncoder/Decoderを書かずに、ケースクラスをJSON化したいときは、import io.circe.generic.auto._, io.circe.syntax._をインポートして hoge.asJsonとすればよいが、キャメルケースのフィールド名がそのままJSONに出力されてしまう。これを簡単にスネークケースにできないか? という感じでツイートしてたら教えてもらいました。それを共有します。 import io.circe._ import io.circe.syntax._ import io.circe.genric.auto._ case class UserName(firstName: String, la
皆様、御機嫌よう かとうです。 このブログ記事は、Scala Advent Calendar 2014 23日目の記事です。 最近、sprayを使っているので、簡単なチップスを公開したいと思います。 sprayとは Akka ActorベースのREST APIを実装するためのフレームワークです。Benchmarking spray によるとJVM最速の部類に入るようです。詳しくはここみてください。 spray-can spray-canを利用するとHTTPのリクエスト/レスポンスのハンドリングをActor上で扱えるようになります。実装コード例は以下です(詳細は こちら を見てください)。HTTPのリクエストをリアクティブにハンドリングできます。 class DemoService extends Actor with ActorLogging { // ... def receive =
このページを最初にブックマークしてみませんか?
『@j5ik2oのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く