We also created a bunch of empty folders, which you can see on the side right now, for presentation, domain, and data.

また、プレゼンテーション用、ドメイン用、データ用の空のフォルダもたくさん作った。

This is for the Number Trivia app we are building.

これは私たちが作っている数字トリビアアプリのためのものです。

And now it's time to start filling in these empty folders with actual code, of course, using test-driven development.

そして今、これらの空のフォルダを実際のコードで埋め始める時だ。もちろん、テスト駆動開発を使って。

Hello, welcome to ResoCoder, where you are getting prepared for real app development by building better, faster, more stable apps.

ResoCoderへようこそ。ResoCoderでは、より良く、より速く、より安定したアプリを開発することで、本格的なアプリ開発の準備をすることができます。

So subscribe and hit the bell if you want to grow your coding skills.

コーディングのスキルを伸ばしたいなら、ぜひ購読してベルを鳴らしてほしい。

So, of course, whenever you are building an app, you should start with the UI and user experience first, but I've done that homework for you.

だからもちろん、アプリを作るときはいつでも、まずUIとユーザー・エクスペリエンスから始めるべきだ。

As you've seen in the previous tutorial, the app looks something like this.

前のチュートリアルで見たように、アプリは次のようになる。

The app looks like this, the actual coding process, though, will happen from the innermost stable layers and will progress toward the outer layers.

アプリはこのように見えるが、実際のコーディング作業は、最も内側の安定したレイヤーから始まり、外側のレイヤーに向かって進んでいく。

So in the case of clean architecture, as it was proposed by Uncle Bob, we can see that we should start from the domain layer, particularly from entities.

つまり、ボブおじさんが提唱したようなクリーン・アーキテクチャの場合、ドメイン層、特にエンティティから始めるべきだということがわかる。

So we are going to create an entity right now.

だから、今すぐエンティティーを作ろう。

Before we do that, though, before we can create an entity for the number trivia, we have to add some packages over to pubspec.yaml, because we are going to be using quite a lot of packages to make things easier for us, of course.

その前に、トリビア番号のエンティティを作成する前に、pubspec.yamlにいくつかのパッケージを追加しなければならない。

And with that, I have to tell you to make sure you check out the written tutorial from the link in the description, where you can find all of the code written in this video, all of the links, and all of that good stuff.

説明文のリンクから、このビデオで書かれたすべてのコード、すべてのリンク、その他すべての良いものを見つけることができます。

And go through this lesson at your own pace.

そして、自分のペースでこのレッスンを進めてください。

This pubspec.yaml file is one of the few things which I'm going to just copy and paste over on video so that I don't bore you to death.

このpubspec.yamlファイルは、皆さんを退屈させないために、ビデオでコピー＆ペーストする数少ないもののひとつです。

So let's just delete all of these unnecessary comments.

だから、不要なコメントはすべて削除しよう。

We'll just clutter up the pubspec.yaml file.

pubspec.yamlファイルを乱雑にするだけだ。

And then the dependencies and dev dependencies will be the following.

そして、依存関係と開発依存関係は次のようになる。

So we have getit, which is the service locator.

サービス・ロケーターであるgetitがある。

I've added all of the dependencies right now so that we later do not have to come back to this yaml file and just lose time on that.

後でこのyamlファイルに戻ってくる必要がなく、時間を無駄にすることがないように、今、依存関係をすべて追加した。

So we have getit.

だから、私たちにはゲットがある。

Then we have flutter block for state management, equatable for value equality.

そして、状態管理のためのフラッター・ブロックと、値の等化のためのイコータブルがある。

Then we are going to touch on some functional programming concepts.

その後、関数型プログラミングの概念に触れる。

Then for remote API, we have connectivity and HTTP packages, of course.

それからリモートAPIについては、もちろんコネクティビティとHTTPパッケージがある。

And for local cache, we are going to be using just simple shared preferences.

そしてローカル・キャッシュには、シンプルな共有プリファレンスを使用する。

As for dev dependencies, these are the ones which do not get packaged together with your app once you build it.

dev dependenciesについては、アプリをビルドしても一緒にパッケージ化されないものです。

We have flutter test.

フラッターテストもある。

This was here even before I think by default.

これはデフォルトだと思う。

And then we have Mockito for creating mocks.

そして、モックを作成するためのMockitoがある。

We are going to get to all of this as we progress forward with this tutorial.

このチュートリアルを進めていくうちに、これらすべてを理解できるようになるだろう。

But just so that you have all of the packages already present, we've added them over here.

