少しだけ論理的に本を読んでみよう

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

技術書を読むという習慣はみなさん持っていると思います。
技術書を消化しようと思った時、みなさんはどのようにされているでしょうか?
写経をしたり、議論をしたり色々な方法があるかと思います。

今回はもう一つの選択肢として、「少し論理的に読んでみる」という方法を紹介したいと思います。

と言っても、それほど難しいわけではなく、

① 主題はなにか?(何について書かれているか?)
② 問題はなにか?(何が問われているのか?)
③ 主張はなにか?(どう答えるのか?)
④ 根拠はなにか?
について考えながら読むだけです。

たとえば、ドメイン駆動設計本のコアドメインなら、

主題(何について)
巨大なシステムのドメインについて。

問題(何が問われ)
巨大なシステムは複雑なので、ビジネス資産がどこだかわからない。ドメインの全体像が見えづらい。設計が理解しにくいときに起きる問題と同じことがおきる。その解決策。

主張(どう答えるのか)
モデルの重要なコアを洗練する。

根拠
設計はすべての部分が等しく改良されるわけではないから、その中でもコアを洗練することによって、最も価値のある特化した概念を浮き彫りにする。

と考えることで要約もできて、理解も進みやすくなり、議論の元にすることもできるのではと思います。

また、ソフトウェアの設計というのが、ビジネスモデルの要約だと考えるならばこのような練習が設計のスキルアップに役に立つのではないかと、個人的に思っています。

そして、もっと論理的な考え方を身につけたいと思う方にお勧めの本が「新版 論理トレーニング(野矢茂樹 著)」です。

この本の例題を引用してみます。

タコは8本足である。
ジョロウグモはタコではない。
だから、ジョロウグモは8本足ではない。

どうでしょうか。何か違うのがすぐわかりますよね。

では、これはどうでしょうか?

思考は閃きを必要とする。
頭のよい人は閃きを得る力に恵まれている。
つまり、頭のよい人は思考力もある。

ぱっと読むと正しそうに見えませんか?
どこがおかしいか、ぜひ考えてみてください。

上記の例は「新版 論理トレーニング」の中の例題ですが、実際のWebや新聞の記事なんかでも論理的におかしいと気づくことがあります。

考えながら本を読むのは大変疲れますが、技術書のみならず、いろいろなジャンルの本やWEBの記事を読む際などにもきっと役に立つと思います。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

禅とソフトウェア設計技術

心の落ち着きは、技術的作業にとって決して表面的なものではない。これこそが重要なものである。心の落ち着きを生み出すものは、優れた仕事であり、それを破壊するものは悪い仕事である。仕様書、計量器機、品質管理、最終点検などはすべて、作業責任者に心の落ち着きを与えるための手段である。ここでは心の落ち着き以外に重要なものは何ひとつない。なぜかといえば、心の落ち着きこそが例の <<クオリティ>> を知覚するための前提条件だからである。

(※ 禅とオートバイ修理技術より(単行本 下巻164ページ) )

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

ソフトウェアにとって、心の落ち着きをもたらしてくれるもの、つまりは優れた仕事、 <<クオリティ>>を知覚できるものは何でしょうか?

Excelの設計書?
トランザクションスクリプトなソースコード?

これらを注意深く、完璧に仕上げたとして心に落ち着きを与えられるでしょうか?

変わり続ける仕様・業務の知識・ビジネス、100%なくすことができないバグが存在する前提がある以上、ソースとドキュメントとの乖離があるのではないかという不安と、ソースコードを変更するたびに他にも影響があるのではないかという不安は消えないのではないのでしょうか?

であれば、ソースコードに変更を加えることが容易になる設計手法こそが心に落ち着きを与えうる設計であると言えると思うのです。

私たちは、ドメイン駆動設計にその活路を見出し取り組んでいます。

それにしても、「心の落ち着き」と「<<クオリティ>>」を結びつけるということに意外であると思う一方、ソフトウェアに携わってきた経験上、妙な納得感がありました。
設計手法以外にも深夜・休日まで仕事をしてしまう、少ないコミュニケーション、要件定義・設計・開発など工程でチームが分かれる・・・などなど心を乱す要因はいろいろありそうですね。

最後に、心の落ち着きを生み出すために美味しい一杯のコーヒーを飲みましょう。。。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

