はてなブックマーク

Scala 3におけるデータ指向プログラミング（以下DOP）について深掘りする。久々にScalaの話題を取り上げるが、これはScala Advent Calendar 2023の14日目の内容でもある。 早速だけど、DOPの基本原則は意外とシンプルだ。 コード（動作）をデータから切り離す データを汎用的なデータ構造で表現する データをイミュータブル（不変）として扱う データスキーマをデータ表現から切り離す イミュータブルなデータは採用することは多いと思うが、これをそのまま実践している人はどのくらいいるだろうか。Scalaではクラス中心の関数型プログラミングが主流だと思うし、私もそうしている。 DOPの詳細は下記の本(以下DOP本)を参照してほしい。 データ指向プログラミング 作者:Yehonathan Sharvit翔泳社Amazon ちなみに留意すべき点がある。DOP本とJavaのPro

「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と

kumagi.hatenablog.com こちらの記事への反応です。 違う。値オブジェクトとはID以外で等価判定をするオブジェクトの事であって、RubyのHash、Pythonのdict、C++のstd::unordered_setすらも値によって等価判定を行うのでこれらは値オブジェクトであるがドメイン固有型ではない RubyのHash、Pythonのdict、C++のstd::unordered_setは、アプリケーションのドメインからみるとインフラストラクチャに見えるかもしれません。 しかし、RubyのHash、Pythonのdict、C++のstd::unordered_set であっても、解決する問題領域(ドメイン)があります。なので、そのドメインにとっては、ドメイン固有型(=ドメインオブジェクト)である、と解釈しています。(ドメイン固有型の”固有”が紛らわしかったかもしれません

Value Objectが盛り上がっているらしい。 Value Objectについて整理しよう - Software Transactional Memo Value Objectの説明に異論がないものの、主題はValue Object Obsessionのほうですよね。 こちらも聞いてみた。 fukabori.fm よい機会なので、よくわかっているつもりの、値オブジェクトというかドメイン固有型について再考してみよう。 それは値か属性か それはエンティティの全メンバーやデータベースの全列のために「顧客郵便番号」「送付先郵便番号」「事業所郵便番号」「契約日」などのクラス(メンバではなくクラス！)を定義して、immutableな振る舞いを強制する事を以てValue Objectであると言い張り、ドメイン知識の断片をそれぞれのクラスに書き散らして「高凝集になった」「型システムが守ってくれる」と喜

この記事はRust Advent Calendar 2021の12/24日の記事です。 仕事ではScalaを使っていますが、趣味のプログラミングではRustで書いたものが増えました。Rustは楽しいですね。 今回は、Rustでオブジェクト指向プログラミングに関数型デザインを導入することで、スケーラブルなプログラムを書く方法(スケーラブル・プログラミング)について書きます。 「スケーラブル・プログラミング」といえばScalaです。Scalaの「スケーラブル」という言葉には「小さいプログラムも大規模なプログラムも同じ概念で記述できるべきである」という、柔軟性や拡張性を重視した設計の意図が込められています。それを実現するために必要なものは、オブジェクト指向と関数型を組み合わせたマルチパラダイムな設計です。 Scalaはマルチパラダイム言語の先駆者(今も先頭を走り続けています)ですが、他の言語にも

この記事はRust Advent Calendar 2021の12/8日の記事です。 Rust前提の記事として書きましたが、他の言語にも適用できる考え方なので、ほかの言語勢の方々もよければお付き合い下さい。 今回のテーマは「Rustで真に安全なプログラムを書く方法」についてです。 「真に安全なプログラム」の定義は以下とします。 挙動が安定し、結果が予測可能となる 正しさの基準に基づき、プログラムの間違いを検知することができる 「真に」とはドメイン知識に基づく正しさという意味です。詳しくは後述します。 それと「そもそもRustで実装されるプログラムは安全じゃないのか」という想定質問については「メモリの操作は安全。だが、それだけでは真に安全なプログラムにはならない」が答えになります。これについて興味がある方、ぜひ最後までお付き合いください。 「真に安全なプログラム」を実現するレシピとしては「関

どうも、かとじゅんです。 松岡さん(id:little_hands)が以下の記事を更新されたそうです。松岡さん自身が悩まれた中で検討したオプションであって、唯一の正解ではないと踏まえたうえで、率直な感想を述べたいと思います。結論からいうと、論旨は前回の記事と変わりませんが、コード例で具体的な考え方を示している点を工夫しています。 little-hands.hatenablog.com 前回の考察記事も古くなったので、最新の記事に併せて考察をまとめ直したいと思います。 blog.j5ik2o.me ドメインモデル ドメインモデル図が追加されていますね。以下の３つの集約があるそうです。「一つの集約にまとめればいいよね」という提案はなしという前提で考えます。 ユーザー タスク アクティビティ・レポート 「アクティビティ・レポート」は「タスク」もしくは「ユーザー」に関連を持つようです。 「これらの

久しぶりにブログ記事を書きますか。 ということで、松岡さん(id:little_hands)のブログ記事に対する考察記事です。 この記事は古くなったので、ぜひ以下も参照してください。 blog.j5ik2o.me little-hands.hatenablog.com 題材も松岡さんのブログ記事と同じもので考えます。 「実装方法1. ユースケースで複数集約を更新する」について考察したいと思います。 注意事項）この記事で使うトランザクションという用語は単なる一連の手続きという意味ではなく、ACID特性を持つRDBのトランザクションという意味です。 class CreateTaskUseCase1( private val taskRepository: TaskRepository, private val taskReportRepository: TaskReportRepository

掲題についての議論です。 僕の結論はこちら。"モジュール分割せずにモデルを分割するだけ"はCQRSと呼んでいけないのでは？まず原義からちゃんと把握しようというお話。 CQRSするにはC/Qは独立しないとダメなので、それをどう連携させるかすごい難しい課題。ESなしでは独立させて統合するのはほぼ難しいと思います https://t.co/Ta0CYujHJx— かとじゅん (@j5ik2o) 2020年9月17日 sipadan2003.blogspot.com Gregさんの原義によると Origins 起源 Command and Query Responsibility Segregation uses the same definition of Commands and Queries that Meyer used and maintains the viewpoint that

CQRSはなぜEvent Sourcingになってしまうのか、まとめてみたいと思います。 なぜまとめるか、それはCQRSにとってEvent Sourcingはオプションだと誤解されている方が多いからです。この記事を書いてる本人も最初はそう思っていましたが、実際に開発・運用を経験してみるとCQRSにとってEvent Sourcingはほぼ必須で、認識を改めるべきだと気づきました。なので、原義に基づいたうえで、Event SourcingではないCQRSがなぜよくない設計になるのか解説します。 その前に松岡さんの記事について。 CQRSの領域ではモデルを完全に分ける 松岡さんの記事には”CQRSはモデルを完全に分ける必要はない”と書かれていますが、知識がないと誤解しがちですが文字のまま意味を取るといけません。こちらの言及は、システムのうち、モデルをC/Qに分割するCQRS領域とモデルを分割しな

DDD Community JPのほうでCQRS/Event Sourcingについて少し盛り上がったので、どういう議論をしたかまとめるのと同時に補足も追加しました。ちなみに、Event Sourcingが主題ですが、CQRSも前提として関係します。その想定で読んでいただければと。 発端はこのツイート。 これはEvent Sourcingじゃないと無理ですね。状態に基づく限り、ストリーム処理は難しいです https://t.co/prB16GJC5q— かとじゅん (@j5ik2o) 2020年9月14日 僕が引用したツイートは松岡さんの質問箱に対するリアクションです。その質問箱に寄せられた質問は以下。 ストリームを開いてから閉じるまでのデータが変化する毎にUIで表示したい場合、DDDではどのように設計したら良いでしょうか？ DDDのリポジトリは1つのリクエストに対して1つのリクエストを返

このブログが話題になってますね。制約を付けること自体はよいことだけど、無目的に適用すると害も生じると思います。 無目的という言い方はおかしいな…。外部キー制約をどのように使えばいいのか、逆にどんなときに使うとまずいのかを考えてみたいと思います。 tech.tabechoku.com 例えば、これ。外部キー制約はできるだけ付けるとか、何も考えずに付けるとよくないと思います。 外部キー制約は、可能な限りつけるようにしています。 DBが別れている場合、外部キーはもちろん貼れないのですが、そうでない場合はとにかく何も考えず貼っています。データベース設計の際に気をつけていること - 食べチョク開発者ブログ テーブル設計をシミュレーションする いいたいことの結論はこれ。以上終了なのですが、もう少しわかりやすく書いてみよう。 何も考えずに外部キーを貼るのは良くないな。トランザクション境界の外で結果整合性

peing.net メッセージングシステムのお題のようです。面白そうなのでちょっと考えてみよう。 問題提起 集約候補が以下の3つ。 ユーザー 企業 スレッド メッセージ スレッド集約はメッセージを複数保持するようです。 1000件のメッセージを保持するスレッド集約を更新した際、1000件のアップデートが行われる スレッド集約内部で更新された属性を把握していない場合は、リポジトリでは全メッセージ分の更新となる。これを避けるための仕組みはどう実装するのか？ ということが指摘されている。まぁわかります。これはCQRS/ESなら解決できるよと言ってみる 問題の分析 で、僕ならどう考えて実装に落とすかつらつらまとめてみよう。CQRS/ES前提です。Akkaの成分は少なめでScalaの擬似コードで解説します。コードはコンパイルしてないので…おかしなところあるかも。 問題はスレッド集約がメッセージの集合

引っ越しました。 ID生成方法についてあれこれ

移動しました。 https://zenn.dev/j5ik2o/articles/6c4dbab802c9701fd878

Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから

最近、ドメイン駆動設計ってどうやって実践すればいいかなーという質問をよくされるので、この記事が満額回答にはならないと思いますが、書いてみたいと思います。 シンプルな問題はトランザクションスクリプト、いわゆる手続き型で対処できます。問題が小さいのでコードは直接的でわかりやすくなる傾向にあります。 とはいえ、世の中の問題はシンプルなものばかりじゃない。複雑な問題もある。DDDの著者であるEric氏は、複雑な問題はドメインモデルを使って対処すべきと説く。 ドメインとは問題の領域とか知識の範囲をいうのですが、DDDはそのドメインにある概念をモデル(ドメインモデル)として定義して、さらに実装として紐付けていく設計手法です。 モデルクラスは概念ありき 例えば、電車にまつわるドメインで考えたとしたら 電車 乗客 駅 ダイア などの概念が登場します。 現実世界に限った話ではなく、仮想世界でもドメインはあり

(Scala前提の記事なので注意してください) たとえばこんなモデルがあって、相互に依存しているケースを考えよう。 注意:説明を簡単にするために、varを利用しています。 従業員 class Employee( val id: Long, val name: String, var department: Option[Department] = None ) 部署 class department( val id: Long, val name: String, var employees: Seq[Employee] = Seq.empty ) 利用例 val employee = new Employee(1, "KATO") val department = new Department(1, "Dev") employee.department = Some(Department

おはこんばんにちは、かとじゅんです。 久しぶりにブログを書く…。最近、趣味でAngular2やらReactやらやっています。やっとWebpackになれました…。 さて、今回のお題は「FluxとDDDの統合方法」について。Angular2を先に触っていましたが、FluxといえばやはりReactだろうということで途中で浮気してReactで考えています。Angular2でもできるはずですが、今回はReactで統合方法*1について考えてみたいと思います。一つ断っておくと、FluxはDDDと統合することを想定していない設計パターンなんで云々とかはここでは考えていません。それはこのブログ記事を読む読まないに関わらずご自身で判断されてください。ソースコードについては、Githubへのリンクを一番下に書いてあるので興味がある人は参考にしてみてください。 Fluxって何？ まず基礎ということで、Flux i

面白そうなネタがあったので、自分なりの考えをまとめてみる。 Ruby/Rails 用 DI コンテナ Dee をつくった、あるいは Ruby のカルチャーについて この記事はRuby用のDIコンテナの話題なんですが、DCIについても言及されているようです。比較軸はDIそのものというより、サービスとDCIだと思うので、それについてダラダラといくつか考えをまとめてみます。多分返事になるようでならないかも。それと宗教上の都合でDDDの視点から書きます...。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメイン

昨日もDDDの話題を少ししたので、シナリオ→モデル→コードのサイクルについて身近な例を踏まえてネタを提供できないかと思った。何でもいいんだけど、鍼とか整体とかマッサージとか一度は行った経験あると思うので、そのドメインで考えてみるか。 実際は仕事に詳しい人を、ドメインエキスパートにした方がいいだろうけど、今回は自分でやってみる。 シナリオからドメインモデルを考える ドメインモデルにでてきそうな概念を、ひとまず人モノなどのリソースから考えてみたい。 患者 施術師 施術方法 まずはこれぐらいから。 このドメインは、患者が施術師の時間を予約することが目的です*1。 簡単にシナリオを考えてみる。 患者が施術師の空き時間を予約できる。 患者が施術師に予約を要求(以下, 予約要求)する。 予約要求には、患者番号, 開始日時, 施術方法が必要。 施術方法には、マッサージ30分コース、マッサージ60分コース

社内でサービスがよくわからないという話になったので、考察を少しまとめておきます。 過去のエントリでも以下のように触れましたが、もう少しかみ砕いてみよう。 サービスという言葉はあいまい まず、簡単に前提の整理から。単に"サービス"って言葉が何を指すのか結構曖昧です。 サービスは簡単にいうと手続きとか振る舞いのことですが、細かくいうと、PofEAAでいうサービスと、DDDいうサービスは、目的が異なります。前者はアプリケーションのためにドメインモデルを再利用可能にするためのものです。後者はドメインの知識を表している振る舞いです。これはのちほど詳しく説明します。 まぁこのあたりは具体例がないと理解しがたいですが、レイヤーの違いによって責務が異なるという感じです。DDDのサービスの章では、サービスには、アプリケーション層、ドメイン層、インフラストラクチャ層と、複数のレイヤーに存在すると言及されていま

超久しぶりのブログ…。 Octopressに疲れたのではてなブログに戻ってきました(Octopressの過去の記事ははてなブログにインポート済です)。ついでプロに移行。 さて、海外のDDDコミュニティではCQRS+Event Sourcing(以下, ES)が人気なのですが、ようやく日本でも話題になることが多くなったので今回は教材となりそうな書籍を簡単に紹介したいと思います。 DDD といえば まず エリック・エヴァンスのドメイン駆動設計 (以下 DDD本) を読むべきですが、CQRSについては記載がないので 実践ドメイン駆動設計 を読みましょう。 実践ドメイン駆動設計 作者: ヴァーン・ヴァーノン出版社/メーカー: 翔泳社発売日: 2015/03/19メディア: Kindle版この商品を含むブログ (2件) を見る さらにDDD本には ES の基礎となる ドメインイベント の解説が含まれ

commons-daemonを使ったら、NettyServerをちゃんとLinuxのデーモン化できた。 https://gist.github.com/2156447

2/28日付けでドワンゴを退職しました。お世話になった会社なのでちゃんとお礼をいっておこうと思います。 初めてのコンシューマ向けウェブサービスでした。とてもよい経験をさせてもらいました。ありがとうございました。 一番大きいところは、ScalaとDDDを採用したサービスを開発してリリースしたってことですね。そのあたりの詳しい話は Scala Conference 2013 で聞けると思います*1。 Scalaで開発した感想ですが、よく話題になる習得コストはそれほどかからなかったように思います。ある程度先にScalaをやっている人がいれば、その人を軸に最初は命令型(var)で書いて言語仕様も部分的な理解でも問題なかったですね。慣れてきたらvalのコードに挑戦するとよいですね。valでコードが書けるとより関数型スタイルになるので、コードが理解しやすくなります。 こういう風に段階的に学習して、プロ

今日は、カリー化と関数の部分適用の話題。 Haskellの視座からScalaのカリー化と部分適用を見てみる まず、Haskellでの関数のカリー化と部分適用についておさらい。 例えば、引数を合計する関数 mysum があるとして、 mysum :: Num a => a -> a -> a -> a mysum a b c = a + b + c 次のようにすると当然期待値を得ることができます。まぁ当然ですね...。 ghci> mysum 1 2 3 6 しかし、このコードをJava脳を用いて読んだ場合、 mysum(1,2,3) のように読んでしまいがちですが、次のように読むのが正解です。 ((mysum 1) 2) 3 Haskellでは関数は必ず一つの引数を取るという考え方があり、2個目の引数は1つ目の引数を取る関数の引数として渡されます。3つ目以降も同様です。これを関数がカリー化

Scalaでもリトライハンドラ*1が欲しくなったので、このブログを参考に作ってみた。 Ruby の retry-handler が激しく便利そうなので Java で実装してみた - YoshioriのBlog 試行錯誤してたら、id:xuwei がforkしてくれていた！→ https://gist.github.com/2996927 参考になりました。 allCatchのほうがよさげだったので、結局以下のような感じになった。 例えばこんな使い方ができます。ConnectExceptionもしくはIOExceptionが発生した場合は3秒間隔で3回までリトライができます(第三引数には関数も渡せます)。リトライ上限回数をオーバーした場合はRetryExceptionがスローされます。retryが成功した場合はちゃんと戻り値を取得できる。これは便利です！ import RetryUtil._

http://atnd.org/events/22899 @yusukeyに絡まれたので、しょうがなく我が家秘伝のJIRA黒魔術をざっくり公開します。。。 JIRAはワークフローを柔軟に扱えることが一つの魅力です。 たとえば、ストーリチケットを作成するときに、ストーリポイントは必須だよね。ストーリチケットだからね。でも、ストーリポイントを必須項目にするとストーリポイントが決まっていない状況では起票できないし、必須でなくしてしまうと未入力のままの可能性がある。 思いついたときに起票して、ストーリポイントも入力漏れを防ぐにはどうしたらよいか。 ワークフローをいじる 簡単です。チケットが開始状態になるまでは未入力だけど、開始するときには必須ってワークフローを書けばいいのです。 ワークフローを超ざっくり説明すると、、、ワークフローには、オープン、開始、処理中、解決、クローズとかの"状態"があります