しかし、すでにすべてのパッケージが揃っているように、ここに追加した。

And I'm just going to delete all of the other comments so that they don't clutter up pubspec.

そして、パブスペックを散らかさないように、他のコメントはすべて削除するつもりだ。

And here we go.

そして、これだ。

The pubspec.yaml file is completely finished.

pubspec.yaml ファイルは完全に完成しました。

All right.

分かった。

So let's now move on to creating the actual entity.

それでは、実際のエンティティの作成に移ろう。

The first question we have to ask ourselves is what kind of data will the NumberTrivia operate with?

最初の疑問は、NumberTriviaはどのようなデータを扱うのか、ということだ。

Well, of course, with NumberTrivia entities.

まあ、もちろん、NumberTriviaのエンティティでは。

So we can create a new file under the domain entities.

そこで、ドメイン・エンティティの下に新しいファイルを作成することができる。

Let's call it NumberTrivia.dart, of course.

もちろん、NumberTrivia.dartと呼ぶことにしよう。

And now we have to take a look at the JSON response from the API because based on that response, we are going to model our class here.

APIからのJSONレスポンスを見て、そのレスポンスに基づいてクラスをモデリングする。

So if you go to numbersapi.com forward slash 42 or some other number and then question mark JSON, so it's a query parameter, you will obtain the following response.

つまり、numbersapi.comのフォワード・スラッシュ42やその他の数字にクエスチョンマークを付けてJSONにアクセスすると、クエリー・パラメーターとして次のようなレスポンスが返ってくる。

And of course, this link is also available from the written tutorial.

もちろん、このリンクは書かれたチュートリアルからも利用できる。

So this is the response which we will be operating with throughout our app.

つまり、これが私たちのアプリ全体を通して操作することになるレスポンスなのだ。

And we need to model our NumberTrivia entity so that it can contain this kind of data.

そして、NumberTriviaエンティティをモデル化して、この種のデータを格納できるようにする必要がある。

So what do we actually really need from this JSON object?

では、このJSONオブジェクトから実際に何が必要なのだろうか？

Well, we need the text, obviously, because that's the core, so to say, functionality of our NumberTrivia app.

NumberTriviaアプリの核となる機能だからだ。

We are going to store the number, but then we have two interesting fields, which are found and type.

番号を保存するつもりだが、次に2つの興味深いフィールドがある。

We are not going to need those at all because found is completely irrelevant for our case, and the type will be always trivia.

ファウンドは今回のケースにはまったく関係ないし、タイプは常にトリビアになるからだ。

And why is found completely irrelevant?

そして、なぜまったく関係ないことがわかったのか？

Well, if I search for a number other than 42, so for example, some complete gibberish long number, which doesn't have any entry in the numbers API and search for that, you can see that found is false, but we still obtain some kind of a reasonable response that this is an uninteresting number.

さて、42以外の数字を検索してみよう。例えば、数字APIにエントリーがないような、まったくちんぷんかんぷんな長い数字を検索してみると、foundが偽であることがわかる。

So we can still display even this message to the user in the app.

だから、このメッセージさえもアプリでユーザーに表示することができる。

We do not need to worry at all whether or not the number was found.

番号が見つかったかどうかを心配する必要はまったくない。

So the bottom line is that we need the text and number fields to map to properties in our app.

要するに、テキスト・フィールドと数値フィールドをアプリのプロパティにマッピングする必要があるということだ。

So let's create a class, NumberTrivia, which will extend Equatable.

そこで、Equatableを継承するクラスNumberTriviaを作成しよう。

And let's import Equatable here.

ここでEquatableをインポートしよう。

This is so that value equality is made simple because by default, Dart supports only referential equality.

デフォルトでは、Dartは参照対等のみをサポートしているからである。

So even two objects which contain completely the same data will not be equal unless they are referencing to the same point in memory.

そのため、完全に同じデータを含む2つのオブジェクトであっても、メモリ上の同じポイントを参照していない限り、等価にはならない。

With Equatable, this is completely changed.

エクイタブルを使えば、これは完全に変わる。

When two objects contain the same values, the same data, they will be equal.

2つのオブジェクトが同じ値、同じデータを含むとき、それらは等しくなる。

And we do not need to override equal operator or hash code, anything like that.

また、等号演算子やハッシュ・コードなどをオーバーライドする必要もない。

Equatable does that for us.

エクイタブルはそれをやってくれる。

So it saves us a bunch of boilerplate.

だから、定型文の手間が省ける。

And now we need to store the text and number.

