最近聞いたポッドキャスト、 Compiled Conversation #8, #9 がドメイン駆動設計の入門としてすごくよかったので、英語で文字起こしして、和訳をしました。参加者のお二人に和訳をブログに載せる許可をいただきました。LLMによる機械翻訳ベースなので、細かな表現が意訳されていたり、また文字起こしの間違いにより一部おかしな内容になっているかもしれません。ぜひ英語でわかる方は本編を英語で聞かれることをお勧めしますが、日本語の和訳だけでもニュアンスが十分伝わるので、よろしければご覧ください。
Domain Modeling Made Functional Part 2 with Scott Wlaschin
(1)-1はこちら
(1)-2 はこちら
(1)-3 はこちら
(2)-1 はこちら
(2)-2 はこちら
podcastのリンクはこちらです。
登場人物
- Ed Mann（ホスト）: ポッドキャストの司会者
- Scott Wlaschin（ゲスト）: 『関数型ドメインモデリング』著者、F# for Fun and Profit ブログ執筆者
関数型プログラミングとDDDの組み合わせ
Ed Mann
英語はこちら
Yeah, absolutely, indeed. And so moving on then, so combining these two worlds now, so.
はい、絶対にそうです。では次に進みましょう。これら2つの世界を組み合わせて、
Ed Mann
英語はこちら
How does then a functional programming language like F# help with modelling these domain concepts?
F#のような関数型プログラミング言語は、これらのドメイン概念のモデリングにどのように役立ちますか？
Scott Wlaschin
英語はこちら
Right. The main thing is, well, there's two things. First of all, these composable data types that you can just glue them together and you can and or them together. Now that's only possible because the data types do not have any behaviour. They're just literally data structures. And in oh, oh, it's hard to, it's harder to compose things in oh, oh because you have the data, plus you have the behaviour that goes with the data and they're all encapsulated into one single object.
そうです。主なことは2つあります。まず第一に、これらの組み合わせ可能なデータ型を接着し、andやorで組み合わせることができます。これはデータ型に振る舞いがないからこそ可能です。文字通りデータ構造だけです。OOでは、データに加えて、データに付随する振る舞いがあり、すべてが1つのオブジェクトにカプセル化されているため、物事を組み合わせるのが難しいです。
Scott Wlaschin
英語はこちら
And that's by design. That's the whole, the whole point of oh, oh is you have this encapsulated object that you can't see inside. So in functional programme, the idea is that the data is transparent and because it's immutable, that's not normally a problem. The fact that I can see what the data fields are is fine because I can't change them. So you.
それは設計によるものです。OOの全体のポイントは、内部を見ることができないカプセル化されたオブジェクトを持つことです。関数型プログラミングでは、データは透明であり、不変であるため、通常は問題ありません。データフィールドが何であるかを見ることができるという事実は、それらを変更できないので問題ありません。
Ed Mann
英語はこちら
Have transferly typed.
透過的に型付けされています。
Scott Wlaschin
英語はこちら
Exactly, exactly. And it's strictly typed, so I have these composable data types, the algebraic data types. So that's one plus about it. And then the second thing which I like about functional programming.
その通りです。厳密に型付けされているので、これらの組み合わせ可能なデータ型、代数的データ型があります。それが1つの利点です。関数型プログラミングについて好きな2番目のことは、
パイプライン指向プログラミング
Scott Wlaschin
英語はこちら
Is I also call pipeline oriented programming, which is the idea that you, the data goes through this workflow one step at a time. It comes in one end and it goes through a series of little pipes and it comes out the other and transformed into something else. Now, this is not a new concept because Unix, you know, the Unix shell script works exactly the same way. You take something, you pipe it into something, you pipe it something else and it comes out the other end. And combining lots of small pieces and piping the data between them is, you know, like I say, that's one of the reasons why Unix, the Unix.
パイプライン指向プログラミングとも呼んでいます。データがこのワークフローを1ステップずつ通過するというアイデアです。一端から入り、一連の小さなパイプを通り、他端から別のものに変換されて出てきます。これは新しい概念ではありません。Unixシェルスクリプトは全く同じように動作します。何かを取り、何かにパイプし、別の何かにパイプし、他端から出てきます。多くの小さな部品を組み合わせ、それらの間でデータをパイプすることは、Unixの理由の1つです。
Scott Wlaschin
英語はこちら
Unix shell is so good because that's exactly how you do stuff. You learn all these little individual pieces and then you connect them together.
Unixシェルが非常に優れているのは、まさにそのように物事を行うからです。これらすべての小さな個々の部品を学び、それらを接続します。
Scott Wlaschin
英語はこちら
Now functional programming has exactly the same idea. You take all these little pieces and you connect them together. And that is a lot easier to understand. And I think than 00 in the sense that you have A1 directional pipeline and the data comes in and goes out the other end and it flows through the pipeline. And I actually think that's a, that's a nicer model for how business processes work in general. With the OO design, you typically have an object that talks another object that talks another object that talks the third, then they then they all talk back and forth and it can very easily.
関数型プログラミングは全く同じアイデアを持っています。これらすべての小さな部品を取り、それらを接続します。それははるかに理解しやすいです。1方向のパイプラインがあり、データが入って他端から出て、パイプラインを流れます。実際、これは一般的にビジネスプロセスがどのように機能するかについてのより良いモデルだと思います。OO設計では、通常、あるオブジェクトが別のオブジェクトと話し、それが別のオブジェクトと話し、3番目と話し、それらはすべて前後に話し合い、非常に簡単に、
Scott Wlaschin
英語はこちら
Get to the point where you don't understand who's talking to who and you get lost because it's not, it's not a one directional process. You can, you get, sometimes you get loops and and and and cycles and stuff. So it's nice indeed a nice idea in theory, but in practise, um.
誰が誰と話しているかわからなくなり、迷子になります。1方向のプロセスではないからです。ループやサイクルなどができることがあります。理論的には良いアイデアですが、実際には、
Scott Wlaschin
英語はこちら
Again, it's one of the things about OO is it's very easy to get too complicated in OWO. It's the, there's all these rules like, well, don't do that. You know, the, all the things like the single responsibility principles that don't do too many things and the, and the interface segregation principle. And you know, all these things that I don't do that rather than saying don't do that, just like don't allow it happen in the 1st place. So if you have functions, functions do one thing. You don't have to have a single responsibility principle for a function because it.
OOのことの1つは、OOで複雑になりすぎるのが非常に簡単だということです。「それをしないでください」というようなルールがたくさんあります。単一責任原則や、インターフェース分離原則など。「それをしないでください」と言うのではなく、最初からそれを許可しないでください。関数があれば、関数は1つのことをします。関数に単一責任原則は必要ありません。
Scott Wlaschin
英語はこちら
A single responsibility so you don't even need. There's no such thing as solid in functional programming because it is solid. Yeah, I mean, I think solid actually applies really well. You know you it can only there's no interfaces so you don't have to segregate, you know all.
単一責任なので必要ありません。関数型プログラミングにはSOLIDというものはありません。それがSOLIDだからです。SOLIDは実際に非常によく適用されます。インターフェースがないので分離する必要がありません。
Ed Mann
英語はこちら
These big classes god classes.
これらの大きなクラスが、
Scott Wlaschin
英語はこちら
Classes for so many different functions. Exactly. Yeah. So you do have these and and, you know, in in programming we always say, well, you should really build these modular components and and connect them to compose them together.
多くの異なる関数のためのクラス。その通りです。プログラミングでは、モジュラーコンポーネントを構築し、それらを接続して一緒に構成すべきだと常に言います。
Scott Wlaschin
英語はこちら
And we want modularity, we want reusable code, all that stuff.
モジュラリティが欲しい、再利用可能なコードが欲しい、すべて。
Scott Wlaschin
英語はこちら
Well, you get that with functions. Each function does one thing well and you glue them together to make your complete workflow. And so you kind of all the things you're kind of striving for in good design, you're kind of a lot of it you get for free with functional programming, which is so I think from for business, you know, again, so nothing to do with the kind of academic idea of functional programming, but just for pragmatic business workflows where you have data coming in and data going out, functional programming really works well for that I think much.
関数でそれを得ます。各関数は1つのことをうまく行い、それらを接着して完全なワークフローを作ります。良い設計で努力しているすべてのことの多くを、関数型プログラミングで無料で得られます。ビジネスのために、アカデミックな関数型プログラミングのアイデアとは関係なく、データが入ってきてデータが出ていく実用的なビジネスワークフローには、関数型プログラミングが本当によく機能すると思います。
Scott Wlaschin
英語はこちら
Better than object programme so.
オブジェクトプログラミングよりも良いです。
Ed Mann
英語はこちら
And in the book I mean you model out a workflow and it's.
本では、ワークフローをモデル化し、
Ed Mann
英語はこちら
How beautiful I I love the pipeline or interesting stuff because you see this beautiful and it's so cleanly shows that the process that's going on in that workflow from input to output and in between. And then you can compose it. You can clearly see how you can add your ability. And that's something I like about like the last section of your book where you go into change. Yeah, because undoubtedly there's going to be change and you can clearly see how you would do that and.
美しいです。パイプラインや興味深いものが大好きです。入力から出力まで、そしてその間のワークフローで進行しているプロセスを非常にきれいに示しているからです。それを構成できます。能力を追加する方法を明確に見ることができます。あなたの本の最後のセクションで変更について触れているのが好きです。間違いなく変更があり、それをどのように行うかを明確に見ることができます。
Scott Wlaschin
英語はこちら
It's so clear and explicit. Yeah. So if you have a pipeline and each step is labelled like, do this, then do this, then it's just how people normally think about it, right? Do this, then do this.
とても明確で明示的です。パイプラインがあり、各ステップが「これをする、次にこれをする」とラベル付けされている場合、それは人々が通常考える方法ですよね？これをして、次にこれをする。
Scott Wlaschin
英語はこちら
I said Passover, him and him do this. Each of those would be a little step in the pipeline. If you need to change the pipeline, you just add the step, add a new step or remove a step or change a step in the pipeline. And it's like really kind of obvious how to do it. And you're not going to be frightened. And again, because the statically typed compiler is going to make sure you get everything lined up properly. So you can, you have a lot of freedom to like replace things in the pipeline and still be confident that the whole thing is going to work properly. Which again, if I was doing an oh, oh thing, I'm not always so confident about that.
私は過越祭のことを言いましたが、彼と彼にこれをやらせると言いました。それぞれがパイプラインの小さなステップになります。パイプラインを変更する必要がある場合は、ステップを追加するか、新しいステップを追加するか、ステップを削除するか、パイプラインでステップを変更するだけです。そして、それをどう行うかは本当に明らかです。そして、あなたは恐れることはありません。そして再び、静的型付きコンパイラがすべてを適切に整列させることを確実にしてくれるからです。つまり、パイプラインで物事を置き換える自由がたくさんあり、それでも全体が適切に動作することを確信できます。これも、もし私がオブジェクト指向をやっているなら、いつもそう確信しているわけではありません。
Ed Mann
英語はこちら
And something you said in the book was around like, can you replace your documentation with just types? And I think something you did really well in the book was able to kind of go through how we're going to model our domain. And then you're able to actually put that into types within F# in this case. So I'm just wondering like for you, can, you know, have you successfully in your projects, do you have much documentation around this or if it is all just encoded in the?
そして、あなたが本で言ったことの一つが、型だけでドキュメンテーションを置き換えることができるかということでした。そして、本で本当によくやったことの一つは、ドメインをどうモデル化するかを通じて進めることでした。そして、実際にそれをこの場合のF#内で型に落とし込むことができました。だから私はただ疑問に思っているのですが、あなたにとって、あなたのプロジェクトで成功したことはありますか、これについてのドキュメンテーションがたくさんあるのか、それとも全てが単に次のものにエンコードされているのでしょうか？
Scott Wlaschin
英語はこちら
Types. Well, you can't encode everything in the types. Again, you can't. You can go overboard and try and be too clever, but I like to try and do.
型です。まあ、すべてを型にエンコードすることはできません。再び、できません。やりすぎて賢すぎようとすることもできますが、私は試してやるのが好きです。
Scott Wlaschin
英語はこちら
Just get the main concepts in the like again, if I'm doing, let's say I'm modelling a game of poker or card game, the concept of the card and the concept of the suits and the all that stuff, I can model that in the types. The rules of poker I can't model. You know, that's just too complicated. So knowing what you can do and what you can't do and making sure you don't go overboard again, that's just, that's a question of experience. But it can do a lot more than you think, a lot more than you, you know, you'd be surprised how much you can do and still keep it nice.
主要な概念だけを入れます。再び、もし私がポーカーやカードゲームのゲームをモデリングしているとしましょう。カードの概念とスーツの概念とそれらすべてのものを型でモデル化できます。ポーカーのルールはモデル化できません。それは複雑すぎます。だから、あなたが何ができて何ができないかを知り、やりすぎないようにすることが重要です。再び、それは経験の問題です。しかし、あなたが思っているよりもはるかに多くのことができます。あなたがどれだけできるかに驚くでしょうし、それでもきれいに保つことができます。
Scott Wlaschin
英語はこちら
ID and yeah, I mean my book. I have a couple of examples where you can actually make code easy to understand and less error prone by remodelling it using types and getting rid of booleans and getting rid of flags and stuff. And you can use types choices and it makes it more documenting and also, you know, more less likely to have bugs and more easy to use as.
そして、はい、私の本では、型を使ってコードを理解しやすく、エラーが起こりにくくすることができる例がいくつかあります。それは、ブール値やフラグなどを取り除いて再モデリングすることによってです。そして型の選択肢を使うことができ、それはより文書化されたものになり、また、バグが起こりにくく、使いやすいものになります。
Ed Mann
英語はこちら
Well, you know, I think a bit of a side there. You know, this is the thing with the type systems. I know there was like going around a couple of years ago a TypeScript and how someone did I think they run.
まあ、ちょっと脇道にそれますが。型システムについて、2、3年前に流行っていたTypeScriptのことを知っています。誰かがやったと思います。
Ed Mann
英語はこちら
People have modelled in type systems ridiculous things and obviously this is the trouble. You can push the envelope. I like what you're saying there. It's like doing just enough, like you don't need to be. Let's not, you know, we have a tool. Let's not try and exploit this tool. We can use it to a good point that allows us to get as much value.
人々が型システムでばかげたものをモデル化したことがあり、明らかにこれが問題です。限界を押し広げることができます。あなたがそこで言っていることが好きです。十分にやるということです。つまり、する必要がありません。このツールを悪用しようとしないでください。良いポイントまで使用して、できるだけ多くの価値を得ることができます。
Scott Wlaschin
英語はこちら
While still making it coherent and understandable. Exactly. There's a trade off just like anything. You make it too complicated. But I think the trade off is much at a different point than it is for OO and certainly for C or something. You know, it's like at some point there's.
それでも一貫性があり理解しやすくしながら。その通りです。何でもそうですが、トレードオフがあります。複雑すぎるものにしてしまいます。しかし、そのトレードオフはオブジェクト指向や確実にCなどとは異なる点にあると思います。ある時点で限界があります。
Scott Wlaschin
英語はこちら
Like it gets too complicated, and for a pragmatic language like F# you can do an awful lot with the types and still have it. Really.
複雑になりすぎるような点があり、F#のような実用的な言語では、型でかなりのことができて、それでも本当に保つことができます。
Scott Wlaschin
英語はこちら
Easy to understand and so I think going into some of the more DDD concepts here like you know, things such as entities and value objects like. How are these modelled then in a?
理解しやすくするために、そして、より多くのDDD概念に入っていこうと思います。エンティティや値オブジェクトのようなものについて。これらは関数型プログラミング言語でどのようにモデル化されるのでしょうか？
Scott Wlaschin
英語はこちら
Function programming language, yeah. So a lot of the concepts in DVD are some kind of OO concepts. But the idea of something, an entity, is something which has an identity that does not change as the object change, as the parts of the object change, like.
はい。DDDの多くの概念は、ある種のオブジェクト指向の概念です。しかし、エンティティという何かのアイデアは、オブジェクトの部分が変化してもアイデンティティが変わらないものです。
Scott Wlaschin
英語はこちら
Customer, you know, you might change your name, you might change your address and your e-mail. You're still the same person, right? The same customer. So, you know, typically you'd have an ID, you have a customer ID that that is, that carries on as all the other things change. So in, in functional programming, you just have a custom ID fields that carries on. Every time you change it, you keep the custom ID field around. So in that sense, it's exactly the same. And in the DDD, there's a value object. Now a value object is something that if you change any part of it, it's different.
顧客のように、名前を変更したり、住所や電子メールを変更したりするかもしれません。それでもあなたは同じ人、同じ顧客です。だから、通常顧客IDがあって、他のすべてが変わってもそれが続きます。だから、関数型プログラミングでは、続くカスタムIDフィールドを持っているだけです。変更するたびに、カスタムIDフィールドを保持します。だから、その意味では、全く同じです。そしてDDDには値オブジェクトがあります。値オブジェクトは、その一部を変更すると、それが異なるものです。
Scott Wlaschin
英語はこちら
So if you have an address and you change, you know, your house number, that's a different address. You know, if you change your e-mail, that's a different e-mail. It's not the same e-mail anymore because it's different. So those are important concept in domain driven design. And it's like you get that naturally if you have a mutable data structures in a functional language, if you change any part of it's a different object as its structural quality is exactly, so you don't have to worry about it. So you get a lot of these things kind of naturally for free.
だから住所があって、家番号を変更すると、それは異なる住所です。電子メールを変更すると、それは異なる電子メールです。異なるので、もはや同じ電子メールではありません。これらはドメイン駆動設計の重要な概念です。そして、関数型言語で不変なデータ構造を持っていれば、自然にそれを得ることができます。その一部を変更すると、それは構造的品質が全く異なるオブジェクトです。だから、これらの多くのものを自然に無料で手に入れることができます。
Scott Wlaschin
英語はこちら
But yeah, the the concepts are still valuable.
しかし、はい、概念は依然として価値があります。
Scott Wlaschin
英語はこちら
Concepts to think about in when you're doing modelling, the fact that some objects, if you change, they kind of still say the same even if you change them, but other ones, if you change them, they're completely different. So that's a useful distinction to know about that in terms of actually from an implementation point of view, both the implementations are completely trivial in functional programming.
モデリングを行う際に考える概念です。一部のオブジェクトは、変更しても、変更してもまだ同じと言えるが、他のものは、変更すると完全に異なるものになるという事実です。だから、それは知っておくべき有用な区別です。実装の観点から言えば、両方の実装は関数型プログラミングでは完全に些細なことです。
Ed Mann
英語はこちら
Absolutely. And then like aggregates as well, then how would we?
もちろんです。そして集約についても、どうやってモデル化するのでしょうか？
Scott Wlaschin
英語はこちら
Model those, yeah. So in aggregate in.
モデル化しますね。ドメイン駆動設計における集約は。
Scott Wlaschin
英語はこちら
Domain term design is an object that has especially a bunch of entities.
特に多くのエンティティを持つオブジェクトです。
Scott Wlaschin
英語はこちら
Grouped together as a single thing, and there might be a classic example is an order. So you have an order and it contains a bunch of order lines. So each of the order lines might be things, but they the whole thing itself is a bunch of stuff and they normally are constraints or invariants. So if I change the price of one of the items, the total price of the order also changes. Or you know, if I change the quantity of one of the items that changes the whole thing is right. Just changing one of the parts also changes the whole thing. So you need to make sure that you only work at the top level.
一つのものとしてグループ化され、典型的な例は注文です。注文があり、それは多くの注文行を含みます。だから、注文行のそれぞれは物かもしれませんが、全体自体が多くのものの束であり、通常は制約や不変条件があります。アイテムの一つの価格を変更すると、注文の総価格も変わります。または、アイテムの一つの数量を変更すると、全体が変わります。一つの部分を変更すると全体も変わります。だから、トップレベルでのみ作業することを確実にする必要があります。
Scott Wlaschin
英語はこちら
And again, that's pretty easy to do in functional programming. You just always pass the top level thing in and you know, whenever you make a change. So it rather than having behaviour, rather than having encapsulated mutable states, which is protected by methods, which is the oh, oh way you can, you just have a function which changes the quantity of an item. But in order to do that, you have to pass the entire order. And because it also changes the total order price as well. So it's not, it's not, it's not that different. And ironically, immutability makes it even more obvious that you have to do that because.
そして再び、それは関数型プログラミングでは非常に簡単に行えます。常にトップレベルのものを渡すだけで、変更を加えるたびに行います。だから、振る舞いを持つのではなく、メソッドによって保護されたカプセル化された可変状態を持つのではなく、それがオブジェクト指向のやり方ですが、アイテムの数量を変更する関数を持つことができます。しかし、それを行うには、注文全体を渡さなければなりません。そして、それは注文の総価格も変更するからです。だから、それほど違いはありません。そして皮肉にも、不変性はそれをより明らかにします。
Scott Wlaschin
英語はこちら
Yeah, I can't change. I can't change one of the small pieces about changing the whole thing as.
はい、変更できません。全体を変更せずに小さな部分の一つを変更することはできません。
Ed Mann
英語はこちら
Well, anyways, not today. And then finally around those kind of concepts is the repository pattern right? Is it even applicable?
まあ、とにかく、今日深掘りすることではありません。そして最終的に、そのような概念の周りはリポジトリパターンですよね？それは適用できるのでしょうか？
Scott Wlaschin
英語はこちら
Yeah, exactly. So the repository pattern in oh, oh, domain of design, the idea is how do I talk to the database? And as we said, we don't really want to. You want to really know how you talk to the database that's not part of the domain model. So the idea is you have a an object which represents a collection.
はい、その通りです。オブジェクト指向のドメイン設計におけるリポジトリパターン、そのアイデアはデータベースとどう話すかです。そして、私たちが言ったように、実際にはデータベースとどう話すかを知りたくありません。それはドメインモデルの一部ではありません。だから、アイデアは、コレクションを表すオブジェクトを持つことです。
Scott Wlaschin
英語はこちら
Of things.
物の。
Scott Wlaschin
英語はこちら
And you add to that collection or you look in that collection, or you remove something and that is then converted into database operations. So look, you know, searching in that collection, it becomes a query in the database and adding something that collection becomes inserting.
そして、そのコレクションに追加したり、そのコレクションを検索したり、何かを削除したりして、それがデータベース操作に変換されます。見てください、そのコレクションを検索することは、データベースでのクエリになり、そのコレクションに何かを追加することは挿入になります。
Ed Mann
英語はこちら
In the database the formula like the.
データベースでの式のように。
Scott Wlaschin
英語はこちら
Persistence equivalence, yeah. So it's basically exactly, it's an interface, it's a way of modelling a database without actually caring about the database. Now as I said in in functional programming we really don't like to have non deterministic code, so we don't really want to be.
永続化の等価性、はい。だから、基本的には、その通りです。インターフェースであり、実際にデータベースを気にしないでデータベースをモデリングする方法です。関数型プログラミングでは、非決定的なコードを持つことを本当に好まないと言いました。だから、コアコードでデータベースをいじりたくありません。
Scott Wlaschin
英語はこちら
Messing with the database in the core code. So what we might do is just keep track of all the objects that we're going to need to add to the database in a structure. And then when we've finished our workflow, we add them to the database directly using direct SQL. Even not even having a norm, just literally writing a piece of SQL that adds them to the database. So you don't need an ORM, you don't need a repository, you just keep track of what you need to do Now this is easy and if that's one of the things where this whole workflow thing happens because you only.
だから、データベースに追加する必要があるすべてのオブジェクトを構造で追跡するだけかもしれません。そして、ワークフローを終えたら、直接SQLを使ってデータベースに直接追加します。ORMすら必要なく、文字通りデータベースに追加するSQLの一部を書くだけです。だから、ORMも必要なく、リポジトリも必要なく、何をする必要があるかを追跡するだけです。これは簡単で、このワークフローという全体が起こる理由の一つです。
Scott Wlaschin
英語はこちら
To do the very minimal things you need to do for this particular workflow, you don't need to have an interface that represents the 10s of thousands of things you might want to do with the database. If I have a workflow that changes my e-mail address, that's it. That's the only thing I do is need to update my e-mail address. I don't need to do anything else in the database. I don't need a special repository interface that has changed e-mail address as one of the methods on it. And if I want to change my password, that's a different workflow. And so that workflow just changes the password. It doesn't need to change the e-mail address. So you don't need to have.
この特定のワークフローに必要な最小限のことだけを行うからです。データベースで行いたい数万のことを表すインターフェースを持つ必要がありません。電子メールアドレスを変更するワークフローがある場合、それだけです。それが私がする唯一のことは、電子メールアドレスを更新することです。データベースで他に何もする必要がありません。電子メールアドレスを変更するメソッドの一つとして持つ特別なリポジトリインターフェースは必要ありません。パスワードを変更したい場合、それは別のワークフローです。だから、そのワークフローはパスワードを変更するだけです。電子メールアドレスを変更する必要はありません。だから、持つ必要がありません。
Scott Wlaschin
英語はこちら
An interface with thousands of different methods on it to handle all the possible things you might want to do. A lot of these problems kind of go away by working in a workflow oriented way. A lot of the O issues kind of go away. You don't have an interface like I say, you don't have these massive interfaces or these massive kind of God objects. You just each workflow is independent and does one thing.
行いたいすべての可能なことを処理するために数千の異なるメソッドを持つインターフェース。これらの問題の多くは、ワークフロー指向の方法で作業することによって消えていきます。オブジェクト指向の問題の多くが消えていきます。私が言うように、これらの巨大なインターフェースや巨大な神オブジェクトのようなものを持つ必要がありません。各ワークフローは独立しており、一つのことを行います。
Ed Mann
英語はこちら
Yeah. And so we're going with that workflow thing. So in the book and so you mentioned like you commands come as input and an output is typically events. But also you kind of mentioned there is like almost like.
はい。そして、そのワークフローのことに進みますが、本でも言及されているように、コマンドが入力として来て、出力は通常イベントです。しかし、あなたはまた、ほとんど次のようなものがあると言いました。
Ed Mann
英語はこちら
Actions that you have to do? Is it always only events that then in turn then will produce side effects or?
しなければならないアクション？それは常にイベントだけで、それが今度は副作用を生み出すのですか、それとも？
Scott Wlaschin
英語はこちら
Are they? It depends. Again, it depends on how strict you want. But typically if you want to communicate to, let's say I've just taken an order in my. If you're doing an e-commerce system, I click a button on the front end and it creates an order object and it sends it to the back end and it saves it in the database. And then that might trigger an event to the fulfilment side saying, OK, this object, this order needs to be fulfilled and send it off to the thing. And it might also send an.
そうとは限りません。どれだけ厳密にしたいかによります。例えばECサイトでフロントエンドのボタンをクリックすると注文オブジェクトが作られ、バックエンドに送られてデータベースに保存されます。その結果としてフルフィルメント側に『この注文を処理して配送して』というイベントを投げるかもしれませんし、
Scott Wlaschin
英語はこちら
To the billing side saying this person need to take money out of their credit card or whatever. So how do you communicate to those other subsystems or other domains? And you could literally just call an API, but then if the billing system is down or the filament system is down, then the order never gets saved and you have the error handling right how you're going to handle it. So it's easy just to save the order and then make an event which gets put on a queue to say so the other system can handle.
請求部門に『この人のクレジットカードからお金を引き落として』というイベントを送るかもしれません。では、そのほかのサブシステムや別ドメインにどう伝えるか。単純にAPIを叩くこともできますが、請求システムやフルフィルメントシステムがダウンしていたら注文自体が保存されず、エラーハンドリングをどうするかという問題になります。そこで、まず注文を保存し、キューにイベントを積んでおけば、相手のシステムがあとで処理できます。
Scott Wlaschin
英語はこちら
At the leisure and they can say, OK, we just got a whole bunch of messages saying.
自分たちの都合の良いタイミングで『大量のメッセージが来たぞ』と受け取って。
Scott Wlaschin
英語はこちら
Saying we need to fulfil this thing and we had on our own, right? So this is where you get these decoupling between the two different domains. And so each workflow typically has its own internal bit that it stores. But then if it wants to communicate to other people, it uses events to do that. So the sorry.
『この注文を処理しなきゃいけない』と自分たちの責務として動けます。こうしてドメイン同士を疎結合にできるのです。各ワークフローは自分の内部状態を保持しますが、他者とやり取りしたいときにはイベントを使う、というわけです。
Ed Mann
英語はこちら
In that case, then so with this, if we're looking at like a functional core and keeping everything pure, if I'm returning back, I would return say I do need to save that user now or I need to do some persistent. I've done this work and I say, right, you need to save.
そうなると、関数型コアをきれいに保ちたいときに、ワークフローの戻り値として『このユーザーを保存する必要がある』『永続化が必要だ』と指示を返す感じでしょうか。
Ed Mann
英語はこちら
This user and then send this event or something exactly.
このユーザーを保存し、このイベントも送る、といった具合に。
Scott Wlaschin
英語はこちら
Exactly. So I'd save the user, I'd save the order and then I'd also put an event on the event queue saying, OK, now you need to take the money out of the credit card or whatever. If you write code up this way, it's super easy to test because it's like if I want to test my workflow, I, you know, I say, well, if you, if you buy this thing, you should be charged, you know, this much money. I put that as the input into my workflow and the output should be an event saying take 10 lbs out of this person's credit card. And I, you know, I don't actually have to do it. I just.
その通りです。ユーザーや注文を保存したうえで、イベントキューに『このクレジットカードから代金を引き落として』と載せておくのです。こうしてコードを書くとテストがとても楽になります。たとえば『この商品を購入したらこの金額を請求する』と想定したとき、その入力をワークフローに渡せば、出力として『この人のカードから10ポンド引き落とせ』というイベントが返るはずだ、と検証できます。実際に決済を走らせる必要はなく、
Scott Wlaschin
英語はこちら
But the inputs and the outputs, that's, you know, I test the entire workflow very easily. So that's another reason, that's another reason why I like the kind of pipeline approach or the workflow approach is the testing is easier. Sometimes it gets very hard to test OO systems because again, you have to mock things. And if you don't have any mocking and you have inputs and outputs, the testing process becomes very easy.
入力と出力だけをテストすればワークフロー全体を簡単に確認できるわけです。これが私がパイプライン的なアプローチやワークフローアプローチを好む理由の一つです。テストが容易になるからです。オブジェクト指向のシステムはモックが大量に必要になりがちですが、モックに頼らず入力と出力だけで済めばテストは驚くほど楽になります。
Ed Mann
英語はこちら
And I guess because you mentioned something in the book as well, the saga pattern and things like that, like I guess if you're breaking up processes, like if I save this, then I want to make sure that these things are saved as well. Like it's dependence on stuff and if things go wrong.
本にもサガパターンなどが出てきますが、プロセスを区切ったとき、『これを保存したら、これらも保存できたか確認したい』といった依存関係や障害時の扱いはどうすればよいでしょう。
Scott Wlaschin
英語はこちら
How do we? Yeah, it can get complicated. So I mean, Saga pattern is really a very long running workflow. And So what you have to do is you have to store your current state of what you're doing. And then you maybe you call out some third party to do the billing, you know, take the money out and then they will send you back something. And it's like depending on what they send you back, you may have to like change to a different state. So OK, your credit card was declined. OK, so that means I have to change the order back to now. I had to change it into the state where it's pending and I have to send an e-mail message to your customer saying please update all this stuff.
そこは確かに複雑になります。サガパターンは要するに長時間にわたるワークフローです。いま自分がどの段階にいるのかを保存しておく必要がありますし、外部の課金サービスに呼び出しを投げて戻り値を受け取り、それに応じて状態を変える必要が出てきます。例えばクレジットカードが拒否されたとしたら、注文を『保留中』の状態に戻して、お客様に『情報を更新してください』とメールを送らなければならないかもしれません。
Scott Wlaschin
英語はこちら
So you can get very complicated, but each piece is quite simple. But yeah, you need to have some sort of persistence between. You do need to have some sort of persistence to keep track of where you are in the in the overall workflow if it's a very long running workflow with lots of dependencies.
長時間動作し依存関係が多いワークフローでは、どこまで進んでいるのかを追跡する永続化が必要になりますが、各ステップ自体は意外とシンプルです。
Ed Mann
英語はこちら
On on third parties, because there's also I guess like saying, look at this functional Quora again. It's like, so I've done this work and I've decided at the end, yeah, you're going to save this user. What happens if it fails?
また、関数型コアに話を戻すと、ワークを終えて『このユーザーを保存するべきだ』と決めたのに、実際の保存が失敗したらどうなりますか。
Ed Mann
英語はこちら
To.
つまり、保存しようとして。
Scott Wlaschin
英語はこちら
Save that user like afterwards, right? Oh exactly. I mean one thing. So it depends if you if it's a, if it's a.
そうですね。失敗するケースがどういうものかによります。
Scott Wlaschin
英語はこちら
If your workflow succeeds but some of the some of the secondary workflows fail, like I can't take the money out of your credit card.
ワークフロー自体は成功したけれど、後続の処理でカードからお金を引き落とせなかった、といったケースです。
Scott Wlaschin
英語はこちら
Then yeah, then there needs to be another event coming, say OK, you need to, you need to cancel this order or you need to do something. Now if you. And funny enough, this is not a new OK, so this is not a new concept. Before they had computers, this was a problem when in the old days, if I cashed a cheque, the check would literally be physically delivered to the central to my bank and then they would take it out of my.
その場合は『この注文をキャンセルする必要がある』『別の対応を取るべきだ』というイベントを再度発行する必要があります。面白いことに、これは昔からある問題です。新しく出てきた話ではありません。
Scott Wlaschin
英語はこちら
Playing in the notes, send the cheque back, you know, it take that's why it would take days to post, you know, weeks to process a cheque. And you know, they already have those processes of this they already thought about. And the classic the the one that accountants use and that banks use is what's called a compensating transaction where they give me the money and then, you know, a week later they find out that I actually don't have the money and then they bill me for the money. They take the money back out again.
手形を戻したり小切手を返送したりといった対応が必要で、だからこそ処理に何日も、時には数週間もかかったわけです。会計士や銀行がよく使う対処法に補償取引というものがあります。まずこちらにお金を渡し、後になって資金が無いとわかれば、請求し直して差し引くのです。
Scott Wlaschin
英語はこちら
So you don't try and you can't. You can't always as a computer person, think we need to solve all the problems right now. It's like in the.
ですから、私たちコンピュータの人間が『今すぐすべての問題を解決しなければ』と考える必要はありません。
Scott Wlaschin
英語はこちら
Real world, a lot of things take days or weeks to solve and so you need to design your systems that you know.
現実世界では、多くのことが解決までに何日も、時には数週間もかかります。その前提でシステムを設計しなければなりません。
Scott Wlaschin
英語はこちら
You have. You can't undo things that you can't always undo. You can't put something in a two phase commit, you know, because.
すべてを元に戻せるとは限らない。常にツーフェーズコミットで処理できるわけでもないのです。
Scott Wlaschin
英語はこちら
You know, you just can't. It's just not how the wheel works. There's a famous article called Starbucks does not use two phase commit, which is exactly about this. Like if you if they make a cup of coffee and you don't pay for it, you know, they don't wait, they don't take the money out at exactly the same time that you pick up your cup of coffee. They might just accept the loss. They might just say, OK, you know, you, you've stolen a cup of coffee, it's not worth doing it. Or they might ban you from the store or they might do it's just various things they can do that are not involved in the technology of A2 phase commit. And you know, so have a look.
世界はそう動いていません。有名な記事に『スターバックスはツーフェーズコミットを使わない』というものがあります。まさにこの話です。コーヒーを作っても、お客さんが代金を払わなかったらどうするか。受け渡しと同時に必ず課金するわけではなく、場合によっては損失として諦めたり、その客を出入り禁止にしたりします。ツーフェーズコミットという技術に頼らない解決策はいくらでもあるんです。
Scott Wlaschin
英語はこちら
How people used to do this before computers that's you know, you can learn you.
コンピュータ登場以前に人々がどう対処していたかを見れば、大いに学べます。
Ed Mann
英語はこちら
Can learn. Yeah, so true. And I think that's the thing with it. It's as developers things have to be correct or consistency, as you say, it has to happen. The real world is not like that, as you say, like you know, as you say, they've not literally taken that money out. You know, already James Easter on the show and did a really good one. It's like paying between cash and credit and card with cash. I really am. It's a strongly consistent thing. I've given you that money now for that purchase, whereas credit card, you know, card.
本当にそうですね。開発者は常に正しさや一貫性を求めがちですが、現実世界は違います。例えば現金払いなら、その場で完全に整合しますが、クレジットカードは最終的な整合性です。ジェームズ・イースターが番組に来てくれたときも、現金とカードの違いを例に挙げていました。
Ed Mann
英語はこちら
Is a. It's an eventual consistency.
カード決済は最終的に整合すればいい、という世界ですよね。
Scott Wlaschin
英語はこちら
Businesses are business like maybe they, you know, people who do credit card fraud, they just, you know, say well, OK, 5% of our customers are going to cheat us. We just that's the cost of doing.
はい。ビジネス側は『不正利用で5%は損をするかも』と割り切っているかもしれません。それが事業コストなのです。
Scott Wlaschin
英語はこちら
Business you know or you can't be sync exactly exactly, exactly it or maybe you get insurance you know to cover the cost of something happening I mean, you know there's I say these processes have been around for a long time prior to computers they've already got ways of dealing with them and you can't always solve problems computers can't necessarily yeah, so.
あるいは保険で損失を補填するかもしれません。言いたいのは、こうしたプロセスはコンピュータ以前から存在していて、既に対処法があるということです。コンピュータで必ずしも解決できるとは限らないのです。
Ed Mann
英語はこちら
We imagine trying to get that coffee.
コーヒーを受け取るのに、決済が完全に確定するまで待たされるところを想像してみてください。
Ed Mann
英語はこちら
Coffee like until it's cleared 100% on that whatever transaction will not give you this coffee by that.
取引が100%確定するまで『コーヒーは渡せません』と言われたら。
Scott Wlaschin
英語はこちら
Time. Exactly, exactly. It's not going to work exactly.
まさに。そんなの現実的ではありません。
Ed Mann
英語はこちら
Well, thank you so much again Scott for coming on. It's been absolutely amazing. I've really enjoyed it. I think it be really cool maybe just at the end like to maybe talk about some success stories around using functional programming in the real world like kind of in these domains and.
改めて出演してくれてありがとう。とても楽しい時間でした。最後に、現実のドメインで関数型プログラミングを使った成功事例について少し教えてもらえますか。
Scott Wlaschin
英語はこちら
Stuff, yeah, I mean, I try to think of any. I mean, I just found it very useful. I've, I've done a lot of this domain modelling with.
そうですね。たくさんあるわけではありませんが、私はドメインモデリングの現場で関数型をかなり便利に使ってきました。
Scott Wlaschin
英語はこちら
A bunch of business as a consultant, you know.
コンサルとして多くの企業を手伝ってきました。
Scott Wlaschin
英語はこちら
And it's always been very just getting everyone in the same room talking about what the domain is, has been, I've always found it very useful. They've found it very useful too. So I highly encourage people to do that. In terms of functional programming, I've normally, I'm working as a consultant now, so I don't normally get to see my programmes live, you know, past the first couple of months that I've been working on it. But I mean, as far as I know.
何よりも効果的だったのは、関係者全員を一つの部屋に集めて『このドメインは何なのか』を話し合うことです。私自身にも、参加者にも非常に有益でした。だから強くお勧めします。関数型プログラミングそのものについては、私はコンサルタントなので、数か月携わった後の運用を直接見ることはあまりありませんが、
Scott Wlaschin
英語はこちら
People who, if you look at the other people in the F# community, they've always had a lot of success with it. I mean, the reasons why functional programming fail is not normally a technical reason. Again, it's a people reason. It's like they say it's hard to hire people or it's hard to whatever it is, but you know, but in terms of I, I don't know any projects that fails because of functional programming, as far as I know, people have been very successful with it. They've normally done really.
F#コミュニティの人たちを見れば、皆かなり成功しています。関数型がうまくいかないとしたら、技術的な理由ではなく、人の理由です。『採用が難しい』『社内にスキルがない』といった話ですね。ただ、関数型を採用したことで失敗したプロジェクトは私は知りません。多くの場合、とてもうまくいっています。
Ed Mann
英語はこちら
Well, and I suppose this is maybe assuming, but like are there pros and cons to using?
なるほど。では、ドメインモデリングで関数型を使う利点と欠点はありますか。
Ed Mann
英語はこちら
FP in domain modelling or should you always use?
常に使うべきなのでしょうか。
Scott Wlaschin
英語はこちら
Functional, well, I think for the kinds of thing I'm talking about, I very much like functional programming, but it's not, again, it's not a silver bullet that's going to solve all the problems. I mean, there's some, I mean a classic example is you're doing game development. Performance is really important and people like using the ECS model I think where you just, you don't have properties on objects, you just have a list of properties and they're all separate in separate arrays is much more efficient that way. It's much more friendly for the high performance computing.
私が話しているような領域では関数型が大好きですが、銀の弾丸ではなく、万能薬ではありません。典型例はゲーム開発で、性能が非常に重要です。その世界ではECS（エンティティ・コンポーネント・システム）モデルのように、プロパティをオブジェクトに持たせず配列で分離した方が効率的で、高性能計算に向いています。
Scott Wlaschin
英語はこちら
Sometimes financial people, machine learning, sometimes your programme is just a bunch of matrix multiplications or it's a bunch of data trends like your ETL where it's a bunch of data coming in out. It's like, is it not? Probably not worth doing a full domain modelling thing for that. So there's lots of situations. And if you're, you really are doing agent oriented programming, then OO is like perfect for that because that's exactly what OO is when you have a bunch of agents, like if you have autonomous drones that are talking to each other in the sky or something, oh, whoa, it might be the perfect model for that, each of these things.
金融や機械学習の現場では、プログラムが行列の掛け算の集合だったり、大量のデータを流すETL処理だったりします。そういう場合にフルスケールのドメインモデリングをするのは見合わないかもしれません。また、エージェント指向プログラミングが本当に必要なら、オブジェクト指向は理想的です。空を飛ぶ自律ドローン同士がメッセージでやり取りするなら、まさにOOの領域と言えるでしょう。
Scott Wlaschin
英語はこちら
As an autonomous entity that talks to each other through messages and it's like that's a natural domain for.
それぞれがメッセージで通信する自律的な存在なら、自然にフィットします。
Ed Mann
英語はこちら
Picking the right tool.
要は適材適所ですね。
Ed Mann
英語はこちら
Yeah, exactly not. Yeah, it was like we've just been saying there. That's so true. And then with that as well as I've kind of alluded maybe there was if there's a second edition, but perhaps isn't like another book. I know in the last podcast we did, which was way back when they were talking about understanding functional programming, there wasn't the idea there like is there any?
その通りです。さっきも話したとおりです。それから、前回のポッドキャストで触れた『Understanding Functional Programming』のような別の本の構想は進んでいますか。
Scott Wlaschin
英語はこちら
Developments on that Yeah, that's a it's a book. I've just been very lazy, but I, I, I mean, I've got the outline written and I've got.
ええ、あります。かなり怠けていましたが、アウトラインは書いてありますし、
Scott Wlaschin
英語はこちら
A couple of chapters written and I'm just being very lazy about finishing it, but yeah.
いくつかの章も書きました。あとは仕上げを怠けているだけです。
Ed Mann
英語はこちら
I'm sure, I'm sure I'm like a lot of people that I'll be very excited to get that.
きっと多くの人が楽しみにしていますよ。私もその一人です。
Scott Wlaschin
英語はこちら
Book. Yeah, I'm hoping, I'm hoping that I really want. I don't think it'd be a useful book to have some. I am, you know, I do really want to work on it.
私自身も価値ある本になると思っていて、本当に仕上げたいと思っています。
AIの台頭に関して
Ed Mann
英語はこちら
It's just when I can, it's time. No exactly. We just get AI to do it. I mean, maybe I don't ever got time there, but like what I know that you mentioned like maybe having a little chat about AI and stuff. And I wonder like how do you find that is changing the landscape so.
時間さえあれば、ですね。本当です。AIに書かせればいいのでは？ と言いたいところですが、AIについても触れようとしていましたね。最近のAIの潮流をどう見ていますか。
Scott Wlaschin
英語はこちら
OK, here's my here's my position. AI is AI.
私の立場を言うと、AIはAIです。
Scott Wlaschin
英語はこちら
Can increase the speed of coding so and I mean there's a great comic strip by commit strip, which is a programming comic and it's like, you know, we don't need programmers. All we need to do is describe in a very clear and unambiguous way what we want the programme to do and then we can have the AI write it and it's like, well, describing something in a clear and unambiguous way is called programming that's what programming is now it may be a much higher level version of programming like yeah, you might be able to but I.
確かにコーディングのスピードは上げられます。コミットストリップの漫画にもありましたが、『曖昧さなく望む動きを説明できれば、あとはAIがコードを書いてくれるからプログラマーはいらない』という話があります。でも、その曖昧さなく明確に説明する行為こそがプログラミングですよね。レベルが高くなるだけで、本質的にはプログラミングなのです。
Scott Wlaschin
英語はこちら
Think that using English language, I mean, people say, well, if you just have the right prompts, you know, you can do, but I don't think the English language is an unambiguous way of describing programming. So I think, you know, people are using English language prompts for AI right now. But I wouldn't be surprised if people come up with a DSL for doing programming AI, you know, programming AI. And we have a special DSL that's very much more, less, much less ambiguous and much clearer. It's like that is a programming language like SQL or something, you know. So yeah, I could see it as being a high level.
英語でプロンプトを書けば十分と言う人もいますが、英語はプログラムを記述するには曖昧すぎると私は思います。いずれAI向けのDSLが生まれて、今よりずっと曖昧さが少ない言語で指示するようになるかもしれません。それってSQLのようなプログラミング言語ですよね。ですから、AIは高レベルなプログラミング言語のような補助になると思います。
Scott Wlaschin
英語はこちら
Assistance to programmers, but I can't.
プログラマーを助ける存在にはなっても、
Scott Wlaschin
英語はこちら
See it replacing listening to people.
人の話を聞くプロセスを置き換えることはできません。
Ed Mann
英語はこちら
Well, that's I was going to say so this that the thing we were talking about strategic DDD, yeah, that can't be replaced. I suppose it's interesting the tactical and well in the sense of the caring about the intrinsics of this programming language and all these things that.
まさに戦略的DDDの部分は置き換わらないですよね。プログラミング言語の細部など、戦術面がどう変わるのかは興味深いですが。
Scott Wlaschin
英語はこちら
So yeah, I mean, some people say you can just have the customer of the tool directly talk to the AI and not talk to a programmer, but we've seen that happen before. I mean, you know, a customer talking to the.
そうですね。『お客さんがAIと直接話せば開発者はいらない』という話も聞きますが、それは昔から同じです。お客さんが直接ツールを操作したからといって、
Scott Wlaschin
英語はこちら
Talking to an AI tool, it's there's a lot, you know, the reason you hire an expert is they think about things like, you know, security and performance and scaling and blah blah. And you know, if you vibe code something and you don't know what you're doing, you can do you end up in a disaster, you know, and we've already seen a couple of them happen. I don't you know, you're going to have an ex truncate in the whole database and things. Exactly, exactly. So someone, you know, someone who can translate human, you know, non programming people, if you can translate that into requirements that a computer can understand that is a.
専門家が不要になるわけではありません。専門家はセキュリティやパフォーマンス、スケーリングなど多くの観点を考慮します。無計画にAIにコードを書かせれば悲惨な結果になるかもしれません。実際、データベース全体をtruncateしてしまうような事故も起きています。非プログラマーの言葉をコンピュータが理解できる要求に翻訳できる人材は不可欠です。
Scott Wlaschin
英語はこちら
To me, you know, and and that's never going to go out of, you know, that's never going to go out of out of favour. You can always have people do that. Now how you actually just like, you know, people don't do assembly anymore. They use a high level language. That's fine. So that you know, you can have compilers that do stuff. I don't think that AI is going to replace developers.
これは今後も価値があるスキルです。アセンブリを手書きしなくなったのと同じで、高レベルな支援を受けながらも開発者は必要です。AIが開発者を置き換えるとは思いません。
Ed Mann
英語はこちら
We'll probably have more debate. I mean, could you argue we have more developers?
むしろ開発者が増えると言えませんか。
Scott Wlaschin
英語はこちら
Because, well, it's, it's a, it's a skill converting requirements into something that a computer can understand is a skill, I think, and we've talked about some things you can get wrong. And I think that's a good skill. It's a skill to have experience. One of the things that concerns me is it going to get rid of junior developers. A is don't learn the same way. Having a real person that you can train up and then in five years or two years there'll be an ex, there'll be a good developer AI. You know, I do worry that getting rid of the.
要件をコンピュータが理解できる形に変換するのはスキルですし、間違いやすいポイントについても話してきました。それができる経験値はとても価値があります。心配なのはジュニア開発者の育成が難しくなることです。AIは学びませんが、人を育てれば2年、5年で優れた開発者になります。
Scott Wlaschin
英語はこちら
Up is it's going to have a.
その芽を摘んでしまうと、
Scott Wlaschin
英語はこちら
Cause a problem because we need people to become can't get senior developers don't come out of nowhere they.
将来的にシニア開発者が不足する恐れがあります。シニアは突然現れるわけではありません。
Ed Mann
英語はこちら
Have to come up. I mean war stories. Why do you do things the way you do? It is because you learn how to do this. You've had experience. If you don't get the experience.
皆が経験を積み重ねてきたから、今のやり方があるのです。経験を積む機会がなければ、
Ed Mann
英語はこちら
As you say, it's a shortcut right now, right?
結局は近道に頼ることになります。
Scott Wlaschin
英語はこちら
So yeah, exactly 10 years down time. I mean, the thing, the thing I think AI is a just like it's a tool. It can all, if you know and if you know what you're doing, it can augment your skill. Just like using a computer to type rather than writing with a pencil, you know, a word processor and a spell checker.
その通りです。AIは道具です。何をしているか理解しているなら、技能を増幅してくれます。鉛筆ではなくワープロで文章を書くようなものです。
Scott Wlaschin
英語はこちら
So I mean, a spell checker, very simple spell checker can check your spelling, but only if you know that the word is spelled wrong in the 1st place. If you don't know how to spell, a spell checker could give you really weird results, right? And so, you know, you need to basically know how to spell, but a spell check can be very helpful if you do know how to check because it can go much faster than you can. So I mean, you know, as a tool that augments, augments your skills, I think AI can be useful. However, knowing the way that capitalism works is not going to be used to augment people. It's going to be used to replace people.
ただし、スペルチェッカーが役に立つのは、自分が綴りを理解している場合だけです。綴りを知らない人が使えば、とんでもない結果になります。つまり、基本を理解したうえで使えばスピードアップできるということです。AIも同じく、技能を補強する道具として有用です。ただ資本主義の仕組みを考えると、人を補強するのではなく置き換える方向に使われがちなのが心配です。
Scott Wlaschin
英語はこちら
And I think that's, you know, I don't think that's good. I think it's going to end in tears, but, you know.
それは良いことだとは思いませんし、きっと痛い目を見る人が出るでしょう。
Ed Mann
英語はこちら
Do you think we're in just a big bubble at the moment?
今は巨大なバブルの最中だと思いますか。
Scott Wlaschin
英語はこちら
I mean, the amount of compute power needed to run these AIS at the moment, now it might change, but right now it's ridiculous. And there were all these, all these AI companies are losing money.
はい。現状のAIを動かすには膨大な計算資源が必要ですし、多くのAI企業が赤字です。状況は変わるかもしれませんが、今のところはそうです。
Ed Mann
英語はこちら
Well, that's what I go get. Like no one's who is making money at the moment. I know Sam will not. We're only doing inference. If we're only doing inference, we would have been making money.
本当にそうですよね。実際、誰が利益を出しているのでしょう。推論だけで済むならもう黒字だ、とサムも言っていましたけど。
Scott Wlaschin
英語はこちら
But they need to be training these new models, which is then incurring all the, well, the idea that I don't think anyone's making money. I think the idea is again, the subscription model which we've seen.
でも彼らは新しいモデルを訓練し続けなければならず、そのコストがかさみます。結局、またサブスクリプションモデルになると思います。
Scott Wlaschin
英語はこちら
With all the other software stuff is you start off by saying, oh, it's you know, £20 a month, $20.00 a month. And then when you, when you, when you say your whole business gets starts, you know, you use this part of your business and oh, by now it's £100, now it's £200. Now it's £500 a month. It, you know, and we've seen it happen with it used to be you could buy, you know, Microsoft Office and you could buy Adobe Photoshop and you could buy it and now it's a subscription. And now if you use Photoshop as part of your call thing, you now have to if Adobe wants.
他のソフトウェアと同じで、最初は月20ドルと言いながら、ビジネスが依存するようになると100ドル、200ドル、500ドルと上がっていきます。昔はMicrosoft OfficeやAdobe Photoshopを買い切りで購入できましたが、今はサブスクリプションです。Photoshopが仕事に不可欠なら、値上がりしても従うしかありません。
Scott Wlaschin
英語はこちら
The price you have to suck it up because that's, you know, and I, you know, I guarantee, I guarantee that they're going to. And another good example is like Netflix, you know, when you used to buy a DVD, you own the DVD and now you say, well, Netflix is so much more convenient, but then they keep raising the prices and they keep adding advertising. You never truly own anything. And yeah, so the thing about AI is, you know, I guarantee they will just if once you get hooked onto it, they're going to keep raising the prices and then.
Netflixも同じです。昔はDVDを買えば自分のものになりましたが、『Netflixの方が便利だ』と乗り換えたら、料金は上がり続け、広告も増え、結局何も所有していない。AIも同じで、一度依存すると価格はどんどん上がるでしょう。
Ed Mann
英語はこちら
They're going to have to, I think, to compute costs like and again, electricity like this is the.
計算コストや電力代も上昇していますしね。
Ed Mann
英語はこちら
It's the energy it requires to be training well first. It's also training these new models because we're all trying to strive for this in quotes AGI But like, yeah, we're going to an inference. It just costs it costs a lot of compute and a lot of.
そうです。新しいモデルを訓練するには膨大なエネルギーが必要です。皆がAGIを目指していると言いますが、推論だけでも莫大な計算資源と電力を消費します。
Scott Wlaschin
英語はこちら
Time Well, we'll see. I mean, I don't think it's, I think it's definitely a bubble. And I've been through a bunch of bubbles before. And if you look historically, there's been bubbles, you know, there was the bubble over telegraphy and there's a bubble over train, you know, railroads and there's a bubble over televisions and bubble over electronics and they're now bubble.
どうなるか様子を見るしかありません。個人的にはバブルだと思います。電信、鉄道、テレビ、電子機器など、歴史的にもバブルは何度もありました。
Scott Wlaschin
英語はこちら
Thefirst.com bubbleandthesecond.com bubble. So yeah, I mean, you know, like with most bubbles, it leaves something useful behind. I mean, you know, the railroad bubble left a bunch of useful train tracks and thefirst.com bubble left a bunch of, you know, high speed Internet and stuff. But yeah, a lot of people, the bubble is going to burst and, you know, we will see. But I mean, I can say I can see AI being a useful tool, but I haven't seen it be a replacement, a good replacement for somebody who knows someone who knows what they're doing.
第一次ドットコムバブル、第二次ドットコムバブルもそうです。バブルは弾けますが、後には有用なものが残ります。鉄道バブルが残したのは線路で、ドットコムバブルが残したのは高速インターネットでした。AIも便利な道具を残すでしょうが、専門家を置き換えるほど信頼できるものはまだ見ていません。
Scott Wlaschin
英語はこちら
And I mean, judging by some of the stuff I've seen come out there, and it's like if you had an employee, let's say you had a junior developer and 90% of the time they were really good and tempers at the time, they produced rubbish. And 10% on how to go, how to go through the code and rewrite all their code because it was rubbish and they never learned. And it's like after six months they were still producing rubbish. 10% of the time that would be, I would fire that person. So the question is, can AI get past that? Can it, You know, right now it seems like 90%. Sometimes it does good stuff, but sometimes it doesn't. And.
実際に見かけるコードを見ると、たとえばジュニア開発者が90%は良い仕事をしても10%はひどいコードを出し、半年経っても改善しなければ、その人は解雇されるでしょう。AIがその段階を乗り越えられるのかが問題です。今のところは良い結果も出せますが、同じくらい外します。
Scott Wlaschin
英語はこちら
Problems. I never know.
その点が課題ですね。
Ed Mann
英語はこちら
Well, the model changes and the travel is it's not an incremental batch learning system. It doesn't learn on the fly. It's a one and done and this model now and I guess you can learn to prompt it in certain ways, but it is a bit whack A mole. But when it worked, the trouble is, is when it works and you play around with these things, it is that you do get that hit of all.
モデルが更新されても、段階的に学習するバッチ処理ではないので、その場で学習してくれるわけではありません。プロンプトの工夫で何とかできることもありますが、もぐら叩きのようなものです。うまくいったときの爽快感があるだけで。
Scott Wlaschin
英語はこちら
My days, it's just built this thing out of nowhere for me, right and saying, but this I mean, like I say, I've seen this before with with, you know, when they had fantastic things that would generate all your code for you. I've seen, you know.
『すごい、何もないところからこの機能を作ってくれた』と思う瞬間はあります。ただ、過去にも全自動でコードを生成するツールがありましたが、
Scott Wlaschin
英語はこちら
It's like the first time you use it, it's fantastic, but then when you want to maintain it or you want to.
最初は感動しても、保守や変更の段階になると途端に大変になるんですよね。
Ed Mann
英語はこちら
Change it. We're going to be managing vibe coded products like it's not going to be legacy code anymore.
将来はレガシーコードではなく『バイブコード』の面倒を見ることになるかもしれませんね。
Scott Wlaschin
英語はこちら
It's going to be vibe coded products. Exactly. Now, exactly. We'll see. I mean, I know I'm a bit cynical about this having been through a bunch of hype bubbles before, but we will see. But right now, as it stands, I don't think it's sustainable, you know, I mean, I think there'll be something will come useful out of it, like I say, but I don't think it's going to change the world like people think it will be. Well, we'll see. I might be well.
そう、バイブコードです。私は過去のハイプを何度も経験しているので少し懐疑的ですが、見守りましょう。ただ、現状のままでは持続可能ではないと思っています。何かしら役に立つものは生まれるでしょうが、人々が期待するほど世界を変えるかは疑問です。まあ、そのうちわかるでしょう。
Ed Mann
英語はこちら
One night. I mean. This is really interesting. Did you use?
ところで、実際にAIを使っていますか。
Scott Wlaschin
英語はこちら
Much AI stuff like no, I don't today. No, I don't want to pay. I don't want to 1st, I don't want to get sucked into paying the money. And secondly, I I just want to if I learn, if I'm, if there's a framework I want to use, then I want to learn how to do that framework. Because if the AI generates all the code for me, how do I know if that code's any good? And if I don't know, then it might be rubbish. And it's like I don't know because I don't know what I don't know. And it's like in order for me to know what the help is any good, I need to be reasonably good in it myself. So I'd rather just.
ほとんど使っていません。有料プランに引き込まれたくないですし、何より自分が使いたいフレームワークがあるなら、自分で学びたいからです。AIがコードを生成しても、それが良いコードか判断できなければ意味がありません。判断できないならゴミかもしれないし、そもそも自分が何を知らないのかも分からない。助けが役に立つかを判断するには、自分自身がある程度習熟していなければならないのです。
Scott Wlaschin
英語はこちら
Done it myself, you know, but I mean as I say, once I know that particular framework then I can then I can help it, then it can augment me.
もちろん、一度身につけてしまえば、その後は補助として使うのは大いにアリだと思います。
Ed Mann
英語はこちら
By generating the augmentations the pie isn't it?
つまり、拡張を生成してもらう補助輪ですね。
Scott Wlaschin
英語はこちら
Right that I have no problem with that. It's just using it to replace thinking.
そう。思考そのものを置き換えるために使うのでなければ問題ありません。
効果的に学習をする方法
Ed Mann
英語はこちら
Yeah, you can't RIP it. That's the thing. You can't replace thinking ever. And I think that's the thing with all these things now, it's really interesting. And I'd say finally, like the last question today would be like, how do you individually learn best? Like I always want, it's such an invaluable skill like to learning how to learn and how you learn. I'm just wondering.
考える行為は置き換えられません。そこが面白いところですよね。さて最後の質問ですが、あなたが最も効果的に学ぶ方法は何ですか。学び方を学ぶのはとても大切なスキルだと思うのですが。
Ed Mann
英語はこちら
How you discovered the best ways that you learn most effectively.
ご自身で最良の学び方をどう見つけたのか教えてください。
Scott Wlaschin
英語はこちら
So I like to do multiple different things and kind of meet in the middle. So if I'm learning something, first of all, I will just come up with some sort of hacky prototype. I'll, you know, design a little project. If I want to learn a new programme in English, for example, I will start building something, but I'd also like to read the documentation. And I also like to see how other people have done it. And I try and combine all these different things from different angles. Like I think the more different angles you come at, the better it is. I mean, another example.
私は複数のアプローチを組み合わせて、真ん中で落ち合うのが好きです。まずは適当なプロトタイプを作り、小さなプロジェクトを設計します。新しいプログラミング言語を学ぶなら、実際に何かを作り始めますし、ドキュメントも読みます。ほかの人がどう書いているかも調べます。いろいろな角度から攻めるほど学びは深くなると思います。
Scott Wlaschin
英語はこちら
You're learning a foreign language or something, you know, they say you want to learn, you know, where you want to learn conversational French or something. So you know, you learn to, you do the, you practise your conversations, but you also listen to French radio and read French newspapers, but you also get a French grammar book and you try and memorise the French, you know, vocabulary, all those things. You can't just use one or the other. The combination of all these different approaches gives you the fastest, best results, I think. So that whether it's learning programming or it's learning something else.
外国語を学ぶときと同じです。会話を練習するだけでなく、ラジオを聞き、新聞を読み、文法書で語彙を覚える。どれか一つだけでは不十分で、複数のアプローチを組み合わせるのが最速で最良の方法だと考えています。プログラミングでも他の学びでも同じです。
Scott Wlaschin
英語はこちら
You know, a combination of practise.
実践の積み重ね、そして、
Scott Wlaschin
英語はこちら
And reading and and and getting feedback from other people and all these things together. I don't think there's one single, you know, way that you can just use. The more different approaches, the better.
読書や他者からのフィードバックなど、さまざまなものを組み合わせる。それが一番です。一つのやり方だけで済むとは思えません。アプローチが多いほど良いのです。
Ed Mann
英語はこちら
Way, yeah, absolutely. And then just for the audience, what would be the best way for.
なるほど。では最後に、リスナーがあなたの近況を知るにはどうすればよいでしょう。
Scott Wlaschin
英語はこちら
Them to keep up to date with you. Well, I'm pretty much not using social media very much. I'm still on Twitter. I'm on blue sky and I'm on and I'm I'm going to keep calling it Twitter. I'm sorry. No, I keep doing it.
私はソーシャルメディアをあまり使っていませんが、Twitter（私は今でもそう呼びます）、Bluesky、Mastodonにはいます。
Scott Wlaschin
英語はこちら
Twitter, Blue Sky and Mastodon.
Twitter、Bluesky、Mastodonですね。
Scott Wlaschin
英語はこちら
But I'm not really active much. I mean, if you contact me on one of those things, my name is Scott Wlaschin is on all of them, I think. So you can probably find me pretty easily. But you know, I'm not posting that much and.
ただし、ほとんど投稿はしていません。これらのサービスでは Scott Wlaschin の名前で見つかるはずなので、連絡したければ探してみてください。
Ed Mann
英語はこちら
I'm not. We'll put, we'll put it all.
番組ノートに全部載せておきますね。
Ed Mann
英語はこちら
In the show notes, Yeah. It's been a really, really interesting episode or episodes. I think this will be. But thank you so much again, Scott, for coming on. I really do.
今回も本当に興味深いエピソードでした。出演してくれてありがとう、スコット。
Scott Wlaschin
英語はこちら
Appreciate it. My pleasure. Thanks for having.
こちらこそありがとうございます。呼んでくれて嬉しかったです。
Ed Mann
英語はこちら
Me. Awesome. Well, audience, until next time, goodbye.
では皆さん、また次回お会いしましょう。さようなら。
まとめ
このエピソードでは、関数型アプローチでドメインを扱う際に直面する具体的なテーマを掘り下げました。主なポイントは以下の通りです：
- 関数型プログラミングの基本姿勢 - 小さな純粋関数を合成し、パイプラインで思考の流れをそのままコード化する方法。
- 型システムによる表現力 - 代数的データ型や活性パターンを用いてルールを型に閉じ込め、バリデーションやエラー防止を強化する手法。
- ドメイン要素のモデル化 - エンティティと値オブジェクト、コレクション、語彙制約などを不変データで表し、ユビキタス言語と整合させる工夫。
- ワークフロー指向設計 - コマンド入力からイベント出力までを直列化し、コンポジションと差分変更を容易にする考え方。
- イベント駆動とサガ - キューを使った非同期連携や補償トランザクションで長時間処理と失敗を取り扱う戦略。
- 永続化戦略の再考 - リポジトリパターンを必須とせず、ワークフローごとに必要な永続化操作だけを集約する関数型的なアプローチ。
- テスト容易性と入力・出力 - 純粋関数として設計することで、副作用を切り離し、入出力の検証だけでワークフロー全体を確認できる利点。
- AIと学習スタイルへの洞察 - AIツールを補助的に捉えつつ、複数の学習方法を組み合わせてスキルを獲得する重要性。
テクノロジーよりも、明確な境界づけとプロセス理解を重視する姿勢が一貫しており、関数型プログラミングがDDDの実践をどのように後押しするかを具体的に示す内容でした。
これで Compiled Conversation #8, #9 の一連の翻訳記事は終わりです！長い記事でしたが、読了お疲れ様でした。
ポッドキャスト、よろしければ英語ですがわかりやすい英語ですので聞いてみるのがお勧めです！
ホストのEddさん と ゲストのScottさんのXにも最新情報が載せられていますので、ぜひご覧ください。
Discussion