Domain Modeling Made Functional Part 1 with Scott Wlaschin
最近聞いたポッドキャスト、 Compiled Conversation #8 がドメイン駆動設計の入門としてすごくよかったので、英語で文字起こしして、和訳をしました。参加者のお二人に和訳をブログに載せる許可をいただきました。LLMによる機械翻訳ベースなので、細かな表現が意訳されていたり、また文字起こしの間違いにより一部おかしな内容になっているかもしれません。ぜひ英語でわかる方は本編を英語で聞かれることをお勧めしますが、日本語の和訳だけでもニュアンスが十分伝わるので、よろしければご覧ください。
(1)-1はこちら
(1)-2 はこちら
(2)-1 はこちら
(2)-2 はこちら
(2)-3 はこちら
podcastのリンクはこちらです。
ガベージイン・ガベージアウトの概念
Scott Wlaschin
英語はこちら
Yeah, so garbage in. I mean, it's just an old phrase, I think.
ええ、ガベージイン。つまり、それは古い言葉だと思います。
Scott Wlaschin
英語はこちら
I don't know if it's used before computers, but it's probably, it's probably been around for ages. So yeah, if you have bad input, you can have the best algorithm. Let's say you have the best programme in the world written in the best programming language with 100% tests and 100% everything and everything, all the fantastic programmes. But if you put in bad inputs, you're going to get bad outputs no matter how good your programme is. So in this not, you know, that's, that's basically it. So my thing is if you can have good inputs, you're going to have good outputs. If you don't have good, you won't have good outputs. So to me it's more important.
コンピューター以前に使われていたかどうかは分かりませんが、おそらく何年も前からあったでしょう。だから、悪い入力があるなら、最高のアルゴリズムを持つことができます。世界最高のプログラミング言語で書かれた世界最高のプログラムで、100%のテストと100%のすべて、すべてが素晴らしいプログラムを持っているとしましょう。しかし、悪い入力を入れるなら、プログラムがどんなに良くても悪い出力を得るでしょう。だから、それが基本的にそれです。だから私の考えは、良い入力を持つことができるなら、良い出力を得るでしょう。良いものを持っていないなら、良い出力は得られません。だから私にとってより重要です。
Scott Wlaschin
英語はこちら
Get a good input I'd rather have a good input with a bad programme than a bad input with a good programme because you know there's no way, no matter how good your programme is, if the inputs bad, the outputs bad, it can't correct that. So that's the whole point of design. So to me this is what design is design is minimising the garbage in or the kind of discovery part of design, listening to the customers trying to figure out what is it you're trying to build and why you're trying to build it and what is the goal of building it. All this stuff. If you can get that right, then chances are that the.
良い入力を得る。良いプログラムで悪い入力を持つよりも、悪いプログラムで良い入力を持つ方が良いです。なぜなら、プログラムがどんなに良くても、入力が悪ければ出力も悪く、それを修正することはできないからです。だからそれが設計の全体的なポイントです。だから私にとって、これが設計です。設計はガベージインを最小化すること、または設計の発見部分、顧客の話を聞いて、何を構築しようとしているのか、なぜ構築しようとしているのか、構築の目標は何かを理解しようとすることです。このすべて。それを正しく行うことができるなら、おそらく...
Scott Wlaschin
英語はこちら
Programme will be successful and I mean it there's actually lots of real world examples of this of very successful programmes which are written in a terrible programming language by somebody who's very inexperienced, but because they listen to the customers, that programme ends up being very successful. If Facebook is probably a good example of this, you know, written in Pearl or Amazon, the first Amazon was written in Perl and Facebook's written in PHP. And also it's like yeah, no testing, no proper development process, but you know, very good at listening to what people want is.
プログラムは成功するでしょう。実際に、これの現実世界の例がたくさんあります。非常に経験の浅い人によってひどいプログラミング言語で書かれた非常に成功したプログラムですが、顧客の話を聞いたため、そのプログラムは非常に成功しました。Facebookはおそらくこれの良い例です。PerlかAmazonで書かれ、最初のAmazonはPerlで書かれ、FacebookはPHPで書かれました。そして、ええ、テストなし、適切な開発プロセスなしですが、人々が望むことを聞くのが非常に上手です。
Ed Mann
英語はこちら
The problem it solves a person has and then you make the garbage in.
それが解決する問題を人が持ち、そしてガベージインを作ります。
Ed Mann
英語はこちら
It was good in.
それは良い入力でした。
Scott Wlaschin
英語はこちら
You know, exactly. But then you have a really fantastic team of programmers, whether all expert programmers and they're all writing in Haskell or Rust or something, and the programmer fails miserably because they're not doing the right thing. So that's what I mean by garbage in, garbage out. And we spend a lot of time as developers thinking about programming. We talk about what's the best programming language and what's the best testing system and you know, debugging and blah, blah, blah, blah. We spend a lot of time talking about that, but we don't nearly, we don't spend enough time talking about getting the right input and the whole design process. I think that's.
まさにその通りです。しかし、本当に素晴らしいプログラマーのチーム、すべてが専門プログラマーで、HaskellやRustか何かで書いているチームがあっても、正しいことをしていないためプログラムは惨めに失敗します。だからそれが私がガベージイン・ガベージアウトで意味することです。そして私たちは開発者としてプログラミングについて考えることに多くの時間を費やします。最高のプログラミング言語は何か、最高のテストシステムは何か、デバッグなどについて話します。それについて話すことに多くの時間を費やしますが、正しい入力を得ることと全体的な設計プロセスについて話すことに十分な時間を費やしません。それが...
Ed Mann
英語はこちら
Much more. Yeah, absolutely. So with your books, I've been reading your book. I was reading your book again like a couple of weeks ago and then also I've been doing some machine learning bits and pieces and it comes up there a lot, the garbage in, garbage out. We have pre training data. Exactly. If you look at it from that way, it's like yeah, if I've got this big new model and I'm training it, I'm giving it bad data. Yeah, the output is going to be bad as well. It doesn't know any else. So you have to yeah, your pre training set, you have to put a lot of work in there to make that valuable to then be able to have valuable output. Exactly yeah, I mean.
はるかに重要です。ええ、絶対に。あなたの本で、私はあなたの本を読んでいます。数週間前に再びあなたの本を読んでいて、また機械学習の断片をやっていました。そこでガベージイン・ガベージアウトがよく出てきます。事前訓練データがあります。その通りです。その方法で見ると、「ええ、この大きな新しいモデルがあり、それを訓練している、悪いデータを与えている。出力も悪くなるでしょう。他に何も知りません」となります。だから、事前訓練セットに多くの作業を投入して、それを価値あるものにし、価値ある出力を得られるようにしなければなりません。その通りです、ええ。
Scott Wlaschin
英語はこちら
A good example, yeah, training, when you're training machine learning, got to have good if you have, yeah, definitely got to have your good input. I mean, and a lot of the data science people, you know, they're given messy, messy output from some system and they spend a lot of time cleaning up the data. And I mean, my understanding of the people I know who do data science is they spend 90% of the time cleaning up the data and they need like 10% running the algorithms.
良い例です、ええ、訓練、機械学習を訓練するとき、良いものを持つ必要があります。ええ、確実に良い入力を持つ必要があります。つまり、多くのデータサイエンスの人々は、いくつかのシステムから乱雑な出力を与えられ、データをクリーンアップすることに多くの時間を費やします。私が知っているデータサイエンスをする人々についての理解では、彼らは90%の時間をデータのクリーンアップに費やし、10%だけアルゴリズムの実行に必要とします。
Ed Mann
英語はこちら
Yeah, Well, this is it. And it's like feature engineering. All these bits is all these bits, as you say, where they are, they'll, you know, in a very concrete way there you'll.
ええ、まあ、これがそれです。そしてそれは特徴量エンジニアリングのようなものです。これらすべての部分は、あなたが言うように、彼らがいるところで、非常に具体的な方法でそこで...
共有メンタルモデルの概念
Ed Mann
英語はこちら
You're seeing how they're trying to decipher the messy world into a model, into a way input that can actually be used, you say, within their systems. Again, it's the communication thing. Maybe in these kind of cases, they could actually talk to the other people to get better outputs, to have their better inputs for them. But yeah, there's a lot of work there that goes into that. Exactly. Yeah. And so from there, one key part of the DDD side of things there is, is the shared model. And I know we've spoken a little bit about it, but we could maybe, again, yeah, to focus on what is a shared model. So a shared model is just.
彼らが乱雑な世界をモデルに、彼らのシステム内で実際に使用できる方法の入力に解読しようとしている方法を見ています。再び、それはコミュニケーションのことです。これらの種類のケースでは、彼らは実際に他の人々と話して、より良い出力を得て、彼らのためのより良い入力を持つことができるかもしれません。しかし、ええ、そこに投入される多くの作業があります。その通りです。ええ。そして、そこからDDD側面の重要な部分の一つは、共有モデルです。そしてそれについて少し話したことを知っていますが、再び、共有モデルが何かに焦点を当てることができるかもしれません。共有モデルは単に...
Scott Wlaschin
英語はこちら
Something that we all agree on that's in our heads really that's not written down. And the nouns you I like to use here is if you go into a restaurant or a cafe and I order some eggs or something, hopefully everyone in the waiter and the chef, they know what I'm talking about when I say, can you make me a fried egg? They have, we all have the same mental model of what that means. And you know, if I had to write down a 200 page document on how to make a scrambled egg or something and I handed that to the waiter and the waiter handed that to.
私たち全員が合意している、実際に私たちの頭の中にある、書き留められていないもの。ここで使うのが好きな例えは、レストランやカフェに行って卵か何かを注文するとき、うまくいけばウェイターとシェフの全員が、「目玉焼きを作ってくれませんか？」と言ったときに私が話していることを知っています。彼らは、私たち全員がそれが何を意味するかの同じメンタルモデルを持っています。そして、スクランブルエッグの作り方について200ページの文書を書いて、それをウェイターに渡し、ウェイターがそれを...に渡すとしたら。
Scott Wlaschin
英語はこちら
Chef, that wouldn't work. I mean, you could say, well, I've documented everything in great deal, but that's not how restaurants work. The chances are that it'd be worse. You get a worse meal out of it. The fact that we all know what we're talking about, We have the shared mental model and that's I guess the idea is that if everyone has the same idea in their heads, there's going to be less miscommunication and also less need for, you know, 200 page documents. We all agree on what's important and we all understand. We always use the same words. We have the same concepts. It's better communication and less overheads.
シェフに、それはうまくいかないでしょう。つまり、「すべてを詳細に文書化しました」と言うことができますが、それはレストランの動作方法ではありません。それはより悪くなる可能性があります。より悪い食事を得るでしょう。私たちが何について話しているかを知っている事実、私たちは共有メンタルモデルを持っています。そしてそれが、みんなが頭の中に同じアイデアを持っているなら、より少ない誤解と200ページの文書の必要性も少なくなるという考えです。私たち全員が何が重要かに同意し、私たち全員が理解しています。私たちはいつも同じ言葉を使います。同じ概念を持っています。より良いコミュニケーションとより少ないオーバーヘッドです。
Scott Wlaschin
英語はこちら
So that's what I mean.
だからそれが私の意味することです。
Ed Mann
英語はこちら
By that, yeah. And you mentioned in the D book a talk by Dan N where the developers are trained to be traders alongside real traders.
それによって、ええ。そしてDDDの本でDan Northの講演について言及されました。そこでは開発者が実際のトレーダーと一緒にトレーダーになる訓練を受けました。
Scott Wlaschin
英語はこちら
Yeah. So, I mean, he gives an example. He gave a talk a long time ago where he said it was the best project he worked on. And they were doing stock market training and they hired, they hired developers to write the software to help the traders do the trades. You know, I don't quite know how that works. You know, they're clicking buttons to do trades or whatever.
ええ。つまり、彼は例を挙げます。彼は昔講演を行い、それが彼が取り組んだ最高のプロジェクトだったと言いました。彼らは株式市場の取引をしており、トレーダーが取引を行うのを助けるソフトウェアを書くために開発者を雇いました。どのように動作するかよく分かりませんが、取引を行うためにボタンをクリックしているか何かです。
Scott Wlaschin
英語はこちら
And if you're if you're a software developer and you don't know how.
そして、もしあなたがソフトウェア開発者で、どのように...かを知らないなら。
Scott Wlaschin
英語はこちら
Trading systems work. Your Polygon end up writing something pretty bad. It's like if you don't know how accounting works, you know you're going to make a lot of mistakes. So what they did is they sent the software developers to the same training programme that the traders were on so that the software developers knew the same jargon, the same concepts, the same language and then they pair programmed. We didn't do pair programming for each. Each developer sat next to a trader as they were working and when the trader, they would see the trader doing trades and.
取引システムがどう動作するか。結局かなり悪いものを書くことになるでしょう。会計がどう動作するかを知らなければ、多くの間違いを犯すことになるのと同じです。だから彼らがしたことは、ソフトウェア開発者をトレーダーが受けているのと同じ訓練プログラムに送り、ソフトウェア開発者が同じ専門用語、同じ概念、同じ言語を知るようにしました。そして彼らはペアプログラミングをしました。各自でペアプログラミングをしたのではありません。各開発者は作業中にトレーダーの隣に座り、トレーダーが取引を行うのを見ました。
Scott Wlaschin
英語はこちら
Developer, you know, this is the developers say, well, actually, I could make that more efficient by, you know, writing a little macro for you or adding an extra button for you to make it do this thing or to whatever. Because and they could talk to the trader directly and exchange the information and then the developer could write to fix to do whatever the new thing was and have it ready the next day. And so they didn't need a test suite, they didn't need a complicated, they didn't need any document. They didn't write any 200 page documents. They were just talking to each other, but because they all were on the same page.
開発者は、「実際に、小さなマクロを書いたり、追加のボタンを追加したりして、これをより効率的にできます」と言いました。そして彼らはトレーダーと直接話し、情報を交換でき、開発者は新しいことが何であれ修正を書いて、翌日に準備することができました。だから彼らはテストスイートも、複雑なものも、文書も必要ありませんでした。200ページの文書を書くことはありませんでした。彼らはただお互いに話していましたが、全員が同じ認識を持っていたからです。
Scott Wlaschin
英語はこちら
The developers could rapidly generate stuff which is very valuable to the traders. And Down N said it was great. I mean, he was surprised because it didn't really follow a process in terms of they didn't follow an agile process, they didn't have source control, they didn't have all this stuff. They just had people talking to each other, writing code as fast as they could. And it said it was fantastic. And it was, you know, exactly what the traders wanted because the developers were literally looking over their shoulder.
開発者はトレーダーにとって非常に価値のあるものを迅速に生成できました。Dan Northはそれが素晴らしかったと言いました。彼は驚きました。なぜなら、それは本当にプロセスに従っていなかったからです。アジャイルプロセスに従わず、ソースコントロールもなく、これらすべてのものがありませんでした。彼らはただ人々がお互いに話し、できるだけ速くコードを書いていました。そしてそれは素晴らしいと言いました。そして、それはトレーダーが望んでいたものそのものでした。開発者が文字通り彼らの肩越しに見ていたからです。
Ed Mann
英語はこちら
As they worked and I guess with that then so.
彼らが作業している間に、そしてそれから...
Ed Mann
英語はこちら
Because obviously that is a very interesting use case where they have essentially become domain experts.
明らかにそれは非常に興味深いユースケースで、彼らは本質的にドメインエキスパートになりました。
ドメインエキスパートとの協働
Ed Mann
英語はこちら
But I guess we can't all become the main experts in all the fields as the software developers that we're going to be doing. I think there's we should have an understanding and I guess it's trying to work out how can we improve our discovery and detective work because that's something as a developer, I feel like I become more, you become more attuned to it's listening and it's kind of understanding good questions and follow-up questions and things to ask to try and unpick this. I'm wondering.
しかし、ソフトウェア開発者として行うすべての分野でメインエキスパートになることはできないと思います。理解を持つべきだと思いますし、発見と探偵作業をどのように改善できるかを理解しようとすることだと思います。開発者として、より調和し、聞くことと良い質問やフォローアップ質問、これを解明しようとするために尋ねることを理解することになると感じます。
Scott Wlaschin
英語はこちら
For you. So you can't use that. Yeah, you can't really become an expert, but I would say that you should become as much an expert as you possibly can.
あなたのために。だからそれを使うことはできません。ええ、本当にエキスパートになることはできませんが、可能な限りエキスパートになるべきだと言うでしょう。
Scott Wlaschin
英語はこちら
And sometimes, you know, you've seen I've worked, there's some places where the developer has been working there for 20 years and they know more about how the company works than anybody else because, you know, they wrote the software that runs the whole company. So they are the domain expert as well as the developer. But yeah, I mean, if I'm writing an accounting programme, I should at least, you know, spending a week learning, watching accounting videos and reading accounting book and maybe going on a one week accounting course or something. That would be to me, that's money well spent. You know, I'm not going to become a certified accountant, but at least I'm using.
そして時々、開発者がそこで20年間働いていて、会社全体を動かすソフトウェアを書いたため、会社がどう動作するかを他の誰よりも知っている場所があります。だから彼らは開発者であると同時にドメインエキスパートでもあります。しかし、会計プログラムを書いているなら、少なくとも1週間学習し、会計動画を見て、会計の本を読み、1週間の会計コースに行くべきです。それは私にとって、よく使われたお金です。公認会計士になるつもりはありませんが、少なくとも使っています。
Scott Wlaschin
英語はこちら
I know what the words are, what the concepts are. And, you know, if I'm writing aerospace software, you know, I should understand a little about how planes fly. You know, otherwise I might make some really bad mistakes, you know. So I would say, you know, there's, again, it depends, but maybe not spending six months learning, but spending a couple of weeks learning and also just talking to the people who are the experts, you can just learn by being in the same room as them and watching what they do. So again, rather than coming in with a bunch of predetermined conclusions about, well, you really need to do.
言葉が何か、概念が何かを知っています。そして、航空宇宙ソフトウェアを書いているなら、飛行機がどう飛ぶかについて少し理解すべきです。そうでなければ、本当に悪い間違いを犯すかもしれません。だから、再び状況によりますが、6ヶ月学習に費やすのではなく、数週間学習に費やし、エキスパートである人々と話すことで、彼らと同じ部屋にいて、彼らがすることを見ることで学ぶことができます。だから再び、あなたが本当にする必要があることについて予め決められた結論を持って来るのではなく。
Scott Wlaschin
英語はこちら
You need to do this. It's just like watch and listen and learn before you try to fix things, you know?
これをする必要があります。物事を修正しようとする前に、見て、聞いて、学ぶことです。
Ed Mann
英語はこちら
I think, yeah. But when you were very on to that, it's so true, is that it's about listening and it's about not your preconceived notions of like, right, I'm here now, this is how we're going to solve your problem.
思います、ええ。しかし、あなたがそれについて非常に正しかったとき、それはとても真実で、それは聞くことについてで、「よし、今ここにいる、これがあなたの問題を解決する方法だ」という先入観についてではありません。
Ed Mann
英語はこちら
I mean, how does that does it when you even say that it sounds it how we're going.
つまり、それを言うときさえ、どのように私たちが進むかのように聞こえます。
Scott Wlaschin
英語はこちら
To solve your problem. It's you. I see, I see this a lot with the you mean, you see where this is the techie people, It's like, you know, they say, well, healthcare in America is a big problem and we're just going to come in, we're going to fix it. I don't understand why it's so complicated or we're going to solve something, you know, transports, why you just could build a bunch of tunnels everywhere. I don't see why they haven't thought of this.
あなたの問題を解決するために。それはあなたです。技術者の人々でこれをよく見ます。「アメリカの医療は大きな問題で、私たちがやって来て、修正するつもりだ。なぜそんなに複雑なのか理解できない」または「交通について何かを解決するつもりだ、なぜどこでもトンネルを建設できないのか。なぜ彼らがこれを考えなかったのか分からない」と言います。
Scott Wlaschin
英語はこちら
I can't believe these so-called transport experts are so stupid. They haven't thought about building a tunnel. Yeah, I mean, they probably have thought about it. And there's probably, and even if they think it's, there's probably reasons why it's not happening. You know, listen and talk to people. I mean, yes, sometimes there's entrenched things where you can kind of breakthrough some of the entrenchments where they could disrupt the standard thing. But normally there's a reason why people do things.
これらのいわゆる交通専門家がこんなに愚かだなんて信じられません。トンネル建設について考えていません。ええ、つまり、彼らはおそらく考えたことがあるでしょう。そして、たとえ彼らがそう思っても、それが起こらない理由があるでしょう。人々に聞いて話してください。ええ、時々、標準的なものを破綻させることができる既存のものを突破できる既存のものがあります。しかし、通常、人々が物事を行う理由があります。
Ed Mann
英語はこちら
Lot of nuance to things yeah, yeah, there's a lot of. And you know, case in point, like say you know, you're starting a new company and.
物事にはたくさんのニュアンスがあります。ええ、ええ、たくさんあります。そして例えば、新しい会社を始めるとして。
Ed Mann
英語はこちら
You go in and you're like, why are they using this framework? What's going on here? Everything has a reason. Like you want a bit at first. You want to believe that everyone's done things for good intent, so that's the first thing. And secondly, there's going to be a reason. So the first thing you should be doing here is not coming in similar to how solving these problems is imposing what we should be doing this, like you say, the tunnel. We should just build these tunnels here or influence.
入っていって「なぜ彼らはこのフレームワークを使っているのか？何が起こっているのか？」と思います。すべてに理由があります。最初は少し欲しいです。みんなが良い意図で物事を行ったと信じたいです。それが最初のことです。そして第二に、理由があるでしょう。だから、ここで最初にすべきことは、これらの問題を解決することがトンネルのように私たちがすべきことを押し付けることと似た方法で入ることではありません。ここにこれらのトンネルを建設すべきか、影響を与えるべきです。
Ed Mann
英語はこちら
Listen, spend all that time, the best thing you can do as a, as a programmer, and as you know, solving.
聞いて、すべての時間を費やして、プログラマーとして、そして知っているように、解決することとして、できる最良のことです。
Scott Wlaschin
英語はこちら
These problems is listening, right? There's a famous thing called Chesterton Fence which is exactly this. And it's the idea that before you'd RIP down this fence, understand why it was built in the 1st place. You know, it may be that it doesn't need to exist anymore, but maybe it does need to exist, you know, maybe at least you should understand before you just blindly go in and you know.
これらの問題は聞くことです、そうですね？まさにこれであるChesterton's Fenceという有名なものがあります。その柵を取り壊す前に、なぜ最初に建てられたのかを理解するという考えです。もう存在する必要がないかもしれませんが、存在する必要があるかもしれません。少なくとも盲目的に入って行く前に理解すべきです。
Ed Mann
英語はこちら
Knock everything down. I like that. Yeah, so true. And so if we're thinking, obviously the one thing is to learn becoming somewhat of a domain expert yourself in this.
すべてを壊すことです。それが好きです。ええ、とても真実です。そして考えているなら、明らかに一つのことは、これにおいて自分自身がある程度のドメインエキスパートになることを学ぶことです。
Ed Mann
英語はこちら
Build, you know, dabbling into this and being able to provide yourself with a concrete understanding enough to start these conversations. But what kind of things are there like tooling wise, structure wise that you know, developers and other people are like can do to actually try and distil this information?
構築、これに手を出し、これらの会話を始めるのに十分な具体的な理解を自分に提供できることです。しかし、開発者や他の人々が実際にこの情報を蒸留しようとするためにできる、ツール面、構造面でどのようなものがありますか？
Scott Wlaschin
英語はこちら
That's a hard 1. I don't think these are people. These are soft skills. These are people skills. And that's why I think learning about anthropology is useful, because that's what anthropologists do, is they listen. So yeah, just learning about. It's not really.
それは難しい問題です。これらは人々ではないと思います。これらはソフトスキルです。これらは人間スキルです。そして人類学について学ぶことが有用だと思う理由は、それが人類学者がすることだからです。彼らは聞きます。だから、ええ、ただ学ぶことです。それは本当に...ではありません。
Scott Wlaschin
英語はこちら
Not really a technical.
本当に技術的なものではありません。
Scott Wlaschin
英語はこちら
Programming skill, I don't know if there's any kind of definitive way of doing that really. I guess I just done it the hard way. I mean, normally for me it was making a bunch of really bad mistakes where I thought I knew what I was doing and I didn't listen to other people and then everything was really bad. Didn't go well. Yeah, didn't go well. It's like, OK, I'm never gonna at least to my to my credit, it's like, oh, I'm never gonna do that again. And it's like, what can I do differently next time to stop the.
プログラミングスキル、それを行う明確な方法があるかどうか分かりません。私はただ困難な方法でやったと思います。通常、私にとって、それは自分が何をしているか知っていると思い、他の人々の話を聞かず、すべてが本当に悪くなるという本当に悪い間違いをたくさん犯すことでした。うまくいきませんでした。ええ、うまくいきませんでした。「オーケー、少なくとも私の名誉のために、二度とそれをしないつもりだ」という感じです。そして「次回、それを止めるために何を違ってできるか？」となります。
Scott Wlaschin
英語はこちら
Thing happening and so it's like OK, I need to completely change the way I think about programming.
そのことが起こり、「オーケー、プログラミングについて考える方法を完全に変える必要がある」となります。
Scott Wlaschin
英語はこちら
And and not focus on the technology, but focus on listening to people.
そして技術に焦点を当てるのではなく、人々の話を聞くことに焦点を当てるのです。
イベントストーミングなど手法について
Ed Mann
英語はこちら
And said, no, that's beautiful. I guess some some things maybe like I could be good to talk about like event storming. And then there's the new and domain storytelling. I don't know what successes you've had using those.
そして言いました、いえ、それは美しいです。イベントストーミングのようなもの、そして新しいドメインストーリーテリングについて話すのが良いかもしれません。それらを使ってどんな成功を収めたか分かりません。
Scott Wlaschin
英語はこちら
Kind of things, yeah, I haven't. I mean, there's a lot of, there's a lot of people out there. I would encourage people to learn as much about that. I mean, event storming is, I think event storming is a very good way to do stuff because that is, again, it's focusing on a lot of.
そのようなこと、ええ、していません。つまり、多くの、多くの人々がそこにいます。人々にそれについてできるだけ学ぶことを勧めます。イベントストーミングは、イベントストーミングは物事を行う非常に良い方法だと思います。なぜなら、それは再び、多くの...に焦点を当てているからです。
Scott Wlaschin
英語はこちら
Design historically focused on getting the debate database right because the database.
設計は歴史的にデータベースを正しく取得することに焦点を当ててきました。なぜならデータベースは...
Scott Wlaschin
英語はこちら
The centre of the thing, so you've got to get the schema right and all this stuff and that's. I still encourage people to know a lot about. I'm actually shocked that people don't know anything about databases today because.
物事の中心であり、スキーマを正しく取得しなければならず、このすべてです。私は今でも人々に多くを知ることを勧めています。今日、人々がデータベースについて何も知らないことに実際にショックを受けています。なぜなら...
Ed Mann
英語はこちら
That's, you know, I grew up just weirdly, we've pushed it to be RM. We just want to be a prognostic from this beautiful thing that can solve so many problems.
それは、奇妙に育ちました、私たちはそれをORMに押し込みました。多くの問題を解決できるこの美しいものから予後診断的でありたいだけです。
Scott Wlaschin
英語はこちら
For us, yeah, I mean, I think everyone, I think all developers should understand SQL and I think they should understand how relation databases work in terms of the relational algebra and all this stuff. I don't think I'm actually kind of shocked that people don't know that. But anyway, so going back, yeah, I mean, but.
私たちにとって、ええ、つまり、すべての人、すべての開発者がSQLを理解すべきだと思いますし、関係代数とこのすべての観点でリレーショナルデータベースがどう動作するかを理解すべきだと思います。人々がそれを知らないことに実際にショックを受けています。しかしとにかく、戻って、ええ、つまり、しかし...
Scott Wlaschin
英語はこちら
Event storming is rather than focusing on the schemas and the and the data, you focus on the activities that happen in a business. So data is not static. Typically the data changes because something happens. You get an order telling you to do something, you know, you get an invoice, you get an e-mail, somebody wants something, something happens that triggers some sort of activity in the business and identifying what those triggers are.
イベントストーミングは、スキーマとデータに焦点を当てるのではなく、ビジネスで起こる活動に焦点を当てます。だからデータは静的ではありません。通常、何かが起こるためデータが変化します。何かをするよう指示する注文を受け、請求書を得、メールを得、誰かが何かを望み、ビジネスでのある種の活動をトリガーする何かが起こります。そしてそれらのトリガーが何かを特定することです。
Scott Wlaschin
英語はこちら
And how the company reacts to those triggers is a great way as a very high level.
そして会社がそれらのトリガーにどう反応するかは、非常に高いレベルでの素晴らしい方法です。
Scott Wlaschin
英語はこちら
Way of thinking about modelling, if you if you start off there, that really gives you a lot of insight into what the business thinks is important. And then the event storming idea is to do that as a group rather than just having one person going around interviewing people, you actually do it as a group in a room with post it notes on the wall. And the idea again is that everyone builds a shared model of the business that you'd be surprised how many companies people don't talk to each other and they don't know how other parts of the business work. So getting everyone in a room together, not just developers, but everyone who cares about.
モデリングの考え方としてそこから始めれば、ビジネスが何を重要視しているのかについて多くの洞察が得られます。そしてイベントストーミングの発想は、誰か一人が人々にヒアリングして回るのではなく、壁にポストイットを貼りながら部屋でグループとして取り組むというものです。再度の狙いは、みんなでビジネスの共有モデルを構築することにあります。多くの企業では人々が互いに話をしないので、他部署がどう動いているかを知らない、ということに驚かされます。だから開発者だけでなく、関係者全員を一つの部屋に集めるのです。
Scott Wlaschin
英語はこちら
Project and and putting stuff up on a wall without any computers just with bits of paper and saying well you know this thing happens and that makes this other thing happen and then that talks with this other department over here. Just getting all that on a wall is a really good starting point for a design so that's basically what event storming is so I like that a.
プロジェクトに関わる人たちがコンピュータを使わず紙切れだけで壁に貼り、「これが起こると次にこれが起きる」「それがあちらの部署とつながる」と示していきます。そうやって全部を壁に並べることが、設計を始めるうえでとても良い出発点になります。つまりそれがイベントストーミングで、私はこの手法が大好きです。
Ed Mann
英語はこちら
Lot, yeah, And it aligns as you say, with it being able to learn, continue learning, communication. Again, it's communication with all.
そうですね、とても気に入っています。それに、あなたが言ったように、学び続けることやコミュニケーションとも一致します。みんなとのコミュニケーションですよね。
Scott Wlaschin
英語はこちら
These things, exactly. It's all about shared communication and it's building a shared model.
まさにそうです。共有されたコミュニケーションがすべてであり、共有モデルを築くことなのです。
Scott Wlaschin
英語はこちら
So sometimes there isn't a shared model and sometimes you have to build like you find.
共有モデルが最初から存在しないこともあり、その場合は状況に応じて一緒に作り上げなければならないことがあります。
Scott Wlaschin
英語はこちら
I find a lot that people in different departments have different words for the same thing. You know, like one department they say, well, this is a customer, another one says, well, no, this is a contact. It's like, is that actually the same thing? Or maybe it's the same thing so we can use the same word or, you know, whatever, but at least we can agree on what those things are.
異なる部署の人たちが同じものに別々の言葉を使っていることが本当に多くあります。ある部署では「これが顧客だ」と言い、別の部署では「いや、それはコンタクトだ」と言う。実際それは同じものなのか？ 同じなら同じ言葉を使えばいいし、そうでなくても少なくとも何を指しているか合意できます。
Scott Wlaschin
英語はこちら
That's an important part of the process as well, but it unpicks. I think this is the thing with all these types of tools, all these types of process, or I hate to say process, but like this communication, all this type of talking, it unpicks misunderstanding or alignment problems that could be.
それもプロセスの重要な一部で、この手のツールややり方—プロセスと呼ぶのは好きではありませんが—こうしたコミュニケーションによって誤解や認識のずれを解きほぐせるのです。
Scott Wlaschin
英語はこちら
Addressed exactly. And so this is, I mean, one of the things is that that a little bit of talking can, you know, as they say, a few weeks of programming can save hours of talking. So yeah, I mean, if you spend a couple of hours talking to people and clearing up all these misunderstandings and getting everyone on the same page, that may take a day or two, but that may save weeks and weeks of misunderstandings when you have a bug because you misunderstood.
まさにそれが解決につながります。よく言われるのは「数週間のプログラミングは数時間の会話を節約する」という逆の格言ですが、実際には数時間話して誤解を解き、全員の認識を揃えれば、一日二日かかってもその後の数週間の手戻りを減らせます。誤解が原因のバグで苦しむ必要がなくなるのです。
Ed Mann
英語はこちら
Something, and this goes in complete contrast to the. I just want to get on with programming exactly, which is what developers, you know, crudely would like.
ですがそれは、「とにかく早くコーディングを始めたい」という開発者の本能とは真っ向から逆行します。
Ed Mann
英語はこちら
Where when am I getting to code like why are we doing this talking?
『いつコードを書けるんだ？ なぜこんなに話しているんだ？』という感じですよね。
Scott Wlaschin
英語はこちら
When I said decoding exactly, it is, I mean, it somehow feels unnatural as a developer to do this. But in my experience, spending a couple of days or a week or even 2 weeks getting everyone on the same page about what's important and how things, you know, how the business works and stuff really can save a lot of time down the line. And it's you're much more likely to have a successful project because you just build, you know what you're building and you can use the same words and all, it's just, it's just in my.
開発者としてこういうことをするのは不自然に感じるかもしれませんが、私の経験では、何が重要か、ビジネスがどう動くのかを全員で共有するために数日、場合によっては一、二週間費やすことで、後々大きな時間の節約になります。何を作っているのかが明確になり、同じ言葉を使えるようになって、プロジェクトの成功率がぐっと高まるのです。
Scott Wlaschin
英語はこちら
It's just a much better way.
その方がずっと良いやり方なんです。
Ed Mann
英語はこちら
Of doing things you see it goes with that Dan N talk where they they are knowing what the problems are as well they're becoming that you know you're seeped into this knowledge and this understanding and this world and that's an exciting thing with the job we have I think it's very interesting where we do try and isolate ourselves whereas we've got this very exciting opportunity to be able to just jump into problems and that's something as developers intrinsically we have though well we have skills to you know try and tease this out and things like that and we obviously like solving problems this is where the problems are and and it.
物事の進め方として、Dan Nの講演で話されていたように、問題を理解し、その知識と世界に浸ることにつながっています。私たちの仕事の面白いところは、孤立しがちなのに、実際には問題のど真ん中に飛び込めるワクワクする機会があることだと思います。開発者は本質的にそうした問題を掘り下げるスキルを持ち、難題を解くのが好きです。だからこそ、その問題があるところに飛び込むべきなんです。
Ed Mann
英語はこちら
Even be that you don't write any code in that two weeks, you, you may find out that actually the requirements, you know, software in quotes, all the coding fun part in quotes that you want to do actually gets reduced. But what you've done in those conversations is actually solve lots of hard things around the business purely through that conversation. And that's part of your that's your value to the company, which exactly is it? You're not the code, it's the value that.
二週間の間に一行もコードを書かないことだってあります。いわゆる「ソフトウェア」や「楽しいコーディング」の部分が実は減るかもしれませんが、その会話でビジネスまわりの難題をたくさん解決しているのです。
Scott Wlaschin
英語はこちら
You're providing exactly. I mean, I can give you a concrete example. I worked at a skin care company for a while and.
それこそがあなたが提供している価値です。具体例を挙げると、私はしばらくスキンケア製品の会社で働いていました。
Scott Wlaschin
英語はこちら
I was building a product for them developing.
その会社のために製品を開発していたときの話です。
Scott Wlaschin
英語はこちら
You know, their internal products and stuff and it's, you know, it's very surprisingly complicated with all the form. It's basically a recipe for building things. You know, you add the various ingredients and you literally cook them up in a pot and that makes your skin lotion or whatever it is. But it's surprisingly complicated. And so I had to become a little domain expert on skin care products in order to write a good app. To me, that was one of the more successful products I worked on because I was constantly talking to the people who are the experts.
社内向けの製品を作っていたのですが、さまざまな処方があって驚くほど複雑でした。原料を加えて実際に鍋で煮込み、それがスキンローションなどになるのです。良いアプリを書くにはスキンケア製品のドメインエキスパートのようにならざるを得ませんでした。専門家たちと絶えず会話したからこそ、とても成功したプロダクトになったのです。
Scott Wlaschin
英語はこちら
And showing them prototypes and using the same words in my code as I was, you know, and that to me was very successful. Which is the complete opposite of how I would have done it in the old days. Which was to, you know, spend 2 weeks building a framework of classes and stuff and trying to come up with a database schema without actually talking to people, maybe talking to them for 30 minutes or trying to write down.
彼らにプロトタイプを見せ、コードの中でも彼らと同じ言葉を使っていました。昔の私なら二週間かけてクラスの枠組みやデータベーススキーマを考え、せいぜい三十分話を聞くだけで済ませていたでしょうが、それとは正反対のやり方でした。
Ed Mann
英語はこちら
As much as possible.
できるだけ詰め込もうとしていたりとか。
Scott Wlaschin
英語はこちら
Yeah, exactly. I mean, to be honest, one of the problems in the real world is that you're often not allowed as a developer. You're actually not allowed to.
本当にそうです。現実世界での問題の一つは、開発者がそれを許されない場合が多いことです。
Scott Wlaschin
英語はこちら
Directly talk to the users. Sometimes you have this thing where you can talk to your manager and the manager talks to somebody else, or you talk to an architect or a product owner or something and they talk to somebody elses manager who then talks to the, you know, if you don't have direct communication between various people, that is often a typical cause of failure of project as well, because the people aren't talking directly and the business will say, well, you know, everyone's busy doing their job. We haven't got time to have people talk to each other. But yeah, you know, but if you want this project to secede.
ユーザーと直接話すことを禁じられていることがよくあります。マネージャー経由で伝言し、さらに別の人へと伝わっていくと、関係者が直接会話しないためにプロジェクトが失敗する典型的な原因になります。ビジネス側は「皆忙しくて話し合う時間がない」と言いますが、成功させたいなら人々が話す時間を確保すべきです。
Scott Wlaschin
英語はこちら
If you can, you spend people spend a day talking to each other, that might really help.
可能であれば、一日かけてでも互いに話すだけで本当に助けになります。
Ed Mann
英語はこちら
It feels so counterinsuitive, doesn't it? And I love that. Another you just say in the book, it's like Chinese whispers, like telephone game. It's so true. It's like if we've got these layers, yeah. And then it's obviously time between them and stuff. And the REPL is not, you know?
直感に反するように感じますよね。本でも「伝言ゲームだ」と書かれていましたが本当にその通りです。層が重なり、時間も空き、REPLのように即時のフィードバックもありません。
Ed Mann
英語はこちら
A quick, fast feedback loop, right? Right. Of course it's not gonna work.
素早いフィードバックループなんて得られません。そりゃうまくいきませんよね。
Ed Mann
英語はこちら
But why do we think this?
なのに、なぜそれでうまくいくと思ってしまうんでしょう？
Scott Wlaschin
英語はこちら
Is going to work Yeah, exactly. So yeah, you allude to the game in America it's called telephone in England it's called Chinese systems. But it's the game where you it's the children's game where you talk you whisper something, somebody ear, they whisper into somebody else's ear they were spit. And by the time it goes around the room what comes out the other way is completely different from what you started with. But I mean everyone's saying was in a game it's very funny but in the real world it's not funny at all because you know but.
本当にその通りです。アメリカでは電話ゲーム、イギリスではチャイニーズ・ウィスパーズと呼ばれる子どもの遊びがありますが、最後には全く違う内容になってしまいます。遊びなら面白いですが、現実の世界では笑えません。
Ed Mann
英語はこちら
I don't know why businesses, but they're still down. That's exactly what we're doing. Like we talk about, oh, we have to have all these.
企業がなぜそんなことをするのか分かりませんが、私たちは実際にそれをやってしまっています。
Ed Mann
英語はこちら
But what you're doing essentially, as you say, is that child's game where you've said one thing and then it goes, it's like, well, that's exactly what happened. This is why this system, this, you know, this system that we built did not solve any of your problems. It solved.
あなたが言うように、それは子どもの伝言ゲームをしているのと同じです。だからこそ作ったシステムは誰の問題も解決しなかったのです。
Scott Wlaschin
英語はこちら
A problem, just not the one you asked for. Exactly. So I mean, a lot of the problem is a lot of managers and companies are not developers. They don't understand the process either. It's just like that's why you come in with your super duper scaled agile framework and then you can sell them on that anyway, that's the whole we can turn into ransom on software, on software development. But I mean we've touched.
別の問題は解決しても、頼まれていた問題ではありません。多くのマネージャーは開発プロセスを理解していないので、スケールドアジャイルのような大掛かりな枠組みを持ち込みたがりますが、その話を続けるとソフトウェア開発の愚痴になってしまいますね。
「データベース／クラス駆動設計への衝動と戦う」必要がある
Ed Mann
英語はこちら
It there you a little bit like databases and we talk about schemas and I think something that you mentioned in the book which is really good is like you mentioned fighting the impulse to do database class driven design and so I was.
そこではデータベースやスキーマの話にも触れていましたが、本で書かれていた「データベース／クラス駆動設計への衝動と戦う」という点について聞かせてください。
Scott Wlaschin
英語はこちら
Wondering what do you mean by that? Right, so if you know if you're an expert database person, if you know SQL inside and out, your natural tendency is to design a whole bunch of tables to represent them domain. And if you're an expert object oriented programmer, your natural instinct would be to create a whole bunch of classes to represent the domain and a class hierarchy.
SQLに精通した人はテーブルを設計したくなり、オブジェクト指向の達人はクラス階層を作りたくなるものです。
Scott Wlaschin
英語はこちら
And everything you know.
頭の中がその発想でいっぱいになるからです。
Scott Wlaschin
英語はこちら
That's because that's the way you think and you have to resist that temptation. And I can, I can just give you a very simple example which I use in my classes, which is if you're modelling a card game, you might realise that there's a difference between a normal unshuffled deck and a shuffled deck. And as an, oh programme, you might say, well, they both inherit from a base deck class or something, right? Because they have a lot in common. Or maybe there's a, maybe they're the same thing and there's a Boolean flag which is it shuffled or not, you know, you're modelling it.
しかしその誘惑に抗わなければなりません。カードゲームを例にすると、未シャッフルのデッキとシャッフル済みのデッキはまったく別物です。共通点が多いからといって基底クラスを作ったり、フラグ一つで区別したりするべきではありません。
Scott Wlaschin
英語はこちら
Say, don't do that. They're separate concepts. In the real world, a shuffle deck and an unshuffled deck have got nothing to do each other. You will never, you never want to mix them up, you know, and the fact they both are listed, you know, both a list of cards or a collection.
現実世界では両者は混同したくない別物です。どちらもカードのリストだからといってひとまとめにしないでください。
Ed Mann
英語はこちら
Of cards trying to find patterns that just are shoehorning these things in.
何でもパターンに押し込もうとするのは危険ですね。
Scott Wlaschin
英語はこちら
Exactly. Or it might even say, let's say you have a hand in if playing poker and you have a hand, that's five cards, right? Or whatever you say, well, that's also a list of cards. So I'm going to have a generic list of cards class, and they're all going to inherit from the list of.
そうです。ポーカーの手札もカードのリストだからと、汎用カードリストクラスに継承させたくなるかもしれませんが、
Scott Wlaschin
英語はこちら
And you know, we're thinking about implementation. That's in the real world. There is no such thing as a list of cards class, you know, that's not how it works. There's no point. Don't do that. They're separate concepts. Now when it comes to implementation, you might find there is something, but there's almost always it's not worth doing that. It keeps them separate. People in the real world do not want to mix them up. Don't try and think about how you can optimise inheritance and stuff. Just keep.
それは実装寄りの発想です。現実世界にカードリストという概念はありません。別々の概念として扱い、継承で最適化しようとしない方が良いのです。
Ed Mann
英語はこちら
Them separate and just don't jump to it immediately. You're you're thinking about a property. I think that's where I love the problem and solutions, but it's like think about the problem only.
別々にして、すぐに解法へ飛びつかないようにしろということですね。
Ed Mann
英語はこちら
Keep thinking about the problem, document the problem exactly. Don't jump. But I know as developers and I know as people like this is the thing we all do. If that you become more in quotes, experienced in something, you naturally jump to a salute, you know, you go, oh, actually we can quickly solve that now. But in this case you should be listening. That's all. The only thing you should be doing is.
問題について考え、記録し続けるだけでいい。経験を積むほど解決策に飛びつきがちですが、このケースでは耳を傾けることが唯一の仕事です。
Scott Wlaschin
英語はこちら
Listening, understanding these problems right and write down what they say. If you're talking to a domain, if you're talking to an expert poker player, they're not going to talk about base classes. They're not going to talk about Oh yeah, well, my hand also inherits has the same.
聞き、問題を理解し、言われたことを書き留めてください。ドメインエキスパートのポーカープレイヤーは基底クラスの話などしません。
Scott Wlaschin
英語はこちら
They don't inherit anything from each other. They're nothing to do with each other. You.
それらは互いに継承関係にないし、何の関係もありません。
Ed Mann
英語はこちら
Know. Yeah, they don't want to know they'll look at you, her and you'll be.
そんな話をしたら怪訝な目で見られます。
Scott Wlaschin
英語はこちら
Losing out on vital. Exactly. And they wouldn't use the words. So in the code, don't use a word that an expert wouldn't use. So a poker player would talk about hands and decks and shuffles and stuff. They would never use the base class or card manager or the card proxy or. So those concepts should not be in your design. Now obviously maybe in your implementation at some point you need to have complicated stuff, but in your design they should not exist because.
そうすると重要な情報を取り逃してしまいます。コードでもエキスパートが使わない言葉を使うべきではありません。ポーカープレイヤーはハンドやデッキ、シャッフルといった単語を使いますが、ベースクラスやカードマネージャー、カードプロキシとは言いません。設計にはそうした概念を入れるべきではないのです。実装で必要になることはあっても、設計には存在しません。
Scott Wlaschin
英語はこちら
That's not. They're not there in.
現実世界にはそんなものはないのです。
Ed Mann
英語はこちら
The real world, yeah, absolutely. And something else with that is you talk about is persistent ignorance, ignorance. And I think that's really interesting as well.
現実世界にはありませんね。本当にその通りです。そしてあなたが語る「持続的な無知」の話も面白いと思います。
Scott Wlaschin
英語はこちら
Yeah. Again, if I'm modelling, let's say, a card game, how do you store this in the database? Well, I don't care. That's not part of the domain. You know, obviously at some point you have to figure out how to store it, whether you store it in a document database or a relational database or whatever. But that is not part of the domain model. In the real world, you know, most things, you don't need to store things, they're just naturally exist. So in a card game, there's no concept of storing things. So yeah, you need to, at some point you need to worry about databases. But that's not, again, it's not part of the key design, it's not part of the core.
たとえばカードゲームをモデリングしているとして、これをデータベースにどう保存するかなんて気にしません。それはドメインの一部ではないからです。もちろん最終的にはドキュメントDBにするかリレーショナルDBにするかを決める必要がありますが、現実世界では多くのものはそのまま存在していて保存などしません。カードゲームに保存という概念はありません。だからデータベースを気にするのは後回しでよく、コアな設計とは別物なのです。
Scott Wlaschin
英語はこちら
Line of the system is how do you store something? I mean maybe in some cases it is, but in a lot of situations it isn't at all.
システムの主題が「どう保存するか」になる場合もあるかもしれませんが、多くのケースではそうではありません。
チーム構造と組織設計
Ed Mann
英語はこちら
Is something you mentioned. So we talked a bit about bounded contest there and we have talked about team dynamics there where we can kind of work out subdomains from distilling it down from what team current dynamics or organisation is. I'm just wondering that the inverse on that like kind of, you know, should we're saying like should we the subdomains we discover and then the bounded context we design dictate team structure and organisation?
境界づけられたコンテキストやチームのダイナミクスについて少し話しましたが、発見したサブドメインや設計した境界が、チーム構造や組織を決める指針になるべきでしょうか。
Scott Wlaschin
英語はこちら
Or that is that's the famous reverse Conway manoeuvre. So the idea, yeah. So the the the idea here is that the Conway thing he said that if you have 3.
それが有名なリバース・コンウェイ戦略です。コンウェイの法則では、三人のチームが三段コンパイラを作ると言っていましたね。
Scott Wlaschin
英語はこちら
You're going to have a classical key. If you have a three team people working on compiler, you're going to get 3 pass compiler. And the flip side of that is if you want to have a three pass compiler, have three teams. So you divide, make your organisation match the domain that you're trying to work on. So if you think there's three important concepts, 3 important domains or subdomains, you have three different teams to work on them. Which again, it makes sense because humans being humans, if you have four teams, you're going to have 4 subsystems and it's just human nature to do this way. And also it's just going to be you have 4 subsystems and three.
逆に言えば、三段コンパイラが欲しいなら三つのチームを用意しなければなりません。重要な概念やサブドメインが三つあるなら、それぞれにチームを割り当てる。人間は四つのチームがあれば四つのサブシステムを作りたがりますし、三つのチームで四つのサブシステムを扱えば軋轢が生じます。
Scott Wlaschin
英語はこちら
Teams, it's just going to be a lot of conflict, but you know, there's always going to be some sort of weird interaction.
だからチーム数とサブシステム数がずれると対立が増え、妙な相互作用が起きるのです。
Ed Mann
英語はこちら
On that 4th subsystem, and that's the whole thing, we've bounded context and kind of the rule released like the recommendation that you should be owned by one team because if we're all hitting into that one badly context, so that model, yeah, you can see that different teams interfacing with the same monolith or something, that's where a problem may occur.
四番目のサブシステムに複数チームが関わると問題が起こります。それが境界づけられたコンテキストには一つのチームが責任を持つべきだと言われる理由ですね。複数チームが同じモノリスに手を入れると衝突が生まれます。
Scott Wlaschin
英語はこちら
Right. And this is the analogy that also I think Eric Evans used is the classic 3 legged race. You know, each team should do one thing well.
その通りです。エリック・エヴァンスも三本足競走の例えを使っていました。
Scott Wlaschin
英語はこちら
And if you have multiple teams kind of step on each other's toes, that really slows you down. You're arguing about, well, my team wanted it this way and your team wants to do it this way. And the analogy here is a three legged Raceway. Literally, you try and run with your legs tied together and that's very slow and you fall over a lot. You know, if you want to run, don't tie people's legs. Let each team run at their own pace and do their own thing. And so this is one of the concepts in.
複数チームが互いの足を踏み合うと速度が落ち、転んでしまいます。走りたいなら足を縛ってはいけません。各チームが自分のペースで進めるようにするべきです。
Scott Wlaschin
英語はこちら
The when you're implementing domains is they should be autonomous.
ドメインを実装する際にも、それぞれを自律的に保つ必要があります。
Scott Wlaschin
英語はこちら
You should be able to do your own design without being impacted what another team is doing with their design. So if you're, if, if your designs are kind of interacting or they're, you know, you can't, I can't make this change because the other team doesn't like it. Your domains are not bounded, right? This whole thing of having a bounded and a boundary, I should be able to do my own thing without having to ask for your permission and vice versa. So this typically means that each subsystem or each domain should actually own their own database and they should own their own storage and own, you know, that's the kind of natural consequence of that.
他のチームが自分たちの設計で何をしているかに影響されることなく、自分たちの設計を進められるべきです。もし設計が相互に干渉し合っていて、「他のチームが気に入らないから、この変更ができない」という状況にあるなら、それはドメインが適切に境界付けられていないということです。境界と境界付けの本質は、相手の許可を求めることなく自分たちのことを進められるべきであり、その逆もまた然りです。これは通常、各サブシステムまたは各ドメインが実際に独自のデータベースを所有し、独自のストレージを所有すべきだということを意味します。これがその自然な帰結なのです。
Scott Wlaschin
英語はこちら
Because it just allows them to evolve independently without breaking other people's teams. And it's good for evolution, Kenny, if you want to evolve, you should be able to make a change to your code without breaking somebody else's code. So again, that's another classic idea. Now, this also crops up in microservices. People say This is why you should do microservices, but it's really microservices are not the answer. Subdomains are the answer because you could easily have microservices just because they're independently deployed. They still step on each other's toes. And it's a very common problem with badly designed microservices where I can't change.
なぜならそれによって、他のチームを壊すことなく独立して進化できるからです。進化のためにも良いことです。進化したいなら、他の誰かのコードを壊すことなく自分のコードを変更できるべきです。これもまた古典的な考え方です。さて、これはマイクロサービスでもよく話題になります。「だからマイクロサービスをやるべきだ」と言う人がいますが、実際にはマイクロサービスが答えではありません。サブドメインが答えなのです。なぜなら、マイクロサービスは独立してデプロイされるというだけで、それでも互いの足を踏み合うことは簡単に起こりえるからです。設計の悪いマイクロサービスでよくある問題で、変更できない状況に陥ります。
Scott Wlaschin
英語はこちら
This microservice because it's going to break all the other microservices that it tells you it's badly designed.
あるマイクロサービスを変えると他が壊れるようなら、それは設計が悪いというサインです。
境界づけられたコンテキストとモノリス
Ed Mann
英語はこちら
Yeah, and again, it's the whole thing of people pushing away from monolith where yeah, okay, I'm on lift with a bounded one single bounded context. But that bounded, if it doesn't conflict and everything, it's absolutely fine and you can make massive changes and easy wins there and you're just in process communication.
モノリスから距離を置きたいという声もありますが、単一の境界づけられたコンテキストならモノリスでも問題ありません。衝突がなければ大きな変更も楽ですし、同じプロセス内で通信できます。
Ed Mann
英語はこちら
Right. Absolutely. Bring a.
ええ、ネットワークを持ち込む必要もありません。
Scott Wlaschin
英語はこちら
Network. Exactly. That's the I I personally like modular monoliths, so each subsystem is a separate component, but it's deployed as.
そう、ネットワークが絡むと一気に複雑になります。私はモジュラーモノリスが好きで、各サブシステムをコンポーネントに分けつつ、一つのモノリスとしてデプロイします。
Scott Wlaschin
英語はこちら
Single monolith and with interfaces and APIs between them as if they were microservices, but within a single monoth. And that way each section of the monoth can be we factored without breaking anything else. And if you really want to make them decoupled, you can use a queue between an internal queue between the various subsystems in a monolith and you can scale it up that way. I mean, that seems like a much nicer way of doing it than microservices. You get all the network issues and stuff. So unless you really, really need a distributed system, I would avoid it. For most people, yeah.
単一のモノリスで、内部ではマイクロサービスであるかのようにインターフェースとAPIでやり取りします。そうすれば、モノリスの各セクションは他を壊すことなくリファクタリングできます。本当に疎結合にしたければ、モノリス内の様々なサブシステム間で内部キューを使うこともでき、そのようにしてスケールアップも可能です。つまり、マイクロサービスよりもずっと良い方法に思えます。マイクロサービスだとネットワークの問題など色々ありますから。ですから、本当に分散システムが必要でない限り、私なら避けます。ほとんどの人にとってはそうですね。
Scott Wlaschin
英語はこちら
People need it, but in general you don't.
必要な人もいますが、一般的には必要ありません。
Ed Mann
英語はこちら
Really need it, yeah. And and you say because you've done that work upfront to workout these banded contexts and stuff like breaking it out into a separate if you need it for due to, you know, certain scaling things or legal requirements or such. But it should not the choice to use that deployment that that way of breaking out should not be dictated like kind of dictate your design. Like the design can still be within a monolith. It just happens that I'm deploying it in this.
本当に必要な場合もありますね。そして、事前に境界づけられたコンテキストをきちんとワークアウトしておけば、スケーリングの都合や法的要件などで別々に分割する必要が生じても対応できます。ただし、デプロイメントの選択、つまり分割の方法が設計を支配するべきではありません。設計はモノリス内にあっても構わないのです。たまたまこの方法でデプロイしているだけで。
Scott Wlaschin
英語はこちら
Other way, that's right. So exactly, I mean, well the nice thing about to my mind is if you yeah, the subsystems that you design.
その通りです。サブシステムを独立して設計しておけば、
Scott Wlaschin
英語はこちら
Independent subsystems. You can choose how to deploy them. You can deploy them independently, or you can deploy them as a single monolith, or you can deploy them as microservices or as lambdas, or whatever. You have a lot of choice. The deployment technique is not tied to your code organisation.
モノリスとしても、マイクロサービスやラムダとしても、好きな方法でデプロイできます。デプロイ手法はコード構造に縛られません。
Ed Mann
英語はこちら
I suggest you make sure you mention subsystems there. That's energy because I always under the pressure. So you've got a modular monolith and then inside of that you'd have different bounded contexts that then communicate like is a subsystem a?
今お話に出た「サブシステム」という言葉について確認させてください。モジュラーモノリスの中のサブシステムとは、複数の境界づけられたコンテキストが連携する構造と理解して良いですか？
Scott Wlaschin
英語はこちら
Different. No, I tend to use. I just tend to use the, you know, subsystem and subdomain. And I mean, I guess I use the word. When I'm talking about domains, I'm talking about the design side of things, and when I talk about a subsystem, I'm talking about the implementation side of things.
私はサブシステムとサブドメインをほぼ同じ意味で使っています。ドメインと言えば設計面、サブシステムと言えば実装面を指す程度の違いです。
Ed Mann
英語はこちら
I guess, right, that's really cool and kind of moving on from that then like you mentioned in the book and in regards.
なるほど。とても参考になります。
ワークフローとビジネスプロセスの用語
Ed Mann
英語はこちら
Some business activities you mentioned scenarios, business processes and then workflows. I'm just wondering it be great to maybe breakdown what those?
そして本では、ビジネス活動をシナリオやビジネスプロセス、ワークフローと呼んでいました。それらの違いについて教えてください。
Scott Wlaschin
英語はこちら
Mean well, OK, so the problem is there's again, there's no standardised word for a business activity. And I wanted to sometimes, you know, people thought that classically they talked about use cases. So the design, the UML people talk about use cases, the agile people talk about user stories, the traditional business people talk about workflows, scenarios, all, it's all you know.
ええと、つまり問題は、またしてもビジネス活動を表す標準化された言葉がないということです。古典的にはユースケースについて話すことがありますよね。設計やUMLの人たちはユースケースについて話し、アジャイルの人たちはユーザーストーリーについて話し、伝統的なビジネスの人たちはワークフローやシナリオについて話します。すべて同じようなものなのです。
Scott Wlaschin
英語はこちら
There isn't really a standard word for these things. So I I like to use the word workflow because that to me implies a business process rather than a, a story is a bit too lightweight and a use case. But I often will use them interchangeably. To be honest, I'm not quite happy to switch between them in a particular thing. And again, people will start gatekeeping and say, well, it's a very subtle, there's an important difference between a use case and a scenario and a workflow. It's like, yeah, I'm sure there is, but I don't care what the difference is.
これらのものに対して本当に標準的な言葉はないんです。だから私はワークフローという言葉を使うのが好きです。なぜなら私にとってそれはビジネスプロセスを意味するものだからです。ストーリーは少し軽すぎますし、ユースケースも。でも、しばしばこれらを互換的に使います。正直なところ、特定の状況でそれらを切り替えることに完全に満足しているわけではありません。そしてまた、人々は門番のように振る舞い始めて、「ユースケースとシナリオとワークフローには非常に微妙な、重要な違いがある」と言うでしょう。ええ、確かにあるでしょうが、その違いなんて私は気にしません。
Ed Mann
英語はこちら
And that's my problem exactly. Going to work for what? You know what I'm trying to solve.
まさにそこが悩ましいんですよね。
Scott Wlaschin
英語はこちら
Exactly. Most people, I think most people know what you're talking about when you talk about a business process or a workflow or something like that. The subtle, subtle differences between these things. Yeah. I mean, I can see why you might care, but.
ビジネスプロセスやワークフローと言えばほとんどの人に伝わります。細かな違いを気にする価値がある場合もありますが、
Ed Mann
英語はこちら
I don't Care now and again, it's context. It's like, maybe in a problem you do care about it, but in the grand scheme of things, with certain other things, it.
結局は文脈次第です。大局的には問題が解決できれば十分です。
ワークフロー志向設計
Scott Wlaschin
英語はこちら
Solves the problem and it's fine, but what I do think why? I do think it's an important concept in the design though, because I like to do kind of workflow.
とはいえ設計ではワークフロー指向を重視しています。
Scott Wlaschin
英語はこちら
Oriented design. So rather than again, it's a very different way from thinking about class oriented design. In a workflow oriented design, you pick a particular business activity, a particular workflow, and you implement it from start to finish all the way from the, you know, beginning to end. And that will give you a piece of value already. That's actually, and you can prototype it, you can show it to people, get feedback from the customers, whatever. And you don't start by building a big class or if you literally just implement one particular workflow and then when that works and then you test it and all that stuff.
志向設計です。繰り返しになりますが、これはクラス志向設計の考え方とは全く異なる方法です。ワークフロー志向設計では、特定のビジネス活動、特定のワークフローを選んで、それを最初から最後まで、始まりから終わりまで完全に実装します。それだけですでに価値の一部を提供できます。実際にプロトタイプを作って、人々に見せて、顧客からフィードバックを得ることもできます。大きなクラスを作ることから始めるのではなく、文字通り特定のワークフロー1つだけを実装し、それが動いたらテストをして、といった具合です。
Scott Wlaschin
英語はこちら
And then you move to the next piece of the next workflow and you implement that workflow. At that point, you might find, well, maybe they have something in common. We can have some reusable code between the two, whatever. And then you just keep implementing these workflows. And by the time you've implemented them all, you have your finished product. And you may find that some of them, as you implement them, you find new ones that you need to do, and some of them you might not need to do after all because they're obsolete. But I like that way you're always, each cycle of deployment or delivery, you're giving them something useful they can work with. As opposed to, again, I've seen things where people spend.
そして次のワークフローに移って、そのワークフローを実装します。その時点で、もしかしたら共通点があるかもしれません。2つの間で再利用可能なコードを持つことができるかもしれません。そしてこれらのワークフローを実装し続けていきます。すべて実装し終わる頃には、完成品ができあがります。実装していく中で、新たに必要なワークフローが見つかることもあれば、結局は時代遅れで不要になるものもあるでしょう。しかし私が気に入っているのは、デプロイメントやデリバリーの各サイクルで、常に彼らが使える有用なものを提供できることです。これとは対照的に、人々が何週間も費やすのを見たことがあります。
Scott Wlaschin
英語はこちら
Weeks designing some sort of complicated class cycle, but there's not actually anything delivered at that point. So that's so I think to me it's a very important concept when I'm doing my design is what are these workflows? What are these business processes? And then that becomes your your, your project management. That's your guide for your project management or your schedule. It's like, OK, I'm going to do this this and this and this and I can assign each one to a different person hopefully, because they're hopefully they're independent anyway. So that's just that's the way I like to do development. Yeah.
何週間もかけて複雑なクラスサイクルのようなものを設計しても、その時点では実際には何も提供されていません。だからこそ、私にとって設計をする際の非常に重要な概念は、これらのワークフローは何か？これらのビジネスプロセスは何か？ということです。そしてそれがプロジェクト管理になります。プロジェクト管理やスケジュールのガイドになるのです。つまり、OK、これとこれとこれとこれをやります、そして願わくばそれぞれを別の人に割り当てることができます。なぜなら、うまくいけばそれらは独立しているからです。これが私の好きな開発の方法です。
Ed Mann
英語はこちら
We're going to go into that a little bit where what you're doing there with Workflow is.
そのワークフローのアプローチは、私たちが解こうとしている問題に直接結びついていますね。
Ed Mann
英語はこちら
It's directly correlates to the problems that you're trying to solve. So it's not like going from, let's build this very complex class hierarchy internally that has no value or understanding to the problem that we're trying to solve just yet. It will eventually solve it, But you're directly going, no, we're going to talk about the problems the whole way through.
これは解決しようとしている問題に直接相関しています。つまり、最初から内部に非常に複雑なクラス階層を構築するのとは違います。そのようなものは、解決しようとしている問題に対して、まだ価値も理解ももたらしません。いずれは解決するでしょうが、そうではなく、直接的に進んでいきます。最初から最後までずっと問題について語り続けるのです。
Scott Wlaschin
英語はこちら
Right, right. Everything, everything you build has a direct cosponsor, something useful in reality. Yeah, absolutely.
そうです。作ったものが現実の役に立つことに直結します。
Ed Mann
英語はこちら
Which then in turn means it's very easy for you to get a very quick feedback loop on. You can talk to people and understand.
そのおかげで素早いフィードバックループが得られ、関係者とも話しやすくなります。
Ed Mann
英語はこちら
And then when people pick it up, they're reading about the business, like the business problems and the solution and the business, you know, needs exactly in code.
コードを読む人も、ビジネスの課題やニーズがそこに書かれているとすぐに理解できます。
Scott Wlaschin
英語はこちら
Exactly. And Agile has the same, Agile has the same concept with the story that you implement stories. But again, it gets kind of lost. You know, you start, it's so easy to get bogged down as just using stories to mean, you know, features and a feature is not a business work. That's why I prefer, you know, like I get the idea of a story is meant to be like a workflow or scenario, but it becomes workflow.
まさにその通りです。アジャイルも同じです。アジャイルにはストーリーを実装するという同じコンセプトがあります。しかし、また見失われがちなんです。始めてみると、ストーリーを単に機能を意味するものとして使うことに簡単に行き詰まってしまいます。そして機能はビジネスワークではありません。だから私は好むのです。ストーリーのアイデアはワークフローやシナリオのようなものであるはずだと理解していますが、それが結局ワークフローになってしまうのです。
Scott Wlaschin
英語はこちら
Is not a feature. It's not a feature only makes sense when it's used in contexts with some other stuff to get something done. And unfortunately, people start using stories to mean features. And again, it's just a hard, it's a constant battle really. But using it again, using the right words can help. I think a workflow implies that someone's actually doing something and they're not just using having a feature.
機能ではないのです。機能は、何かを成し遂げるために他のものと文脈の中で使われて初めて意味を持ちます。そして残念なことに、人々はストーリーを機能を意味するものとして使い始めてしまいます。繰り返しますが、これは難しい、本当に絶え間ない戦いです。しかし、適切な言葉を使うことは助けになります。ワークフローという言葉は、誰かが実際に何かをしているということを暗示していて、単に機能を持っている、使っているということではないと思います。
Ed Mann
英語はこちら
Yeah, and it's a beginning, middle and end.
ええ、ワークフローには始まり・中間・終わりがあります。
Ed Mann
英語はこちら
Like it's a slightly like.
小さな物語のようなものです。
Scott Wlaschin
英語はこちら
There's a workflow. I like that. Yeah, exactly. I like the word.
そう、流れがあり、静的データではなく実際に動きがあると示してくれます。
Scott Wlaschin
英語はこちら
Low because it implies it's not static and there's something actually happening.
その言葉が好きなのは、何かが動いていると感じられるからです。
コンテキスト間の通信と統合
Ed Mann
英語はこちら
Yeah, not like data, static data, there is actually something happening exactly going to be effect to it. And into finally like talking about around the DDD stuff. One thing we haven't spoke about is we talked about bounded context and that they have to communicate with each other, but we don't really know like how they communicate. So I'm just wondering like it would be very interesting for the audience to go into what, what ways can a bounded context talk?
ええ、データのような静的なものとは違って、実際に何かが起こっているのです。それが影響を与えることになります。そして最後にDDDの話題に戻りますと、まだお話ししていないことが一つあります。境界づけられたコンテキストについて話し、それらが互いにコミュニケーションを取る必要があることは述べましたが、実際にどのようにコミュニケーションを取るのかはまだ話していませんね。オーディエンスにとって、境界づけられたコンテキストがどのような方法で会話できるのかを掘り下げることは、とても興味深いと思います。
Scott Wlaschin
英語はこちら
Within each other. Well, I mean.
境界づけられたコンテキスト同士のやり取りですね。
Scott Wlaschin
英語はこちら
The simplest way is literally just through a kind of API or an interface and.
一番簡単なのはAPIやインターフェースを通じて連携することです。
Scott Wlaschin
英語はこちら
Again, you can get if you, if you depends on really how much you really want to keep them independent. If you really want to keep them independence, you actually serialise things to Jason or protobuf or something and not even pass the domain objects around because the domain objects might be different in the different subdomains or the different, you know, because they're subtly different. I mean, a good example might be a customer. You think all the customer is the same throughout the whole business, but it isn't. I mean the marketing idea of a customer and the billing department idea of a customer. They're using the same word, but.
繰り返しになりますが、これは本当にどれだけそれらを独立に保ちたいかによります。本当に独立性を保ちたいなら、実際にはJSONやProtobufなどにシリアライズして、ドメインオブジェクトすら渡さないようにします。なぜなら、ドメインオブジェクトは異なるサブドメインや異なるコンテキストでは違うものかもしれないからです。微妙に異なっているのです。つまり、良い例が顧客でしょう。ビジネス全体を通して顧客は同じだと思うかもしれませんが、そうではありません。つまり、マーケティング部門の顧客の概念と請求部門の顧客の概念。彼らは同じ言葉を使っていますが、実は違うのです。
Scott Wlaschin
英語はこちら
Different concepts, you know, billing people, it's all about money. So the customer is like what invoices they have, how much money do they owe us? Marketing people, it's all about how can I spam them? I need another e-mail and other stuff, their phone number. So they're both called customers, but they're completely different. So when you communicate a customer from one system to another system, just you shouldn't just pass the entire object over the different things. So you need a proper interface and like I say, if you really want to be good, you would serialise it to something and then maybe even put it on a queue so that if one system goes down the other.
異なる概念なのです。請求部門の人々にとっては、すべてお金に関することです。顧客とは、どんな請求書があって、いくらお金を私たちに負っているか、ということです。マーケティングの人々にとっては、どうやってメールを送るか、ということです。別のメールアドレスやその他の情報、電話番号が必要です。どちらも顧客と呼ばれますが、完全に異なるものです。だから、あるシステムから別のシステムに顧客を伝える際、単にオブジェクト全体を異なるもの間で渡すべきではありません。適切なインターフェースが必要です。私が言うように、本当に良いものにしたければ、何かにシリアライズして、さらにはキューに入れることもできます。そうすれば、一つのシステムがダウンしても、もう一つの
Scott Wlaschin
英語はこちら
Systems can keep working, so the interfaces become the boundaries. You know, there you have used documented boundaries. So how I think you can communicate between boundaries, it depends how much you want to do. Again, you can go how much overboard you want to go with it. But yeah, if you really want to make sure your system is very robust and each component can evolve separately, then yeah, you need to have a strict interface with data transfer objects and the whole thing.
システムは動き続けることができます。つまり、インターフェースが境界になるのです。そこには文書化された境界があります。境界間でどのようにコミュニケーションを取るかは、どこまでやりたいかによります。繰り返しますが、どこまで過度にやるかは自由です。しかし、システムを本当に堅牢にして、各コンポーネントが別々に進化できるようにしたいなら、データ転送オブジェクトを使った厳密なインターフェースと、そのすべてが必要です。
Ed Mann
英語はこちら
Yeah, it's outgoing in the book and start. And I think that's the thing with the bounded context and with context maps and stuff is that they provide explicit because this is the thing with communication, as you say, you've mentioned there quite rightly, it's like the interfaces and it's this agreement between parties and something again, which DDD does is puts names on these things and having the context map where it's like, you know, we mentioned in the book the anti corruption layer and you got the open host and all these things. They're clearly defining like how these relationships between communication, you know, communication patterns work.
ええ、それは本でも詳しく説明しています。そして、境界づけられたコンテキストとコンテキストマップの特徴は、それらが明示的にしてくれることです。コミュニケーションについてもあなたがおっしゃった通り、インターフェースと、関係者間の合意が重要です。そして、DDDがもたらすもう一つの価値は、これらのものに名前を付けることです。コンテキストマップを持つことで、本でも触れたアンチコラプションレイヤーやオープンホスト、その他すべてのパターンを定義できます。これらは、コミュニケーションパターンの関係がどのように機能するかを明確に定義しているのです。
Scott Wlaschin
英語はこちら
Right, so that's what so the.
その通りです。
Scott Wlaschin
英語はこちら
The idea of a context map is a map showing you all the bounded contexts and how they talk to each other. So it's, again, it's a very high level overview that allows people to kind of get the big picture. And one of the things that Eric Evans was insightful about is that there needs to be an interface between these two things. But who decides what the interface is? And that is a political problem. Like if you have two teams and I'm, you know, I need to send you data, do I get to decide what the data format is? Do you get to decide what the.
コンテキストマップのアイデアは、すべての境界づけられたコンテキストとそれらがどのように会話するかを示す地図です。繰り返しになりますが、これは人々が全体像を把握できるようにする非常に高レベルの概要です。そして、Eric Evansが洞察に富んでいた点の一つは、これら2つのものの間にはインターフェースが必要だということです。しかし、誰がインターフェースを決めるのでしょうか？これは政治的な問題です。2つのチームがあって、私があなたにデータを送る必要がある場合、データフォーマットを決めるのは私でしょうか？あなたでしょうか？
Scott Wlaschin
英語はこちら
Form is or do we collaborate and decide and ideally we would collaborate, but in the real business, that's not often how it works. Typically the team that's making money gets to decide and the everyone else has to deal with it or the team that runs the mainframe decides because they can't change the mainframe or the team with the most political power in the business. And you know, that's just that's the nature of things. But the fact there is some sort of predefined, you know, protocol or you know, way that you communicate with our teams, that is something to.
フォーマットを決めるのか、それとも協力して決めるのか。理想的には協力すべきですが、実際のビジネスではそううまくいかないことが多いです。通常は、お金を稼いでいるチームが決めて、他のみんながそれに対処しなければならない。あるいは、メインフレームを運用しているチームが決める。なぜならメインフレームは変更できないから。または、ビジネスで最も政治的な力を持つチーム。それが物事の性質です。しかし、チーム間でコミュニケーションする際の、ある種の事前定義されたプロトコルや方法があるという事実、それは何かとして
Scott Wlaschin
英語はこちら
Recognise that it's a real thing and labelling them. So they have, yeah, there's a, there's, there's various labels for these things about the consumer driven stuff versus the producer driven stuff versus the anti corruption layer. So that's the idea is that when you're working with a third party system, an API, it's very easy for that jargon to get into your code and corrupts your nice, beautiful domain model. So there's a, there's a translation layer that translates from that jargon to your jargon. It keeps them and keeps them separate. So there's a lot of there's words for these things.
認識すべきものです。それが現実のものであり、それらにラベルを付けることです。そうです、消費者駆動のものと供給者駆動のもの、アンチコラプションレイヤーなど、これらのものに対する様々なラベルがあります。つまり、アイデアとしては、サードパーティシステムやAPIと作業する際、その専門用語があなたのコードに入り込んで、あなたの美しく綺麗なドメインモデルを汚染するのは非常に簡単だということです。だから、その専門用語からあなたの専門用語への翻訳層があり、それらを分離して保つのです。これらのものに対する言葉がたくさんあるのです。
Scott Wlaschin
英語はこちら
And it's useful to have these words because then when you talk to somebody, say, yeah, we need, we have to be very careful about doing this. It just makes you conscious about.
そして、これらの言葉を持つことは有用です。なぜなら、誰かと話すときに「ええ、これをやるにはとても注意深くある必要がある」と言えるからです。それが意識させてくれるのです。
Scott Wlaschin
英語はこちら
You know what what this means.
これが何を意味するのかを知ることについて。
Ed Mann
英語はこちら
Yeah, and I think like not getting scared about people saying, oh, this is going to be have an ACL here or an open host here and a partnership here. This is the problem. It becomes very tagging. These are things that you're already doing when you're looking at systems and you're looking at problems in there. You know, things. Some things are easier than others. Like talking to another team is a harder problem than say if we have too badly context and one team owns both of them, then yeah, it's easier.
ええ、そして、人々が「ここにACLがある」「ここにオープンホストがある」「ここにパートナーシップがある」と言うことを怖がらないことが重要だと思います。これが問題です。非常にタグ付けのようになってしまいます。これらは、システムを見て、その中の問題を見ているときに、すでにやっていることなのです。物事によっては他のものより簡単です。別のチームと話すことは、例えば2つの境界づけられたコンテキストがあって、1つのチームが両方を所有している場合よりも難しい問題です。その場合は、ええ、より簡単です。
Scott Wlaschin
英語はこちら
For us to both change both of them. So then it's a partnership or something like that. Exactly. It's just, it's just sort of it is you sort of have labels for things, but the labels.
私たちが両方を変更することは。だから、それはパートナーシップか何かそのようなものになります。まさにその通りです。単に物事にラベルを持つようなものですが、ラベルは。
Scott Wlaschin
英語はこちら
The label start sort of take over, but it is useful to say this is the situation we have and this is a pretty common situation and here's a label for this situation. We call it consumer driven or producer driven or partnership or collaboration, whatever. It is useful to have these labels, but the labels are not a substitute for understanding. You know, again, sadly people get hung up on the labels and they start gatekeeping all this stuff and I don't think that's helpful.
ラベルが支配し始めてしまいます。しかし、「これが私たちが持っている状況で、これはかなり一般的な状況で、この状況に対するラベルがあります」と言うことは有用です。私たちはそれを消費者駆動、供給者駆動、パートナーシップ、コラボレーションなどと呼びます。これらのラベルを持つことは有用ですが、ラベルは理解の代わりではありません。繰り返しになりますが、悲しいことに人々はラベルにとらわれて、これらすべてについて門番のように振る舞い始めます。それは役に立たないと思います。
Scott Wlaschin
英語はこちら
Hey.
ええ。
Ed Mann
英語はこちら
That wraps up part one of our conversation with Scott Wlaschin on Domain Driven Design and functional programming. In this episode, we dug into all things domain-driven design, from what a domain and subdomain really mean to the distinction between strategic and tactical, DDD, bounded contexts, vitamin language, and the importance of communication and empathy when modelling real-world problems. Next episode, we'll switch gears and look at functional programming, why it's such a good fit for domain modelling, and how to bring the two approaches together. Thanks for listening, and be sure to check out.
これでScott Wlaschinとのドメイン駆動設計と関数型プログラミングについての会話のパート1が終了します。このエピソードでは、ドメインとサブドメインが実際に何を意味するかから、戦略的DDDと戦術的DDDの区別、境界づけられたコンテキスト、ユビキタス言語、そして現実世界の問題をモデリングする際のコミュニケーションと共感の重要性まで、ドメイン駆動設計のあらゆることを掘り下げました。次回のエピソードでは、ギアを変えて関数型プログラミングを見ていき、なぜそれがドメインモデリングにそんなに適しているのか、そして2つのアプローチをどのように結び付けるかを探ります。お聞きいただきありがとうございました。必ずチェックしてください。
Ed Mann
英語はこちら
Part 2 when it's published.
パート2も公開されたらぜひチェックしてください。
まとめ
この対談では、Scott WlaschinとEd Mannが『関数型ドメインモデリング』の核心的な概念について深く議論しました。主要なトピックは以下の通りです：
- ドメイン駆動設計の基本概念 - 技術的観点ではなく、ビジネス言語を使ったコード設計
- 戦略的DDDと戦術的DDD - 戦略（どこに向かうか）と戦術（どうやってそこに到達するか）の違い
- Core・Supporting・Genericサブドメイン - ビジネス価値に基づく優先順位付け
- 境界づけられたコンテキスト - ソフトウェアにおける明確な境界の重要性
- ユビキタス言語 - 開発者とドメインエキスパート間の共通言語
- ガベージイン・ガベージアウト - 良い入力なしには良い出力は得られない
- 共有メンタルモデル - チーム全体での概念の統一
- ドメインエキスパートとの協働 - 聞くことの重要性と技術者の謙虚さ
この対談は、技術的な詳細よりも、人間とのコミュニケーション、ビジネスの理解、そして実用的な問題解決に焦点を当てた貴重な洞察を提供しています。
ポッドキャストパート2も公開予定なので、お待ちください。
これで Compiled Conversation #8 の一連の翻訳記事は終わりです！
ポッドキャスト、よろしければ英語ですがわかりやすい英語ですので聞いてみるのがお勧めです！
ホストのEddさん と ゲストのScottさんのXにも最新情報が載せられていますので、ぜひご覧ください。
(2)-1 はこちら
(2)-2 はこちら
(2)-3 はこちら
Discussion