そして今度は、テキストと番号を保存する必要がある。

So final string text, and then final int number.

つまり、最終的な文字列はテキスト、そして最終的な数値はint。

And of course, we need to put them into constructor.

そしてもちろん、コンストラクターにそれらを入れる必要がある。

So we can just hit control dot, at least in VS code, and create constructor for all of these fields here.

だから、少なくともVSのコードでは、コントロール・ドットを押すだけで、ここにあるすべてのフィールドのコンストラクタを作成できる。

But we are not just going to have this kind of a constructor with unnamed arguments.

しかし、このような無名の引数を持つコンストラクターだけを持つつもりはない。

We want to have them named.

私たちは彼らに名前をつけてもらいたい。

And of course, we are going to make them required.

そしてもちろん、我々はそれを義務付けるつもりだ。

So we need to import meta package.

そこでmetaパッケージをインポートする必要がある。

So meta dot Dart.

だからメタ・ドット・ダート。

And let's just make these required.

そして、これらを必須としよう。

And also this one will be required here.

そして、これもここで必要になる。

And we mustn't forget to pass these over to the super constructor, because Equatable needs to know which properties to make equality happen on.

そして、スーパーコンストラクタにこれらを渡すことを忘れてはならない。Equatableは、どのプロパティで等価性を実現するかを知る必要があるからだ。

So we are going to pass them in as a list.

そこで、リストとして渡すことにする。

So we pass in text and also number to the super constructor, which is Equatable.

そこで、スーパーコンストラクタであるEquatableにテキストと数値を渡す。

And you may have noticed that we didn't do any test driven development here.

そしてお気づきかもしれないが、ここではテスト駆動開発をしていない。

That's because this class is really, it doesn't have any logic.

それは、このクラスが本当に、ロジックを持たないからだ。

There is why we aren't writing any tests for this number trivia entity.

私たちがこの数字のトリビアの実体のテストを書いていない理由がそこにある。

Should you have any logic inside your entity, you would write test even for entity, but that's not the case with this one.

エンティティの中に何かロジックがあれば、エンティティのテストも書くだろうが、この場合はそうではない。

All right, now let's talk about use cases.

では、ユースケースについて話そう。

They are where the business logic gets executed.

ビジネスロジックが実行される場所だ。

And sure, there won't be much logic in the number trivia app, because all a use case will do is to get data from a repository.

ユースケースが行うのは、リポジトリからデータを取得することだけだからだ。

So just so you can see that, here we go with the diagram.

この図を見てほしい。

We have use case here.

ここにはユースケースがある。

It will get data from the repository and they will communicate together through these entities.

リポジトリからデータを取得し、これらのエンティティを通じて相互に通信する。

And we have created just one such entity called number trivia a few moments ago.

そして、私たちは先ほど、ナンバー・トリビアと呼ばれるそのような存在のひとつを作り上げた。

And we are going to have two use cases in our finished app, getConcreteNumberTrivia and getRandomNumberTrivia.

完成したアプリでは、getConcreteNumberTriviaとgetRandomNumberTriviaの2つのユースケースを用意する。

By looking at this diagram, as I've already said, you know that use cases get data from repositories, and then they pass that data, which in this case are entities, over to the presentation logic holders and to the whole presentation layer.

この図を見れば、すでに述べたように、ユースケースはリポジトリからデータを取得し、そのデータ（この場合はエンティティ）をプレゼンテーション・ロジック・ホルダーやプレゼンテーション・レイヤー全体に渡すことがわかる。

So it kind of makes sense that when a use case is communicated with repositories, the repository should return an entity, right?

だから、ユースケースがリポジトリと通信されるとき、リポジトリがエンティティを返すのは理にかなっているよね？

But because we have to allow for asynchronous operations, we are going to wrap this entity, which in this case is number trivia, into a future.

しかし、非同期操作を許可しなければならないので、このエンティティ（この場合は数字の豆知識）をfutureにラップすることにする。

But that's not the actual case of what we are going to do.

しかし、それは実際にやろうとしていることではない。

We have to think about error handling as well, because is it the best choice to let exceptions freely propagate?

例外を自由に伝播させることが最善の選択なのか？

Having to remember, and when you have to remember something, you know that that's not cool.

覚えておかなければならないこと、そして何かを覚えておかなければならないとき、それがクールでないことがわかる。

We have to remember to cache them somewhere else in the code if we let exceptions just nicely propagate at their own peril.

例外をそのまま放置しておくと危険なので、コード内のどこかにキャッシュしておく必要がある。