エンティティの識別子をラップしたクラスを用意するとよい理由

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。

今回は、ドメイン駆動設計における、エンティティの識別子の実装面について考えてみたいと思います。(あまり本質的な話題でなくてすみません。。。)

エンティティの識別子、どう実装していますか?

私の場合、以下の図のようにエンティティが直接LongやStringなどプリミティブの型で持ってもよいと思っていました。エンティティの識別にしか使われないのでエンティティが直接持っていた方が使いやすいと思っていたのです。

VoyageClass

ドメイン駆動設計本の例はどうでしょう・・・。

ドメイン駆動設計ではプリミティブの型を使用している例も載っていますが、書籍内のサンプルを実装したDDDSampleではVoyageNumberやTrackingIdなど識別子をラップしたクラスを使ってます。

VoyageAndVoyageNumberClass

実践ドメイン駆動設計本では日付時刻を含んでいるような識別子を例にあげてこのような複雑な識別子はラップしたクラスを使うべきとあります。

要は識別子の複雑さや使われ方によるのかなと思います。

という曖昧な結論では記事になりませんので、識別子用のクラスを持つことで効果がでるケースを紹介したいと思います。

例は、よくある求人サイトの想定で、求職者が求人に応募するようなモデルです。

まずは、求人パッケージ(モジュール)。
求人

そして、求職者パッケージ(モジュール)。
求職者は求人に応募しますので、応募クラスは求人IDクラスを持っています。
求職者

・・・と、クラス図だけではなんてことないのですが、パッケージ図を見るとこうなります。
求人サイト

これが求人や求職者の識別子がプリミティブな型の場合は以下の通り依存関係を持つことはありません。

求職者2

求人サイト2

実装上はこれでも問題ないのですが、ドメインの知識をソースコードに反映するということを考えると、パッケージ間の依存関係がきちんと表現できるとよりわかりやすい設計になると思います。

エンティティの識別子はそのエンティティの同一性を保証してあげるだけの役割ですので、わざわざラップして使う必要がないと思いがちです。
しかし、ラップして使うことで、プリミティブな型をそのまま使うことに比べてモデルをより豊かに表現することができ、ドメインの知識をより深く理解する手掛かりとすることができます。

ぜひ試してみてください。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

※ アイキャッチ画像(Original Update by paurian https://www.flickr.com/photos/paurian/3707187124)

ドメイン駆動設計の探求 其の一 モデルと実装を協調させる、とはどういうことか

どうも、ギルドワークス 前川です。 以前ご紹介した通り、ギルドワークスではドメイン駆動設計(DDD)の勉強会を社内で行っています。 その中で出てきた指摘に、ハッとする物があったので、今回はそれについて、ご紹介します。

「それ、ソースコードに書いてないじゃん」

それは、DDDを前提においたコードレビューで飛び出した指摘でした。

コードはかなりシンプルな、ユーザからの投稿とそれに関する感想を閲覧する、といったサービスに関するものでした。 こういった場合、当然のように、『”投稿”がトップレベルのオブジェクトにあり、それにぶら下がる形で”感想”オブジェクトがある』という様なモデル化をしていました。

一方このドメインにおいては、投稿もさることながら、投稿に対する感想の方がドメインにおける重要な関心事、なのでした。

それを話した時に、弊社増田の口から飛び出たのが、、、

「んで、それはソースコードの何処に書いてあるの?」

実装に構造を語らせるために

この時、僕は軽く衝撃を受けました。

「だって、ソースコード見てそのドメインの関心事が分からなければ、3年後見た時にわかると思う?」

…はい、分かりませんよね。そりゃあ。

そう、エヴァンスのDDD本に書いてあった、以下の一節は、そういうことを言っています。

ある種の意思決定をすることによって、モデルと実装の協調が保たれ、互いがもう一方の効果を高めるようになる。

— 『エリック・エヴァンスのドメイン駆動設計』 第二章の導入より

モデルと実装が、協調している。モデル通りの実装になっているし、実装からモデルがわかる。そのモデルというのは、ただの設計構造ではなく、顧客の関心ごとを反映した「ドメイン」である、ということ。

ではどうすればいいのか?

「それに答えなんかないですよ。色々実験してみることです。例えば、感想が重要な関心事なら 主従関係をひっくり返して、感想を投稿の親にしてみては?」

確かに、ソースコードで物を語るには、クラスの所有関係を表すのが一番です。なんとなく、理屈で収まりがいいツリー構造を考えてしまいますが、勇気を持って構造を組み替えたりして、色々実験しなければなりません。

確かに、DDDではリポジトリという形で、永続化処理をドメインから分離しています。そうすることで、永続化層の理屈をドメインから分離し、ドメインの中で腹落ちするようなモデルを構築していくのですね。

ドメインの設計を、ソフトウェアシステムにおけるその他の大量の関心事から分離することで、設計とモデルとのつながりが非常に明確になる。

— 『エリック・エヴァンスのドメイン駆動設計』 第二章の導入より

と、偉そうなことを書いていますが、私もまだまだ勉強中の身。これからも色々と実験を重ねていきたいと思います。

ギルドワークスでは、こうやってドメインのあるべき構造を追い求めてくれるような、ギルドメンバーを引き続き募集中です!興味を持たれた方は、こちらからどうぞ

新しく「ドメイン駆動設計のパターン・原則・プラクティス本」が出ました

井上です。 以前、本ブログでドメイン駆動設計(Domain-Driven Design 以下 DDD)のリファレンス本について紹介致しました。 おかげさまで非常に多くの方にご覧頂いたようで、DDDの注目度を改めて感じました。 また、「エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本) に続く2冊目ドメイン駆動設計本として、「実践ドメイン駆動設計」(以下 DDD実践本) も出版され、日本におけるDDDへの注目度がさらに増しているように思います。 私自身、普段からDDDを用いた開発を行っているので、日本語で多くのDDD情報が入手できることはとても嬉しい限りです。 そんな中、DDDを冠した「Patterns, Principles, and Practices of Domain-Driven Design」という新しい本 (以下 DDDパターン・原則・プラクティス本) が 2015/4/20 に出版されたようです。

