Collection pipelines are a programming pattern where you organize some computation as a sequence of operations which compose by taking a collection as output of one operation and feeding it into the next. (Common operations are filter, map, and reduce.) This pattern is common in functional programming, and also in object-oriented languages which have lambdas. This article describes the pattern wit

より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ

より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料：http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ

BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/

Auto-generate on. Press Ctrl+E to force regenerate image. UPDATE: March 26th 2020 - We're fixing issues with the new parser as they get reported. Sorry if we broke you diagrams! See here for more information.

システム開発における言語的要素の重要性について、書籍を参照しつつ私見を整理する。 導入 世の中には「文系プログラマ」という表現がありますが、私もそのカテゴリに入る人間です。それも文系度はかなり高く、文学部でいわゆる思想史的なことを勉強していたんですね。文系の思想研究とソフトウェア開発との間には、かなり深い溝が横たわっていると思う人が多いですし、私自身も当初はそう思っていたのですが、時間が経つにつれて両者の間には相通じるものが確かにあると考えるようになってきました。それはどちらも本質的には「言葉」を扱うものだということです。特定の処理はどう実現するかよりはむしろ、どう表現するかという問題であるということですね。より正確に言うならば、この実現手段と言語的表現を限りなく近づけることができるパラダイムがオブジェクト指向である、ということなのかもしれません。 特定の抽象度からある概念を捉えること。そ

Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

Eric Evans氏の名著"Domain-Driven Design"第17章より、戦略的デザイン（"Strategic Design"）のためのエッセンスをまとめた部分について要約とコメント。 Six Essentials for Strategic Design Decision Making 決定はチーム全体に行き渡らなければならない 戦略はメンバー全員が知る必要がありますが、かといって中心にすえられるのが「象牙の塔のアーキテクト」だとうまくいきません。コミュニケーションがうまくいっているプロジェクトでは、アプリケーションチームから発生した戦略的デザインこそが全体に行き渡り、正しい意思決定をする上での権威を持ちます。どんなシステムであっても大切にしなければいけないのは、マネジメントによって与えられた権威よりも開発者が戦略に対して持つ実際の関係なのです。 決定のプロセスはフィードバッ

標準のライブラリが使いにくいとき、つい XXXUtils のようなクラスを作ってしまいがちです。 例えば、悪名高き java.util.Calendar。来年の2月15日が何曜日か調べようと思ったら、次のようなコードを書かなければなりません。値の取得も設定も面倒で、なぜか月が0始まりになっています (歴史的な制約?)。 Calendar calendar = Calendar.getInstance(); calendar.add(Calendar.YEAR, 1); // 2月は month = 1 calendar.set(Calendar.MONTH, 1); calendar.set(Calendar.DAY_OF_MONTH, 15); // 文字列に変換する場合は、DateFormat を使用する。 DateFormat df = new SimpleDateFormat("E

「Model View Controller」や「モデル駆動」など、ごく当たり前に使用されるようになった「モデル」という言葉をDDDに準拠しながら再考する。 導入 「オブジェクト指向」「モデル駆動」「ドメイン駆動」という表現はすっかり日本語として定着しており、ある一定の共通認識も出来上がってきているように感じます。しかし、「オブジェクト」「モデル」「ドメイン」という概念が本当にきちんと日本語としての文脈の中に位置づけられているのかというと、結構怪しいことも多いのではないでしょうか。このあいまいさの原因ははっきりしていて、向こうの国で膨大な文脈の中に位置づけられている単語を日本語にすることなく、なんとなくカタカナで表現してしまっていることでしょう。もっとも、この悪い癖は今に始まったことではなく、「エラン・ヴィタール」や「ルサンチマン」に見られるように、それなりの歴史があるのかもしれませんが。

What's New in PHP 8.3 PHP 8.3 is the latest major update in the PHP 8.x series. In addition to performance improvements, it brings a wealth of new features, including amendments to the readonly feature introduced in PHP 8.1; explicitly-typed class constants; a new #[\Override] attribute for methods intended to be overridden from a superclass, and more.

あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;

前ブログの続き。。。 土曜日日曜日に、「サンデーソングブック」という山下達郎のFMラジオ番組があり、愛聴しているのだが、そこで取り上げられる楽曲は「時代を超えて残る曲」だ。達郎自身、「長く残る曲というものはどういう特徴を持つものか、に興味がある」と言っていた。 これに触発され、より長く残る価値観、を見つけて、それを後輩たちに伝えたいと思う気持ちが僕の中で最近高まってきている。前ブログでは、ずっと「よい設計とは」として残り続けている設計の特徴を挙げた。 オブジェクト指向技術について、ここ２，３年は「先祖がえり」というか、「長く読まれるであろう価値観に焦点を当てた本」が出ていることも動機の１つだ。 Rebecca Wirfs-Brock の『オブジェクトデザイン』 Eric Evan の 『Domain Driven Design』 Ken-Pughの『インターフェイス指向設計』(※1/5追記