Domain Modeling Made Functional Part 1 with Scott Wlaschin
最近聞いたポッドキャスト、 Compiled Conversation #8 がドメイン駆動設計の入門としてすごくよかったので、英語で文字起こしして、和訳をしました。参加者のお二人に和訳をブログに載せる許可をいただきました。LLMによる機械翻訳ベースなので、細かな表現が意訳されていたり、また文字起こしの間違いにより一部おかしな内容になっているかもしれません。ぜひ英語でわかる方は本編を英語で聞かれることをお勧めしますが、日本語の和訳だけでもニュアンスが十分伝わるので、よろしければご覧ください。
(1)-2 はこちら
(1)-3 はこちら
(2)-1 はこちら
(2)-2 はこちら
(2)-3 はこちら
podcastのリンクはこちらです。
登場人物
- Ed Mann（ホスト）: ポッドキャストの司会者
- Scott Wlaschin（ゲスト）: 『関数型ドメインモデリング』著者、F# for Fun and Profit ブログ執筆者
はじめに - Scott Wlaschinの紹介
Ed Mann
英語はこちら
Hello and welcome to the show. My name is Ed Mann, and today we're very lucky to be joined by Scott Wlaschin. How's it going, Scott? Hi. Thanks for having me on. No worries. No worries at all. I was just, we were talking off air, like the last time we spoke, I think was in 2018 on another podcast that I've done. And a lot has changed since then. So yeah, we've got plenty to catch up on. But no, I'm. I'm really looking forward to it. But for the audience, would you mind introducing yourself?
こんにちは、番組へようこそ。私の名前はEd Mannです。今日はScott Wlaschinに参加していただき、とても幸運です。調子はいかがですか、Scott？こんにちは。お招きいただきありがとうございます。どういたしまして。全く問題ありません。収録前に話していたのですが、最後にお話ししたのは確か2018年の別のポッドキャストでした。それ以来多くのことが変わりました。ええ、話すことがたくさんありますね。いえ、本当に楽しみにしています。しかし視聴者の皆さんのために、自己紹介をしていただけませんか？
Scott Wlaschin
英語はこちら
Yes, so I'm Scott Wlaschin and I have been doing. I have a blog about functional.
はい、私はScott Wlaschinです。関数型プログラミングについてのブログを運営しています。
Scott Wlaschin
英語はこちら
Going called F# for Fun and Profits, which I started about 1314 years ago and which is very popular in the F# world. And then I also wrote a book in 2018 called The Domain Modelling Made Functional, which is about domain driven design, which I'm a big fan of, and also functional programming and how we can combine functional programming and domain design in the same process rather than having typically domain designers considered OO. So my book is functional version of domain design, Absolutely.
「F# for Fun and Profits」というブログで、約13-14年前に始めたものでF#の世界では非常に人気があります。そして2018年に『Domain Modeling Made Functional』（関数型ドメインモデリング）という本も書きました。これはドメイン駆動設計について書いた本で、私はDDDの大ファンなのですが、関数型プログラミングとドメイン設計を同じプロセスで組み合わせる方法について述べています。通常、ドメイン設計者はOOをベースに考えられがちですが、私の本はドメイン設計の関数型版です。その通りです。
Ed Mann
英語はこちら
For the audience, I put it in the show notes. We've had a couple of really interesting episodes with Scott over the years on the previous podcast and I'll put them in there. And we did touch upon the domain modelling made functional book in one of them. But I thought it would be so cool to get you back on again. I'd recently reread it. I got very excited and I thought it would be really cool. I feel like the way you've been able to tackle both DDD and functional programming for an introductory level, as well as then being able to make it complete. I I don't know how you've done it in a book. I really don't. And in the size of the book.
視聴者の皆さんのために、ショーノートに記載しておきます。以前のポッドキャストでScottと何度か興味深いエピソードを収録しており、それらもそこに載せています。その中で『関数型ドメインモデリング』の本についても触れました。でも再びお招きできて本当に素晴らしいと思いました。最近この本を読み返して、とても興奮しました。本当にクールだと思ったのです。入門レベルでDDDと関数型プログラミングの両方に取り組みつつ、それを完成させることができた方法に感動しています。一冊の本でどうやってそれを成し遂げたのか、本当に分かりません。しかもこのサイズの本で。
Ed Mann
英語はこちら
I think it shows how well they blend together.
それらがいかによく組み合わさるかを示していると思います。
『関数型ドメインモデリング』執筆の動機
Scott Wlaschin
英語はこちら
I think so, yeah. And the book had to be short. Publishers do not like long books, so they had to be under 300 pages. So I did have to leave a bunch of things out. But I think I, yeah, people seem to be very happy with it. It gets good reviews and definitely it was an interesting book, so.
そう思いますね。そして本は短くする必要がありました。出版社は長い本を好まないので、300ページ未満にする必要がありました。そのため多くのことを省かなければなりませんでした。でも、人々はとても満足しているようです。良いレビューを得ていますし、確実に興味深い本だったので。
Ed Mann
英語はこちら
Yeah, I'm happy to talk about that later on. That's awesome. So I think my first question then would be around that.
ええ、それについては後で話すのを楽しみにしています。素晴らしいです。では最初の質問はそれに関することですね。
Scott Wlaschin
英語はこちら
Book is like what motivated you then to write this book? Well, OK, so I've always been into design and ever since I used to do a lot of programming in small talk back in the 90s and I've always been.
本について、この本を書く動機は何でしたか？そうですね、私は常に設計に興味を持っていました。90年代にSmalltalkでたくさんプログラミングをしていた頃からずっと。
Scott Wlaschin
英語はこちら
I, I hate like low level languages like C assembly code. I'm always, I'm a high level kind of guy and I've always been interested in design. And, and what's interesting is a lot of the, a lot of the people who are famous today, Martin Fowler and Kent Beck and Uncle Bob, these old people are small talk backgrounds. So the small talk community, a lot of the things like design patterns and stuff came out of the small talk community and I was part of that then. So I was very, I've always been into design, but then I also got into functional programming.
私はCやアセンブリコードのような低レベル言語が嫌いです。私は常に高レベル志向の人間で、設計に興味を持ち続けてきました。興味深いことに、今日有名な多くの人々、Martin FowlerやKent Beck、Uncle Bobといった人たちは、Smalltalkの背景を持っています。Smalltalkコミュニティから、デザインパターンなど多くのものが生まれました。私もその時代の一部でした。そのように私は常に設計に興味を持っていましたが、その後関数型プログラミングにも興味を持つようになりました。
Scott Wlaschin
英語はこちら
You know, 15 years ago.
15年ほど前のことです。
Scott Wlaschin
英語はこちら
And, and I started seeing things like, well, this has been awesome for doing design as well, but nobody has talked about it because functional programming was considered very mathematical, very abstract and nothing to do with kind of normal people doing business programming. It's all very, you know, very academic stuff. So, and I thought, well, you know, it seems to me there's a good match there. So I was, I had audit, my very first conference talk was on this exact topic. And I did a bunch of conference talks. It wasn't called domain modelling main function. It was called DDD with F#.
そして、これは設計においても素晴らしいということを見始めましたが、誰もそれについて話していませんでした。関数型プログラミングは非常に数学的で抽象的であり、ビジネスプログラミングをする普通の人々とは関係がないと考えられていたからです。すべて非常にアカデミックなものだったのです。でも、そこには良いマッチングがあるように思えました。そこで私は、最初の講演がまさにこのトピックでした。多くの講演を行いました。その時は「Domain Modeling Made Functional」とは呼ばれていませんでした。「DDD with F#」と呼ばれていました。
Scott Wlaschin
英語はこちら
Or something. But I was approached by someone at Pragmatic Programmers Press and they said would you like to turn it into a book? And I said I'd love to. So I pitched the book and I wrote the book and there you go. So it's very unusual because most Prague normally they made their thing from the Pragmatic programme and they do a lot of Ruby and Elixir and things like that. They're not really not really a statically typed functional programming thing, but I think the book has been quite successful for them. It's still selling. I'm surprised actually. I thought the.
のような名前でした。でもPragmatic Programmers Pressの人からアプローチがあり、「これを本にしませんか？」と言われました。「ぜひそうしたいです」と答えました。そこで本を企画し、執筆しました。これは非常に珍しいことです。なぜならPragmaticは通常、RubyやElixirなどを扱っており、静的型付けの関数型プログラミングは本当に彼らの専門分野ではないからです。でも、この本は彼らにとってかなり成功したと思います。まだ売れています。実際に驚いています。
Scott Wlaschin
英語はこちら
Most books would like have a big peak when you first launch it and then, you know, it decay. So I'd never thought of it as like, you know, that would last, but it's actually it's just steady. It's pretty much selling. You know, it's gradually going down, but it's not it's still selling quite a lot considering that it's, you know, five years old. So but I worth it like that I wrote it I didn't want.
ほとんどの本は最初に大きなピークがあり、その後衰退していくものです。そんなに長く続くとは思っていませんでしたが、実際には安定しています。着実に売れています。徐々に減少していますが、5年経っているにも関わらず、まだかなり売れています。でも、書いてよかったと思っています。私が望まなかったのは...
Scott Wlaschin
英語はこちら
I used to buy books like Visual Basic 5.0, you know, COM Edition or something. And then next, you know, next year you'll be out of date. And the same thing with all the JavaScript and all the stuff. So I hate books which go out of date within six months. So I want to write a book like the design patterns book or like the domain design book, which would last would be valuable for, you know, 10-15 years. So hopefully I think.
私は昔「Visual Basic 5.0 COM Edition」のような本を買っていました。そして翌年にはもう古くなってしまうのです。JavaScriptなど他のすべてのものでも同様です。6ヶ月で古くなってしまう本が嫌いです。だから、『デザインパターン』の本や『ドメイン駆動設計』の本のように、10-15年間価値のある本を書きたかったのです。うまくいったと思います。
Ed Mann
英語はこちら
I've done that. I know you definitely have. And I think that's the thing like talking about the theory and as you say like the the practical application. I mean the one thing I love about.
それを実現しましたね。確実に成功したと思います。理論について話すことと、おっしゃったような実践的な応用について。私が愛している一つのことは...
Ed Mann
英語はこちら
Is that you do blend both the theory with practical so you can really see it, you know, it's not just kind of pie in the sky ideas without any real true understanding, but it refrains. I mean, there's only a couple of references to maybe 2017, you know, you need to have. But really it is timeless. And I think that's one of the most powerful things around this is that you can still use this today. So I was just wondering like, since it's been published, then how has your thought process, how are things changed for you since then? Like in your understanding around EDD and functional programming? What I'm really kind of.
理論と実践の両方を組み合わせていることです。本当にそれを見ることができます。真の理解を伴わない単なる夢物語のアイデアではなく、抑制されています。2017年頃への言及が少しあるくらいで、本当に時代を超越しています。これが最も強力な点の一つだと思います。今日でもまだ使えるということです。だから疑問に思ったのですが、出版されてから、あなたの思考プロセスはどう変わりましたか？DDDと関数型プログラミングの理解において、どんなことが変わりましたか？私が本当に気になるのは...
Ed Mann
英語はこちら
That would there be a second edition maybe?
第2版が出る可能性はありますか？
本の内容と今後の展望
Scott Wlaschin
英語はこちら
Well, people have complained that some of the things, you know, I skimp on a lot of stuff which I do because of space. And also there's some techniques which I don't discuss at all which functional programmers would use. And I don't really talk about them because it was meant to be an introductory book. And so I was appealing to people who were DDD people, not functional programming people, which is why I do a lot of basic, very basic intro to functional programming. So some people complain about that. And I didn't have event sourcing. I don't a whole bunch of things.
まあ、いくつかのことについて人々は不満を言っています。スペースの関係で多くのことを省いているからです。また、関数型プログラマーが使うであろういくつかのテクニックについては全く議論していません。これが入門書として意図されていたため、それらについて実際には話していません。関数型プログラミングの人々ではなく、DDDの人々にアピールしようとしていたので、非常に基本的な関数型プログラミングの入門を多く行っています。それについて不満を言う人もいます。イベントソーシングも含めていませんし、他にも多くのことを含めていません。
Scott Wlaschin
英語はこちら
Don't have. And I thought, well, you know, I'm not going to put that in. And if, you know, to be honest, if I did a second edition, I I still probably wouldn't put that in. It's just it's meant to be an introductory book. And I do have ideas for, you know, a much more detailed book on design in general, but I think I'm quite happy with it. I don't think I would. Change too much. I mean there's a couple of mistakes and stuff in there, but well,
含めていません。そして、それらを入れるつもりはないと思いました。正直に言うと、第2版を出すとしても、おそらくまだそれらを入れないでしょう。これは入門書として意図されているからです。設計全般についてのより詳細な本のアイデアはありますが、現在の本には非常に満足しています。変更するつもりはないと思います。
Ed Mann
英語はこちら
no, I mean, and you know, a release in 2018. I know you went through like the beta kind of the the Prague product was quite interesting. Listening back to our previous episode, yes, you know that that interesting feedback loop that you'd happen everything and it went to 2018.
Was published, yes, but again, I think you're right like this book, if you start adding more functional concepts, more pressing on that kind of thing, it is another book and it's also going to muddy the water between the DDD, like trying to introduce DDD and also functional programming and really just trying to blend the world. Look, this is how you can use functional programming to better and to understand your domain and things like that like it's not about monads and.
Automatically readers that it's about the core that is DDD and how FP works.
いえ、つまり、2018年のリリースの話ですね。ベータ版を通して、プラハの製品プロセスがとても興味深かったことを知っています。以前のエピソードを振り返ってみると、そうです、あのすべてが起こった興味深いフィードバックループがあり、それが2018年まで続いたのです。
確かに出版されましたが、あなたが正しいと思うのは、この本により多くの関数型概念を追加し始めたら、それはもう別の本になってしまうということです。そしてDDDとの間の境界線を曖昧にしてしまいます。DDDを紹介しようとしながら、同時に関数型プログラミングも紹介し、世界を融合させようとするようなものです。これは関数型プログラミングを使ってドメインをより良く理解する方法を示すものであり、モナドについてのものではありません。
読者にとって重要なのは、DDDの核心部分と、関数型プログラミングがどのように機能するかということです。
Scott Wlaschin
英語はこちら
Had nothing I deliberately didn't put anything about monads in there I would at maybe 1 section I would probably expand on is the whole architecture section because I kind of skimped on that too and I talk about IO. I've become more firmly the idea that IO shouldn't be in your core domain at all I mean in my in my 1 I did it through kind of dependency injection which is okay and again it's what people who are doing oh oh would understand but I've actually I've actually done a talk about this a couple of years ago about keeping IO at the edges of your app and not having in the core domain at all and.
意図的にモナドについて何も入れませんでした。拡張するとすれば、アーキテクチャのセクションでしょう。そこも少し省略しすぎました。IOについて話しています。IOはコアドメインに全く含めるべきではないという考えをより強く持つようになりました。本では依存性注入を通じて行いましたが、それは大丈夫で、オブジェクト指向をやっている人々が理解できるものです。しかし実際に、数年前にこのことについて講演を行いました。IOをアプリケーションの端に保ち、コアドメインには全く含めないということについてです。
Ed Mann
英語はこちら
Emphasise that a lot. Interesting, very interesting. And so I think what I've kind of talked with this episode was it be really cool maybe to touch on domain driven design, functional programming and then they say the combination of the two. I think your books done it so well. So hopefully we can do something similar. So I think first thing then would be what is domain driven design?
それを大いに強調するでしょう。興味深い、とても興味深いです。このエピソードで話そうと思っていたのは、ドメイン駆動設計、関数型プログラミング、そしてその二つの組み合わせについて触れることでした。あなたの本はそれを非常にうまく行っています。だから私たちも同様のことができればと思います。では、最初の質問は、ドメイン駆動設計とは何かということです。
ドメイン駆動設計とは何か
Scott Wlaschin
英語はこちら
Right. So Domain Driven Design was a term pretty much invented by Eric Evans, who had a book called Domain of Design.
そうですね。ドメイン駆動設計という用語は、『ドメイン駆動設計』という本を書いたEric Evansによってほぼ発明されました。
Scott Wlaschin
英語はこちら
About 2003. Maybe 20, at least 20 years ago and.
2003年頃のことです。たぶん20年、少なくとも20年前のことです。
Scott Wlaschin
英語はこちら
That was his face, but the idea of his main idea was rather than writing code from a technological point of view, you write code using the words that a non developer would use. So the concepts and the vocabulary would be based on what the non developers would use. Well, why would you bother to do that? I mean most developers would have, you know, company to digitally use very complex things. Well, the OO domain modelling people, class responsibility cards and some of that stuff from the.
それが彼の顔でしたが、彼の主なアイデアは、技術的な観点からコードを書くのではなく、開発者でない人が使う言葉を使ってコードを書くというものでした。つまり、概念と語彙は非開発者が使うものに基づいているのです。なぜそんなことをするのでしょうか？ほとんどの開発者は、デジタル的に非常に複雑なものを使う会社にいるでしょう。オブジェクト指向のドメインモデリングの人々、CRC（クラス責任協調）カードなど...
Scott Wlaschin
英語はこちら
Also kind of emphasise this, and the reason is because code is about communicating. It's not the computer doesn't care what kind of code you write. You know, you've seen those obfuscated C things where it's really impossible for someone to understand the computer. The compiler understands it no problem. But so code is written for other people to read. And So what is the best? The idea of domain driven design is you write the code in such a way that the concepts that you're trying to build are communicated in the code itself. So if you have a word.
これも強調していますが、その理由はコードはコミュニケーションに関するものだからです。コンピュータはどんなコードを書こうが気にしません。難読化されたCコードのようなもので、誰かが理解するのは本当に不可能ですが、コンピュータは問題なく理解します。しかし、コードは他の人が読むために書かれているのです。では、何がベストでしょうか？ドメイン駆動設計のアイデアは、構築しようとしている概念がコード自体で伝達されるようにコードを書くことです。ある言葉があれば...
Scott Wlaschin
英語はこちら
In the real world, you use the same word in the codes. I mean, it's, you know, it's pretty obvious really, but you think it would be obvious. But surprisingly, a lot of code is actually kind of hard to understand because it's not written in a way that someone who's not a programmer could understand. So that's basically the basic idea is you focus on the domain and the concepts of the domain rather than the technology or the kind of stuff that you're doing to implement that as much as possible. Obviously there's always stuff sneaking in, but in general when you try to design, try and make it so you can communicate to other people.
現実の世界で使っている言葉と同じ言葉をコードでも使うのです。つまり、本当に明白なことなのですが、明白だと思うでしょう。しかし驚くべきことに、多くのコードは実際には理解が困難です。なぜなら、プログラマーでない人が理解できるような書き方になっていないからです。つまり、基本的なアイデアは、技術や実装のためにやっていることよりも、ドメインとドメインの概念にできるだけ集中することです。明らかに、いつも何かが忍び込んできますが、一般的に設計しようとするときは、他の人とコミュニケーションできるようにしようとするのです。
Scott Wlaschin
英語はこちら
What the important concepts are?
重要な概念は何かということです。
Ed Mann
英語はこちら
Yeah, And, and, and I think it's kind of push on that a little bit. It's like it'd be interesting. Like why is that? Why do we seem to have this thing as developers to translate and to change? Like as you say, it seems like common sense. And the more I read about it, the more, you know, over the years, I'm just like, what we're doing is like, obviously these terms and we've obviously put bounded context subdomains and all these naming, you know, we've named these things, but all these things fundamentally do just make common sense. It seems to be that we learn this stuff afterwards and go, oh, let's go back to having some.
ええ、そしてそれを少し押し進めてみると興味深いと思うのです。なぜでしょうか？なぜ開発者として翻訳し、変更したがるのでしょうか？おっしゃる通り、それは常識のように思えます。そして、何年もかけてそれについて読めば読むほど、私たちがやっていることは、明らかにこれらの用語であり、境界づけられたコンテキストやサブドメイン、これらすべての名前付け、つまりこれらのものに名前を付けましたが、これらすべては根本的に常識なのです。私たちは後からこのことを学んで、ああ、いくつかのものに戻ろうと言っているようです。
Ed Mann
英語はこちら
As opposed to factory builder, you know, insert repository and stuff.
ファクトリービルダー、リポジトリなどとは対照的に。
Scott Wlaschin
英語はこちら
I think it's the way developers, I think developers don't think like normal people. And I think that's part of the problem is developers think that everyone else thinks like them.
開発者の考え方だと思います。開発者は普通の人々のようには考えないと思います。そして、問題の一部は、開発者が他のみんなも自分たちのように考えると思っていることだと思います。
Scott Wlaschin
英語はこちら
In a classic example is it was a joke, you know, instead of having a toaster, it's like, well, this toaster, all you do is you push a button and the toast pops up. It's like, well, you can't control the temperature finally, and you can't control the time. And you end up with a programmable toaster which has, you know, 10,000 buttons on it and a whole bunch of complicated stuff. You know, and a developer say that all of that looks awesome. You can control all these things. And the average person says, I have no idea how to use this toaster anymore. And that's because most people just want to get something done. They don't really get.
古典的な例としてジョークがあります。トースターを持つ代わりに、このトースターは、ボタンを押すだけでトーストがポップアップするというものでした。しかし、最終的に温度をコントロールできない、時間もコントロールできないということになります。そして結局、1万個のボタンと複雑な機能がたくさん付いたプログラマブルトースターになってしまいます。開発者は、それらすべてが素晴らしく見えると言います。これらすべてをコントロールできるのです。しかし、平均的な人は「もうこのトースターの使い方が全く分からない」と言います。それは、ほとんどの人は何かを成し遂げたいだけで、実際には...
Scott Wlaschin
英語はこちら
They don't really care about the details of how it gets done. And so I think, yeah, developers get very obsessed with, you know, the high, especially with, oh, I mean, oh, is I don't hate oh, but it's very easy to get obsessed with the hierarchy of the classes and all the different ways they interact. And I've seen projects where people have written an 0.
彼らは実際にそれがどのように行われるかの詳細については本当に気にしません。そして私は思うのですが、開発者は特にオブジェクト指向において、クラスの階層やそれらが相互作用するすべての異なる方法に非常に執着してしまいます。私はオブジェクト指向を嫌っているわけではありませんが、そこに執着するのは非常に簡単です。私は人々がゼロから書いているプロジェクトを見たことがあります。
Scott Wlaschin
英語はこちら
They've written all the framework for there. They spent two weeks writing code, but they haven't actually written anything useful. It's all the framework. It's all the hierarchy and this and this that. Literally none of the code is useful for anything at that point. But that's developers think we've made progress, but we haven't made any progress. So just getting out of that mindset is actually very hard for a developer. And I highly recommend that developers look at normal people using their software to get a good idea of how they think People, normal people think differently, you know. Yeah, I think empathy.
彼らはそのためのフレームワークをすべて書きました。2週間かけてコードを書きましたが、実際には何も有用なものを書いていません。すべてがフレームワークです。すべてが階層とあれこれです。文字通り、その時点でコードは何の役にも立ちません。しかし開発者は進歩したと思いますが、実際には何の進歩もしていません。そのマインドセットから抜け出すことは、開発者にとって実際には非常に困難です。そして、開発者が自分たちのソフトウェアを使う普通の人々を観察することを強く推奨します。彼らがどう考えるかを理解するために。普通の人々は違った考え方をするのです。ええ、共感だと思います。
Scott Wlaschin
英語はこちら
Exactly 1 of.
まさにその通りです。
Ed Mann
英語はこちら
The biggest, yeah, empathy to the common user. And as you say, like we're trying to solve problems like none of this you mentioned there, you know, spending weeks and weeks on building out these frameworks. If they're not adding any value to the end user or solving a problem, unfortunately, they may be as nice as anything. They may be the best thing ever. You can show it off to your tech frames, but they're not they're not useful like.
最大の、ええ、一般ユーザーへの共感です。おっしゃる通り、私たちは問題を解決しようとしているのに、あなたが言及したように、フレームワークの構築に何週間も費やすということは。それらがエンドユーザーに価値を追加していない、または問題を解決していない場合、残念ながら、それらがどんなに素晴らしくても。それらは今まで最高のものかもしれません。技術仲間に自慢できるかもしれませんが、それらは有用ではありません。
Scott Wlaschin
英語はこちら
It's very sad it's but it's true. Exactly, exactly. It's and I, you know, there's something about developers which is it's very easy to do that. And so the thing of having.
とても悲しいことですが、それは真実です。その通りです、その通りです。開発者にはそれをしやすい何かがあるのです。そこで、持つということは...
戦略的DDDと戦術的DDD
Scott Wlaschin
英語はこちら
A name like the Major tonight, it's like forces you to stop obsessing about your code and start thinking about the problem and start thinking about other people who aren't developers. So it just gives you a sort of nudge to do things in a different way. So that's why I think it's.
ドメインのような名前は、あなたのコードへの執着を止めさせ、問題について考え始め、開発者でない他の人々について考え始めることを強制するようなものです。それは物事を異なる方法で行うための一種の後押しを与えてくれます。だから私はそれが有用だと思うのです。
Ed Mann
英語はこちら
Useful in particular. I think that's so true. I think one thing I'll push on there is that so with DDD, and I think this is again, I've done this wrong and I think Eric Aaron's, the way he organised it in the book is the difference between strategic DDD and tactical DDD. And a lot of what you're talking about there is the strategic.
特に有用です。それは本当にその通りだと思います。私がそこで押したいことの一つは、DDDについて、これは再び、私はこれを間違ってやったと思うのですが、Eric Evansが本で整理した方法は、戦略的DDDと戦術的DDDの違いです。そして、あなたがそこで話していることの多くは戦略的なものです。
Ed Mann
英語はこちら
DDD for the case of trying to workout with the user and all these types of things.
ユーザーと一緒に解決しようとする場合のDDDと、これらすべてのタイプのことです。
Ed Mann
英語はこちら
The tactical DDD part has definitely been, well, we're developers, so we like these things. I was wondering for the audience, maybe it would be good if you maybe explain what when I want to say strategic DDD and tactically what.
戦術的DDDの部分は確実に、まあ、私たちは開発者なので、こういったことが好きです。視聴者のために、戦略的DDDと戦術的DDDについて説明していただけるといいかもしれません。何を意味するかを。
Scott Wlaschin
英語はこちら
What we mean by that, right? So strategy is where do you want to go? And tactics is how do you get there? So where do you want to go? When you're building a programme, you know, what are you trying to achieve? And that's the strategy of how you do that. And the tactics is, you know, what route and what techniques do you use to get there and.
それが何を意味するかですね？戦略とは、どこに行きたいかということです。戦術とは、どうやってそこに到達するかということです。では、どこに行きたいのでしょうか？プログラムを構築するとき、何を達成しようとしているのでしょうか？そしてそれがそれを行う戦略です。そして戦術は、どのルートを使い、どのテクニックを使ってそこに到達するかということです。
Scott Wlaschin
英語はこちら
So strategic DDD is all, to me, it's about understanding the problem, listening to the customer, thinking of, you know, building a shared mental model that we can all agree on. Now the tactics can be bogged down in patterns just like the Gang of Four book with the Puttons. And unfortunately, Eric wrote the book, as everyone says that he wrote sort of back to front. The most important stuff is the strategic thing about thinking the same way. But he unfortunately, he put the, I think he was probably influenced by the patents book and the patents book, you know, it's like, here's a pattern, here's the entity pattern.
だから戦略的DDDは、私にとって、問題を理解し、顧客の話を聞き、私たち全員が合意できる共有メンタルモデルを構築することについてです。さて、戦術はGoF（Gang of Four）のデザインパターンの本のように、パターンに埋もれてしまうことがあります。そして残念ながら、Ericは本を書いたのですが、みんなが言うように、彼は後ろから前に書いたようなものです。最も重要なものは、同じ方法で考えるという戦略的なことです。しかし残念ながら、彼は、おそらくデザインパターンの本に影響を受けていたと思います。パターンの本は、「これがパターンです、これがエンティティパターンです」というようなものです。
Scott Wlaschin
英語はこちら
Here's the value object pattern, here's the repository pattern, blah, blah, blah. And as developers, everyone kind of left onto the patterns and it's like, oh, you need to use this pattern and this pattern, this pattern, this pattern, and you kind of miss the point of DDD in my, in my opinion. So you see a lot. And I think also This is why I've seen people who've got kind of corporate DDD training and they say, I hate, I did all this DDD and I hate it. It's just another corporate thing. And that's because they know that you have to memorise his 20 patterns that you have to use and blah, blah, blah, that's not.
「これが値オブジェクトパターンです、これがリポジトリパターンです」などなど。そして開発者として、みんながパターンに飛びついて、「ああ、このパターンとこのパターンとこのパターンとこのパターンを使わなければならない」となり、私の意見では、DDDの要点を見失ってしまいます。それをたくさん見かけます。そして私が思うに、これが企業のDDDトレーニングを受けた人々が「嫌だ、このDDDをすべてやったが嫌いだ。これはただの企業的なもの」と言う理由です。それは、使わなければならない20のパターンを暗記しなければならないことを知っているからです。それは違います。
Scott Wlaschin
英語はこちら
To me, and so if people are finding it boring and complicated, if it's too complicated, you know you have something going wrong with we.
私にとって、だから人々がそれを退屈で複雑だと感じているなら、それが複雑すぎるなら、何かが間違っているということを知っているはずです。
Ed Mann
英語はこちら
Were just saying like DDD seems like common sense and if and if we're saying that and in someone, as you say, is looking at the tactical look at these patterns and going what are they talking about common sense, you know this repository pattern, the value.
DDDは常識のように思えると言っていましたが、私たちがそう言っているのに、誰かが、あなたが言うように、戦術的にこれらのパターンを見て、「常識について何を話しているんだ、このリポジトリパターン、値オブジェクト...」と言っているとしたら。
Ed Mann
英語はこちら
But no, we're talking about the bits the strategic does, you know, because it's something. This is the bit that makes sense. You're trying to solve a problem and you solve it in the problem in the language that the user what is used you.
でも違います、私たちは戦略的な部分について話しているのです。それが何かだからです。これが意味をなす部分です。あなたは問題を解決しようとしており、ユーザーが使っている言語で問題を解決するのです。
Ed Mann
英語はこちら
Know the problem space that you're in. Exactly. That's it. That's it. If you understand that, to me that is DDD and everything else is just other stuff. But again, as developers, we just love to get and we love to give things names and we love to make the names very complicated so that other people can't.
あなたがいる問題空間を知ることです。その通りです。それです。それです。それを理解すれば、私にとってそれがDDDであり、他のすべてはただの他のものです。しかし再び、開発者として、私たちは物事に名前を付けることが大好きで、他の人が理解できないように名前を非常に複雑にすることが大好きです。
Ed Mann
英語はこちら
Understand names with rules that we can then tell other people they've done it wrong. Exactly. We can have ambiguity around those.
ルール付きの名前を理解して、他の人に「間違ってやった」と言えるようにします。その通りです。それらの周りに曖昧さを持つことができます。
Ed Mann
英語はこちら
Things and then we can be like, they're right.
物事について、そして私たちは「彼らは正しい」と言えます。
Scott Wlaschin
英語はこちら
And they're, yeah, it's, and then you have people gatekeeping it and it's just like, yeah, it's the whole thing. It is very sad sometimes the DD people unfortunately kind of got sucked into that as well. The DDD community themselves got sucked into. I mean, here's a good example. When you have a programming conference, we are very programmers tend to be very isolated. You know, you have language specific conferences. Then even if you have a generic one, the people of the conference that almost always programmers, you don't have testers and maybe you have a few testers you don't have.
そして彼らは、ええ、そうです、そして人々がそれをゲートキーピングして、それは全体のことです。DDDの人々も残念ながら、それに吸い込まれてしまったのは時々とても悲しいことです。DDDコミュニティ自体がそれに吸い込まれました。つまり、これは良い例です。プログラミングカンファレンスがあるとき、私たちプログラマーは非常に孤立する傾向があります。言語固有のカンファレンスがあります。そして、汎用的なものがあったとしても、カンファレンスの人々はほぼ常にプログラマーで、テスターはいないし、少数のテスターがいても...
Scott Wlaschin
英語はこちら
Developers who have input into things, and this tends to be database conferences are different from programming conferences. And it's like we're very, very isolated from other people who actually are working in the same, trying to achieve the same thing we are. But we tend to be very insular about how we do that. So anyway.
物事に意見を持つ開発者がいます。そして、データベースカンファレンスはプログラミングカンファレンスとは異なる傾向があります。私たちは、実際に同じことをしようとしている、私たちと同じことを達成しようとしている他の人々から非常に、非常に孤立しています。しかし、私たちはそれを行う方法について非常に内向きになる傾向があります。とにかく。
Ed Mann
英語はこちら
No, it's so true. And again, it's empathy. It goes back to that. It's about being that you're trying to solve a problem. And as you say, in that case, we're talking to our almost in a silo of ourselves without saying that, hey, do you know that all these other people here to help solve?
いえ、本当にその通りです。そして再び、それは共感です。それに戻ります。あなたが問題を解決しようとしているということについてです。そしてあなたが言うように、その場合、私たちは「ちょっと、この問題を解決するのを手伝ってくれる他のすべての人々がここにいることを知っていますか？」と言わずに、ほぼ自分たちのサイロの中で話しています。
Ed Mann
英語はこちら
This problem with us, and also we're trying to solve a problem for that person there. So maybe it's a good idea that we all talk together, but I think that's the trouble is the talking part, the communication part.
私たちと一緒にこの問題を、そしてまた私たちはあそこにいるその人のために問題を解決しようとしています。だから、みんなで一緒に話すのは良いアイデアかもしれませんが、問題は話すこと、コミュニケーションの部分だと思います。
(1)-2 はこちら
(1)-3 はこちら
Discussion