Patterns, Principles, and Practices of Domain-Driven Design

私自身、まだ購入したばかりで流し読みしか出来ていないのですが、簡単に紹介したいと思います。

DDDパターン・原則・プラクティス本とは

本書は、大きく4つのパートから構成されています。概要は以下の通りです。

  • PART I – DDD の哲学 (philosophy) 、原則 (principles) 、プラクティス (practices) について
  • PART II – 境界付けられた境界 (bounded contexts) を統合する 戦略的パターン (strategic patterns) について
  • PART III – 効果的なドメインモデルを作るための 戦術的パターン(tactical patterns) について
  • PART IV – ドメインモデルを活用し効果的なアプリケーションを構築するために適用可能なデザインパターン (design patterns) について

戦術的パターンより戦略的パターンが先に紹介される構成となっており、その点はDDD実践本と同じですね。 また、本書は792ページと非常にボリュームがあります。 DDD本が560ページ、DDD実践本が 656ページであることと比較しても、そのボリュームがわかると思います。 なお、DDD本とDDD実践本のサンプルコードはJavaで記述されていましたが、本書はC#で記述されています。

章構成

具体的な章構成は以下のようになっています(日本語訳は私が付けたもので、正式なものではありません) 各パート・章のタイトルを見ていただければ、どのような内容になっているのかある程度想像がつくのではと思います。

  • INTRODUCTION
  • PART I: THE PRINCIPLES AND PRACTICES OF DOMAIN-DRIVEN DESIGN (ドメイン駆動設計の原則とプラクティス)
    • CHAPTER 1: WHAT IS DOMAIN-DRIVEN DESIGN? (ドメイン駆動設計とは何か?)
    • CHAPTER 2: DISTILLING THE PROBLEM DOMAIN (問題ドメインの蒸留)
    • CHAPTER 3: FOCUSING ON THE CORE DOMAIN(コアドメインに注目する)
    • CHAPTER 4: MODEL-DRIVEN DESIGN(モデル駆動設計)
    • CHAPTER 5: DOMAIN MODEL IMPLEMENTATION PATTERNS(ドメインモデル実装パターン)
    • CHAPTER 6: MAINTAINING THE INTEGRITY OF DOMAIN MODELS WITH BOUNDED CONTEXTS(境界づけられたコンテキストのドメインモデルの整合性を維持する)
    • CHAPTER 7: CONTEXT MAPPING(コンテキストマッピング)
    • CHAPTER 8: APPLICATION ARCHITECTURE (アプリケーションアーキテクチャ)
    • CHAPTER 9: COMMON PROBLEMS FOR TEAMS STARTING OUT WITH DOMAIN-DRIVEN DESIGN (ドメイン駆動設計から始めたチームの共通問題)
    • CHAPTER 10: APPLYING THE PRINCIPLES, PRACTICES, AND PATTERNS OF DDD (DDDの原則、プラクティス、パターンを適用する)
  • PART II: STRATEGIC PATTERNS: COMMUNICATING BETWEEN BOUNDED CONTEXTS(戦略的パターン:境界づけられたコンテキスト間のコミュニケーション)
    • CHAPTER 11: INTRODUCTION TO BOUNDED CONTEXT INTEGRATION(境界づけられたコンテキストの統合の概論)
    • CHAPTER 12: INTEGRATING VIA MESSAGING(メッセージングによる統合)
    • CHAPTER 13: INTEGRATING VIA HTTP WITH RPC AND REST (RPCやRESTを用いたHTTPによる統合)
  • PART III: TACTICAL PATTERNS: CREATING EFFECTIVE DOMAIN MODELS(戦術的パターン:効果的なドメインモデルの構築)
    • CHAPTER 14: INTRODUCING THE DOMAIN MODELING BUILDING BLOCKS (ドメインモデリングの構成要素の紹介)
    • CHAPTER 15: VALUE OBJECTS (値オブジェクト)
    • CHAPTER 16: ENTITIES (エンティティ)
    • CHAPTER 17: DOMAIN SERVICES (ドメインサービス)
    • CHAPTER 18: DOMAIN EVENTS (ドメインイベント)
    • CHAPTER 19: AGGREGATES (集約)
    • CHAPTER 20: FACTORIES (ファクトリ)
    • CHAPTER 21: REPOSITORIES (リポジトリ)
    • CHAPTER 22: EVENT SOURCING (イベントソーシング)
  • PART IV: DESIGN PATTERNS FOR EFFECTIVE APPLICATIONS(効果的なアプリケーションのためのデザインパターン)
    • CHAPTER 23: ARCHITECTING APPLICATION USER INTERFACES (アプリケーションのユーザインタフェース設計)
    • CHAPTER 24: CQRS: AN ARCHITECTURE OF A BOUNDED CONTEXT (コマンドクエリ責務分離 : 境界づけられたコンテキストのアーキテクチャ)
    • CHAPTER 25: COMMANDS: APPLICATION SERVICE PATTERNS FOR PROCESSING BUSINESS USE CASES (コマンド:ビジネスユースケースを処理するためのアプリケーションサービスパターン)
    • CHAPTER 26: QUERIES: DOMAIN REPORTING (クエリ:ドメインのレポーティング)