I do not think that this is the best choice.

これが最善の選択だとは思わない。

Instead, we want to catch exceptions as early as possible inside the repository here, and then return failure objects from the repository methods.

その代わりに、ここではできるだけ早い段階でリポジトリの内部で例外をキャッチし、リポジトリのメソッドから失敗オブジェクトを返したい。

So unlike exceptions, you will not have to try and catch all of these exceptions.

そのため、例外とは異なり、これらの例外をすべてキャッチしようとする必要はない。

You will have failure objects, which are returned as regular objects, return types from methods.

通常のオブジェクトとして返される失敗オブジェクトや、メソッドから返される型がある。

There will be no special error flow, nothing like that.

特別なエラーフローはない。

It will be just like a regular data flow without any kind of try-catch-finally blocks in the rest of the app from the repository upwards.

リポジトリから上のアプリの残りの部分では、try-catch-finallyブロックのようなものはなく、通常のデータフローのようになる。

So to recap, repository and then subsequently use cases will return both number trivia objects, and also they will return failure objects from their methods.

まとめると、リポジトリとそれに続くユースケースは、数字のトリビア・オブジェクトを返し、またメソッドから失敗オブジェクトを返す。

So how is something like that possible?

では、どうしてそんなことが可能なのか？

How can we return number trivia or failure from the same method?

同じメソッドから数字のトリビアや失敗を返すには？

Welcome functional programming, and that's why we have imported the darts package over to our app.

ようこそ、関数型プログラミングへ。それが、ダーツ・パッケージを私たちのアプリにインポートした理由です。

This functional programming darts package allows us to simply use an either type.

この関数型プログラミング・ダーツ・パッケージは、単純にどちらかの型を使うことができる。

While I will not pretend that I am some functional programming pro, at least not yet, you don't need to know any really advanced stuff about either type, which is a functional programming concept, will allow us to return either number trivia or failure, which we are going to create next.

少なくともまだ、私が関数型プログラミングのプロであるかのようなふりをするつもりはないが、関数型プログラミングの概念であるどちらの型についても、本当に高度なことを知る必要はない。

Obviously, we still do not have any failure classes.

もちろん、まだ失敗クラスはない。

So let's define them right now.

では、今すぐ定義してみよう。

We are going to create an error subfolder under core, and this will hold failures.dart.

coreの下にerrorサブフォルダーを作成し、ここにfailures.dartを格納する。

And the failure here will be really only a simple class.

そして、ここでの失敗は、本当に単純なクラスだけだろう。

It will be abstract actually, because then later on, we are going to create some concrete implementations of failure objects.

これは抽象的なもので、後で失敗オブジェクトの具体的な実装を作るからだ。

And again, we are not writing this in test-driven development manner, because there is nothing to test in an abstract class.

抽象クラスにはテストするものがないからだ。

So this will be abstract class failure.

つまり、これは抽象的なクラスの失敗ということになる。

Let's again extend equitable, so that the class is extending failure later on, should they have any fields like message or some error code or something like that, their equality will be able to be checked based on those fields.

equitableを再び拡張して、このクラスが後で失敗したときに、メッセージやエラー・コードなどのフィールドがあれば、そのフィールドをもとに等質性をチェックできるようにしよう。

So for that, to use equitable in this abstract base class, we have to have a constructor here, which will accept a list of properties, which will equal const dynamic, which will be an empty list.

そのため、この抽象基底クラスでequitableを使うには、コンストラクタを用意する必要がある。コンストラクタはプロパティのリストを受け取り、そのリストはconst dynamicと等しく、空のリストになる。

And then we will pass this list of properties over to the super constructor.

そして、このプロパティのリストをスーパーコンストラクタに渡す。

This is nothing really to worry about.

これは本当に心配することではない。

This is just what's going on with this Dart analyzer.

このダート・アナライザーで起こっているのはまさにこれだ。

This is just simply the way that things work with equitable.

これは単に、エクイタブルで物事がうまくいく方法なのだ。

So we pass in properties over to the super constructor.

そこで、スーパーコンストラクタにプロパティを渡す。

And again, this is only an abstract class.

繰り返すが、これは抽象的なクラスに過ぎない。

We are going to create concrete classes in the next parts of this course.

このコースの次のパートでは、具体的なクラスを作成します。

Then as you hopefully remember from the last part, and as is signified by this diagram here, a repository from which a use case gets its data is both inside the domain layer and inside the data layer as well at the same time.

