Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。2004)の著者でもあります。年代前半から、企業のシステムにおけるドメインのモデル化と設計に取り組んでおり、ドメイン駆動設計のチームを指導・訓練したり、柔軟性の高いプロセスや高度な設計をさまざまなプロジェクトに組み入れる手助けをしてきました。とここスプリングエクスペリエンスに来ています。Eric、自分自身のことについて、そして最近の活動について少し教えてください。最近は、コンサルタント業務を行ない、ドメイン駆動設計に関して、いろいろなお客様をサポートしています。具体的には戦略を考えたり、トレーニングを実施したりといった活動です。スプリングエクスペリエンスのようなコンファレンスにも出席しています。十分な知識がない人のために、ドメイン駆動設計について教えてください。ドメイン駆動設計の重要なポイントは、まずはソフトウェアの対象となるビジネスやドメインについてもっと熟考し、そのあとでソフトウェアの開発に使用するテクノロジーやすべての手法、さらにはプロセスについて考える必要があるということです。これが、ドメイン駆動の重要な部分です。実際にこれを実行することは、口で言うほどは簡単なことではありません。したがって、きわめて多くのことが導入されます。ドメインが複雑になると、ドメインのモデル化がドメイン管理の鍵となります。これが、ドメイン駆動設計とモデルの間に大きな関連性がある理由です。チームでドメイン駆動設計を行なう場合、ドメイン駆動設計を有効に実施するためには、最低でもどのようなことが必要とされますか?さまざまなパターンが考えられますが、ドメイン駆動設計の最も基本的なパターンは、おそらくユビキタス言語でしょう。ドメインの専門家、社内の専門家がドメインについて議論する際に基盤となる概念を練り上げるときに特定の言語を使い、そして、その言語には、概念の洗練さを反映して常に改良が加えられていきます。議論する際に共通の言語を使います。これは、規格書で使われる言語と同じものであるため、概念モデルの改良に合わせて規格書も改良する必要があります。重要なポイントは、この言語は、テクノロジーで実現できる範囲を拡大するコードで使用する言語と同じものです。それがユビキタス言語と対応するようにします。いった理由でユビキタスと呼ばれます。プロセス全体で使われるからです。そのためには、境界があるという認識、モデルは空間に浮かんでいるのではないという認識、そのモデル特定の状況において適用され、その状況には明確に定められた範囲、つまりそのモデルの限定的な状況があるという認識を持つ必要があります。つの要素でドメイン駆動設計を行なう場合は、もっと具体的な問題の解決に役立つことがほかにも数多くあるでしょうね。つの要素について、まずはユビキタス言語をどのような方法でコード化するのか、そしてそれは実際にどのような感じなのかについてもう少し詳しく教えてください。採用している実装テクノロジーのタイプによって大きく変わります。実際に、オブジェクト指向のプログラミングの利点は、特定の種類のモデル、概念システムと使用する傾向が高い言語、実際の実装を綿密に対応付けることができるという点です。構文的には英語の文章と大きく異なるものの、意味的には近いコードを記述できます。コードのその行を読んで、「意味は理解できる。英語の構文を使って、非常に似通った言葉で意味を説明できる」と言うことができます。主語と動詞を言い当てることはできますが、ほかにも言いたいことはあるかもしれません。それが現状なのでしょう。範囲が限定された状況について詳しく教えてください。モデルについては考えますが、このモデルに意味を与える状態や状況については考えません。このホテルのこの場所に座っているときに、私が「ホームに帰りたい」と言えば、それはおそらく空港に行き、飛行機に乗り込み、カリフォルニアに帰りたいという意味になるでしょう。球場のグラウンドで、「ホームに帰りたい」と言えば、ベースを回って得点をあげたいという意味になるでしょう。ソフトウェアを記述したり設計したりするときに、こういうことはあまり考えません。簡単な英語の文章の意味、そしてもちろん設計中のドメインオブジェクトの意味は、非常に状況に依存しています。したがって、範囲が限定された状況とは、それを明示的に認識することであり、「この状況においてこのモデルを使っている」と言うことです。サブシステムによってそれを明確にできるかもしれません。「このサブシステムにおいては、これが状況である。私たちが使っているのはこのモデルであるという意味である」とも言えます。「このチームが行なっている作業内で、このモデルが適用されている」とも言えます。それは一般的にチームの範囲と一致します。これらも概念モデルであり、ほかの人と自動的に共有できないため、十分密接な関係を築いて本当に打ち解けている必要があるからです。これが、範囲が限定された状況の本質であり、大規模なプロジェクトにおいては、常に複数のモデルが有効であるため、範囲は重要であり、そうでなければ、いろいろなことがごちゃ混ぜになり、さっぱりわけがわからないことになります。ユビキタスな言語と範囲が限定された状況はどのような方法で文書化し、この情報をチーム内でどのような方法で共有するのですか?いい質問ですね。通常は、このようなことは問題にはならないのですが、私は問題であると考えています。ユビキタス言語に関して言えば、実施されている傾向は高いと言えます。場合によっては、用語集などを作成していることもありますが、それには注意しなければなりません。用語集は言語を凍結させますし、進化することが言語の価値の1つだからです。範囲が限定された状況については、実際にはユビキタス言語そのものよりもはるかに安定しているのですが、組織内、さらには部門ごとの境界に設置されたチームにさまざまなコードが存在すれば、範囲が限定された状況はかなり安定したものになります。実際に私は、本で使用したような非公式な表記方法を使って図式化しています。特別な表記方法は定めてはいませんが、実際に図を描いたり、通常は設計担当者やプロジェクト責任者といった人たちを集めたりすることには価値があると言っているわけです。重要なお客様数人を集めて、状況マップがどのようなものになるのかを導き出し、チームの全メンバー、誰とでも共有することも可能です。これは十分に行なう価値があることであり、実際に私自身がお客様に対して頻繁に行なっていることです。ドメイン駆動設計が多用されていることに対してどう思いますか?また、ドメイン駆動設計を多用していることは、どのようにしたらわかりますか?このことについては、ずっと気になっていたので、最近よく話題にしています。モデル信望者が最初に犯す基本的なミスとしてますます目に付くようになったのは、すべてのものをモデル化すべきであるという考え方、システム全体をモデル化しオブジェクト指向化すべきであるといった考え方です。最近になってわかってきたことなのですが、このような考え方によって、取り組みが希薄化され、モデル化の責任に対する気力がなくってしまいます。CRUD(create、read、update、delete)され、そのような問題に対する簡単な解決策が存在します。したがって、私が本当に注目してきたことは、ドメインの難しくて複雑な部分において、ゼロ化することです。この複雑な部分が本当に問題の原因になっています。モデル化の取り組みに焦点を当て、範囲が限定された状況という考え方を利用することによって、ほかの部分から分離し、いくつかの価値の高い困難な問題の範囲内において、モデル化によって実現できることが本当に見えてきます。困難なプロセスであるため、さまざまな価値が得られます。楽しみだけのためにやりたいと思うことではないし、データを収集しデータベースに入力するための莫大な数の画面を作成するためにやるべきことでもありません。ビジネス的な価値が得られる部分を求めて行なうべきです。図式化とほぼ同意語になりました。ソフトウェエアの層を意味していると考えることもできるでしょう。私にとっては、モデル化というのはそれ以上にもっと基本的なことです。モデルは、概念的なシステムであり、一部の特定の問題または複数の問題に適用できる抽出の集合です。ソフトウェアが出現するずっと前にモデルはすでに存在しましたよね。物理学の理論はモデルであり、地図は世界をモデル化したものです。ナビゲーションの地図、人口統計用の地図など、地図は特定の用途で使われています。同じ理由で、自分のドメインのモデルを作成しますが、このモデルは、非常に蒸留度が高く、きわめて厳格であるだけでなく、特定の重要な情報を解明したり、特定の何らかの問題に取り組んだりする上で便利なドメインの概念を個別に選択したものでもあります。あいまいに聞こえるかもしれませんが、それが本当にモデルというものです。辞書をひけば、抽出のシステムのように定義されているかもしれませんが、モデルの能力の一部は、その基本的な定義に戻ってくるのです。一部のモデルの特定の特性を伝えたり記録したりするにはよい方法です。したがって、私たちはたいていオブジェクト指向のパラダイムで運営しているので、選ぶモデルの種類は次にようになります。「このような一連の事象があり、このような一連のオブジェクトがあり、それらがこのようにお互いに関連しています。表記法があり、それによって図示することができます。オブジェクトの静的な関係という観点では。はすばらしいコミュニケーションツールです。そのような目的で使うのであれば、本当の資産になります。モデルのほかの側面のいくつかにおいては、実際にはじゃまになります。ユビキタス言語とコードの結び付けについて話したときのように。ユビキタス言語全般は本来、もっとテキスト的なものです。図式化よりもわかりやすいと言えます。年に発表されたものですが、現在それに関する発言が大きくなってきているような気がします。今が、ドメイン駆動設計の時代であることの理由を教えてください。私自身、このことに当惑してきました。最近大ブームになっていることに気づいたからです。して、本によって人々の意識がいくぶんか高まったということが挙げられます。このような考え方を表現する新しい方法を吸収する時期が必要だったのです。そのような人たちが現在は自分自身で何らかのことを試してみる時間ができ、そして膨大な数の人たちが次のステップに移行していることに気づきました。したがって、このような静かさがあったのはそのためではないかと思います。それはさまざまな形態で現れました。ドメイン駆動設計の早わかりバージョンを発表したことなどが挙げられます。その手法を使う人たちもいます。興味深い体験レポートも書かれ始めました。これは、当然のなりゆきなのですが、ツールメーカーや技術者がそれを使って物事を行なおうとしていることであり、場合によっては、さまざまな方法があったり、ひどい結果を招いたりする場合もありますが、実際にテクノロジー基盤をドメイン駆動設計に若干適したものに変えている人もいると思います。実験が行なわれることにわくわくしています。私は、実験が大好きです。今後数年でどのような機能が実現するかがわかるでしょう。