想定する読者

Introduction」の「Who Should Read This Book」で、本書の想定読者について触れています。 以下、上記からの引用です。

It is not a replacement for Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans (Addison-Wesley Professional, 2003). Instead, it takes the concepts introduced by Evans and distills them into simple straightforward prose, with practical examples so that any developer can get up to speed with the philosophy before going on to study the subject in more depth.

ここでは、本書が「DDD本の代用品ではない」と明確に述べていますね。 また、「エヴァンスによって紹介された概念を、単純で (simple) 分かりやすい (straightforward) 散文 (prose) に蒸留する (distill) 」という記述もあります。 これは、DDD本自体が文学的で韻文形式の文章を多く含んでおり、それがDDD本の読みづらさに繋がっていたと思うので、韻文と対比する形で散文 (prose) という言い回しを使うことで、分かりやすさを強調しているのかなと解釈しました。 つまり本書は「DDD本を読むだけでは分かりづらかったDDDの概念を、わかりやすい文章と実践的なコード例を用いて解説する」という内容になっていると思います。 著者が述べている通り、DDD本を既に読まれた方が、理解を深めるための副読本として読むのが良いのかもしれませんね。

まとめ

今回は、DDDパターン・原則・プラクティス本について簡単に紹介しました。 DDDへの理解を深めるために有用そうな内容になっているので、少しづつ読み進めていきたいと思います。 興味のある方は手に取ってみてはいかがでしょうか?(個人的には日本語訳されることを期待しています)