前編を思い出してほしいが、この図に示されているように、ユースケースがデータを取得するリポジトリは、ドメインレイヤーの中にあると同時にデータレイヤーの中にもある。

Or to be more precise, the definition of a repository, or as we are going to call it, a repository's contract is present in the domain layer.

より正確には、リポジトリの定義、あるいはこれから呼ぶように、リポジトリの契約はドメイン層に存在する。

This upper half of this gradient is pink or what is this color or whatever.

このグラデーションの上半分はピンク色で、これは何色なんだ？

And then the concrete implementation of a repository, this green side of the gradient is in the data layer.

そして、リポジトリの具体的な実装は、この緑色のグラデーションのデータ層にある。

This will allow for total independence of the domain layer.

これにより、ドメイン層の完全な独立が可能になる。

But there is also another benefit, which we haven't talked about yet.

しかし、まだ話していない別のメリットもある。

And that is testability.

そして、それがテスト可能性である。

That's right.

その通りだ。

Testability and separation of concerns go together extremely well.

テスト容易性と懸念事項の分離は非常に相性が良い。

And this is the absolute beauty of clean architecture because it really complements test-driven development because without architecture, you cannot even test anything because spaghetti code, believe it or not, cannot be tested.

なぜなら、アーキテクチャがなければ、何もテストすることができないからだ。

How will this allow for this?

これによってどのように可能になるのか？

This will be an abstract repository class, will allow us to write tests, test-driven development style, of course, for the use cases, even without having an implementation of the repository.

これは抽象的なリポジトリクラスとなり、リポジトリの実装がなくても、もちろんユースケースに対してテスト駆動開発スタイルでテストを書くことができる。

Something like this is called mocking.

こういうのをコケにするっていうんだよ。

And we are, of course, going to get to that later on.

もちろん、それについては後で説明するつもりだ。

For now, let's create the so-called contract of the repository.

とりあえず、リポジトリのいわゆるコントラクトを作ってみよう。

Inside the domain folder, under repositories, let's create a new file, NumberTriviaRepository.dart.

domainフォルダのrepositoriesの下に、新しいファイルNumberTriviaRepository.dartを作成します。

And inside of here, we will have an abstract class, NumberTriviaRepository.

この中にNumberTriviaRepositoryという抽象クラスがあります。

And this class will have the following interface.

そして、このクラスは次のようなインターフェイスを持つ。

We want to have two methods here, one for getting concrete number trivia, for which we have to pass in a number.

ここでは2つのメソッドを用意したい。1つは具体的な数字のトリビアを得るためのメソッドで、数字を渡す必要がある。

And don't worry, I will come back to the return types in just a bit.

リターン・タイプについては、また後ほど。

So getConcreteNumberTrivia, int number.

というわけで、getConcreteNumberTrivia, int number.

If I could write number.

もし私が数字を書けるとしたら。

And then, of course, it's going to have getRandomNumberTrivia, which will not have any parameters.

そしてもちろん、パラメータを持たないgetRandomNumberTriviaもある。

So let's just rename concrete to random.

だから、コンクリートはランダムという名前に変えよう。

And what is going to be its return type?

その戻り値の型は？

Well, we are going to use that either type, which I have described previously.

さて、前回説明したどちらのタイプも使うことになる。

So let's go bit by bit.

では、少しずつ行こう。

It will, of course, still return a future, because it will be an asynchronous operation to get the concrete or data sources.

もちろん、コンクリートやデータソースを取得するための非同期操作であるため、フューチャーを返すことに変わりはない。

And what's interesting is the type which the future will wrap.

そして興味深いのは、未来が包むタイプだ。

It will be either, which comes from the darts package.

それはダーツのパッケージから来るものだ。

So let's import that.

だから、それを輸入しよう。

And then, either gets two type parameters.

そして、どちらかが2つの型パラメーターを取得する。

One is left, so L, and R for right, of course.

ひとつは左だからL、右はもちろんR。

And the left side is always, for this kind of error handling, the failure.

そして左側は、この種のエラー処理では常に失敗である。

So let's import failure here.

だから、ここで失敗を輸入しよう。

And the right side is always the success kind of data.

そして右側は常に成功のデータだ。

So in this case, it will be the entity number trivia.

というわけで、今回はエンティティ・ナンバーのトリビアとなる。

And we, of course, need to import even that right over here.

そしてもちろん、その権利さえもこちらに輸入する必要がある。

And then this return type will be the same for getRandom number trivia.

そして、この戻り値の型はgetRandom number triviaでも同じになる。

We will cover this in greater detail later on, how to actually work with this either type.