「よいコード」を書くためのはじめの2歩

ギルドワークスさんとパートナーとして一緒にお仕事させていただいています
木目沢(@pilgrim_reds)と申します。

このような場で記事を書かせていただけることになりまして大変緊張しております。

今回は、Kent Beckが書いた「実装パターン」という本を紹介したいと思います。

出版社の都合で絶版になってしまっているのですが、素晴らしい本ですので、もし手に取る機会がありましたらぜひ読んでみてください。

この本のテーマは、「よいコードを書く方法」です。
190ページという薄い本ながら、「よいコードを書く」ためのパターンが100個近く掲載されています。

なにより素晴らしいのは、パターンを紹介するだけでなく、

  • そもそもよいコードとは何か?
  • なぜよいコードを書く必要があるのか?
  • パターンとは何か?
  • どのようにパターンを選択し、適用すればよいのか?

という本のテーマの「前提」となる部分がきちんと説明されていることです。(まえがき、1章〜4章)

全てをこの場では紹介しきれませんので、今回はこのなかから、「よいコードを書くためのはじめの2歩」を紹介します。これは、Kent Beck自身が歩んだ最初のステップということで「1章 はじめに」で紹介されています。

1歩目・・・プログラミングを行うと同時に意識的になること。

Kent Beckがこの本を執筆しはじめたころの話だそうですが、当時、すでに、何年もプログラミングの経験があり、プログラミング上の決定はスムーズにすばやく行われているのに、なぜメソッド名をその名前にしたのか、そのオブジェクトにそのロジックを含ませるべきだと確信した理由は何なのかを説明できなかったことに気がついたそうです。

そこで、よいコードを書くための第一歩は「自分で何を考えているかを意識できるぐらいに思考速度を落とす」こと、直感でコードを書く「振り」をやめることを挙げています。

2歩目・・・他人の重要性を認識すること。

プログラミングというのは、1人の人間と1台のマシンとの孤独なコミュニケーションであることは、ほとんどありません。
また、他人を気に掛けるということは、意識的な決定であって、練習しないと身につかないものです。

同じくKent Beckが書いた「XPエクストリーム・プログラミング入門 — 変化を受け入れる 第2版」の原書出版が2004年。「実装パターン」原書出版が2007年ですから、当時、すでに達人の域に入っていたといってもいいでしょう。
つまり、新人でも中級者・上級者であっても気がつかなければ最初の一歩も踏み出せないということです。

ここまで、こんなことを言っておいてなんですが、私自身、はじめの2歩を忘れてコードを書いていることが未だに多いです。
まだまだ、練習が足りませんね。

誤解していただきたくないのは、「常にゆっくり」コードを書けといっているわけではありません。いわばトレーニングの一環といったところです。
最終的にはよいコードを書くことを「習慣化」するというのが、そもそもの本書の目的であります。

最後にこの「実装パターン」ですが、ギルドワークスの増田さんが、ドメイン駆動設計を実践する中で、何度も読み返して参考になさっている文献のなかの一冊に挙げられています。

ドメイン駆動設計を実践されている方にもぜひ手に取っていただきたい一冊です。

この記事を読んでギルドワークスに興味を持たれた方はお気軽に【ギルドワークスに依頼する】をご覧の上、お問合せください

ドメイン駆動設計とJava 8 ラムダ式

河上です。

Java 8 でやっとラムダ式が使えるようになって喜んでいる今日このごろですが、業務アプリケーション・プログラミングであるドメイン駆動設計という文脈でどういった変化がおこるのかを考えてみます。

まず適用できそうなところとして思いつくのは以下です。

  • Specificationパターンの実装
  • ファーストクラスコレクション内部のコレクション操作

それぞれの実装例として幾分恣意的ではありますが、シンプルな要件を、ラムダ式を利用しないバージョンと、利用するバージョンでそれぞれ実装してみたいと思います。

要件:「ある会員制サイトで、年収800万円以上、且つ、正社員、且つ、課長以上、というステータスを持つ会員を幹部候補として区別し、絞込などをおこないたい」

まずは、年収800万円以上、且つ、正社員、且つ、課長以上という、複合条件をSpecificationパターンの実装方法の1つである、「Compositeパターンによる条件ツリー方式」で記述してみます。

ラムダ式を利用しない

public class ExecutiveMemberSpecification {
    MemberSpecification 年収800万以上 = new MemberSpecification() {
        @Override
        public boolean isSatisfied(Member 会員) {
            return 会員.年収().greaterEqual(800);
        }
    };
    MemberSpecification 正社員 = new MemberSpecification() {
        @Override
        public boolean isSatisfied(Member 会員) {
            return 会員.雇用形態().equals(EmploymentType.正社員);
        }
    };
    MemberSpecification 課長以上 = new MemberSpecification() {
        @Override
        public boolean isSatisfied(Member 会員) {
            return 会員.役職().greaterEqual(Position.課長);
        }
    };

    public boolean isSatisfied(Member 会員) {
        return 年収800万以上
                .and(正社員)
                .and(課長以上)
                .isSatisfied(会員);
    }

}

abstract class MemberSpecification {
    abstract boolean isSatisfied(Member member);

    MemberSpecification and(MemberSpecification specification) {
        return new MemberSpecification() {
            @Override
            boolean isSatisfied(Member member) {
                return MemberSpecification
                        .this.isSatisfied(member)
                        && specification.isSatisfied(member);
            }
        };
    }

    MemberSpecification or(MemberSpecification specification) {
        return new MemberSpecification() {
            @Override
            boolean isSatisfied(Member member) {
                return MemberSpecification
                        .this.isSatisfied(member)
                        || specification.isSatisfied(member);
            }
        };
    }
}

ラムダ式を利用する

public class ExecutiveMemberSpecification {
    final Predicate<Member> 年収800万以上
            = it -> it.年収().greaterEqual(800);
    final Predicate<Member> 正社員
            = it -> it.雇用形態().equals(EmploymentType.正社員);
    final Predicate<Member> 課長以上
            = it -> it.役職().greaterEqual(Position.課長);

    public boolean isSatisfied(Member 会員) {
        return 年収800万以上
                .and(正社員)
                .and(課長以上)
                .test(会員);
    }
}

ラムダ式を利用しない場合に比べてコードにあるノイズがほぼ消えていることがわかります。

次は、このSpecificationを使って、実際に会員を絞り込むコレクション操作部分です。

ラムダ式を利用しない

public class Members {
    final List<Member> values;

    public Members(List<Member> values) {
        this.values = values;
    }

    ExecutiveMemberSpecification 幹部候補者条件 = new ExecutiveMemberSpecification();

    public List<Member> 幹部候補者リスト() {
        List<Member> members = new ArrayList<>();
        for (Member 会員 : values)
            if (幹部候補者条件.isSatisfied(会員)) members.add(会員);
        return members;
    }
}

ラムダ式を利用する

public class Members {
    final List<Member> values;

    public Members(List<Member> values) {
        this.values = values;
    }

    final ExecutiveMemberSpecification 幹部候補者条件 = new ExecutiveMemberSpecification();

    public List<Member> 幹部候補者リスト() {
        return values.stream()
                .filter(幹部候補者条件::isSatisfied).collect(Collectors.toList());
    }
}

こちらではラムダ式を利用しない場合に比べて絞り込むという部分がfilterというメソッドとしてより直接的に表現出来ている部分に好感がもてます。

コードの例としては以上となります。コードの細かい解説などはなく不親切とは思いますが、雰囲気だけでも感じていただければと思います。

上記例以外にもソートなどの記述がシンプルになったりと、メリットが多いと感じるラムダ式ですが、実を言うと、上記の例も含めて、私がドメインモデルのコードでラムダ式を使う部分は局所的です。

それは、例えば「ドメインモデルの外部からラムダ式を注入するようなモデルの汎用化をおこなう事」が、「用途や文脈に合わせた特殊化を行う」というドメイン駆動設計の思想と相反するのではないかという考えがあるからで、今のところそれを変えるような経験に出会っていません。

もちろん、ドメインモデルの外のインフラストラクチャやフレームワーク内部ではラムダ式をつかった汎用化がかなりの武器になることに疑問はありません。

他につっこみや「ドメインモデル内でのラムダ式活用例」としてなにか事例等あればご意見ください。