And in this video, I'm going to show you a pattern or a rule that you can follow to every time create clean and maintainable software using the repository pattern.

このビデオでは、リポジトリー・パターンを使って、クリーンで保守性の高いソフトウェアを作るためのパターンやルールを紹介する。

So before we go and look into what it is, let me show you this example application without using the repository pattern.

では、それが何なのかを調べる前に、リポジトリ・パターンを使わないアプリケーションの例をお見せしよう。

And if this sounds familiar, the way that I'm structuring this application, then I think that this video is going to be really important for you.

そして、もしこれが聞き覚えのあるものだとしたら、私がこのアプリケーションをどのように構成しているのか、このビデオはあなたにとって本当に重要なものになると思う。

So this is pretty simple.

だから、これはとてもシンプルだ。

We have a user model.

我々はユーザーモデルを持っている。

You could imagine this is you're starting users on your database.

これは、データベースでユーザーを開始する場合を想像してほしい。

And here we start actually pretty well because we start with an application struct that we can start injecting dependencies.

というのも、依存関係の注入を開始できるアプリケーション構造体から始めるからだ。

We'll go over that and how dependency injection is also used in the repository pattern, but it's actually different.

依存性注入はリポジトリパターンでも使われるが、実は違う。

It's not the same thing.

同じことではないんだ。

So pretty simple here on the main, we're just initializing this database.

メインでは、データベースを初期化しているだけだ。

It doesn't mean it doesn't matter what it is.

それが何であろうと関係ないという意味ではない。

And here we initialize our application.

そして、ここでアプリケーションを初期化する。

So this is how I usually structure APIs or any kind of project that has global state that I want to pass.

だから私は通常、APIやグローバル・ステートを渡すプロジェクトでは、このように構成している。

So here we have an endpoint which creates a user.

ここでは、ユーザーを作成するエンドポイントがある。

So let's take a look at it.

それでは見てみよう。

This is the payload it receives.

これがペイロードである。

We are just decoding these requests.

私たちはこれらの要求を解読しているだけだ。

And then here we are creating a user on the database.

そして、データベース上にユーザーを作成する。

So here is clearly, we are clearly using SQL to inject, to insert the user in the database.

つまり、ここでは明らかに、SQLを使ってデータベースにユーザーを挿入しているのだ。

So we know the table name, we know that we're using SQL.

テーブル名もSQLを使っていることもわかっている。

And then here is some business logic.

そしてビジネス・ロジックだ。

We are sending a welcome email to the user.

ユーザーにウェルカムメールを送信しています。

So here we are actually doing something good because we are abstracting the malware into its own package and then we are sending the email.

マルウェアを独自のパッケージに抽象化し、メールを送信しているのだ。

So this is the application.

これがアプリケーションだ。

It's pretty simple, but you can start to see the problems.

とても単純なことだが、問題が見えてくる。

The first is that there is a big tight coupling between the database and the service.

第一は、データベースとサービスの間に大きな緊密な結合があることだ。

So if you think about the three layers that we might have, the transport, the service, and the storage, this is all of them combined here.

つまり、トランスポート、サービス、ストレージという3つのレイヤーを考えてみると、ここにあるのはそれらすべてを合わせたものだ。

So this is the transport layer, which is HTTP.

これがトランスポート層で、HTTPである。

This is the service because this is the business logic.

これがサービスであり、これがビジネス・ロジックだからだ。

So we're sending emails and we're getting the user.

つまり、メールを送信し、ユーザーを獲得しているのだ。

And we might even do some other business logic here.

また、ここで他のビジネス・ロジックを実行することもある。

So this is clearly a service with data access embedded into it.

つまり、これは明らかにデータアクセスが組み込まれたサービスなのだ。

And why is this bad?

なぜ悪いのか？

Firstly, it basically fails all of the good practices in software engineering.

まず第一に、基本的にソフトウェア・エンジニアリングにおけるグッド・プラクティスのすべてに失敗している。

And then it also is untestable.

そして、それはまたテスト不可能でもある。

So I'm not going to even try to test this because we need to mock the whole SQL driver here.

SQLドライバー全体をモックする必要があるからだ。

We need to mock the malware as well.

私たちはマルウェアもあざ笑う必要がある。

So you can see that this does not obey the single responsibility principle.

つまり、これは単一責任の原則に従っていないことがわかるだろう。

So this does a lot of things here.

だから、これはいろいろなことをやってくれる。

So let's take a look at how the repository pattern can actually help us.

それでは、リポジトリ・パターンが実際にどのように役立つかを見てみよう。

So the repository pattern, and basically in a few words, this is a way to organize and abstract data access logic from the business logic or the application logic.

つまりリポジトリ・パターンは、基本的に一言で言えば、ビジネス・ロジックやアプリケーション・ロジックからデータ・アクセス・ロジックを整理し、抽象化する方法である。

Now let's take a look at how we could leverage this.

では、これをどのように活用できるか見てみよう。

So if we have, this is usually application, even if you're building an API or something else, you're going to have layers.

つまり、これは通常アプリケーションであり、APIなどを構築する場合でも、レイヤーを持つことになる。

Or at least you should start to have layers because this adds a separation of concerns and a single responsibility for each layer.

というのも、レイヤーを分けることで、懸念事項の分離と、各レイヤーに対する単一の責任が追加されるからだ。

So let's go back to our transport layer, which is our HTTP.

では、HTTPであるトランスポート・レイヤーに戻ろう。

You can see here it's on the main.

メインにあるのがわかるだろう。

That is fine for now.

今はそれでいい。

But once we get to the service, we got the service and the storage all mixed up together as we have seen already.

しかし、サービスに入ると、すでに見たように、サービスとストレージがごっちゃになってしまう。

And we have a storage because most applications require a state.

そして、ほとんどのアプリケーションが状態を必要とするため、我々はストレージを持っている。

Either you're starting on a database or you're starting on just RAM.

データベースで始めるか、RAMだけで始めるかだ。

It doesn't matter.

そんなことはどうでもいい。

It's still a storage.

まだ倉庫だ。

Or even if you're just starting on disk files on your server or something like that, it's still state that you're usually storing.

あるいは、サーバー上のディスクファイルから始めている場合などでも、通常保存している状態であることに変わりはない。

Most applications use states.

ほとんどのアプリケーションはステートを使用する。

Now this here, if we apply these layers, we're automatically going to get separation of concerns, single responsibility.

このレイヤーを適用すれば、自動的に懸念事項の分離と単一責任が実現する。

We're going to encapsulate the data access and we're going to make our code testable.

データ・アクセスをカプセル化し、コードをテスト可能にする。

And all of this is tied to dependency injection.

そして、これらすべてが依存性注入に結びついている。

And I'm going to show you how you can implement the repository pattern without it and why the repository pattern is not the same as dependency injection.

そして、リポジトリ・パターンを使わずに実装する方法と、なぜリポジトリ・パターンが依存性注入と同じではないのかを紹介するつもりだ。

So let's go back to the code and refactor step-by-step into a better application.

それではコードに戻り、より良いアプリケーションへと段階的にリファクタリングしていこう。

So going back to the editor, what I have quickly done here is that I have just created this service.go file.

エディターに戻って、私がここで素早くやったことは、このservice.goファイルを作成したことだ。

And what we're going to do is that we're going to go step-by-step into these layers until we have the repository pattern implemented.

そして、これからやることは、リポジトリ・パターンを実装するまで、これらのレイヤーを段階的に進めていくことだ。

So what we want to do is make what we have drawn there on a diagram.

そこで私たちがしたいのは、そこに描いたものを図にすることだ。

The first step is to create the user service.

最初のステップは、ユーザーサービスを作成することです。

Now, there is some problems here still.

さて、ここにはまだいくつかの問題がある。

And the first one is here.

そして第1号はこちら。

What we are passing is not an interface.

渡しているのはインターフェイスではない。

It's not something abstract.

抽象的なものではない。

It is an implementation.

それは実装である。

And this is the first issue that we're going to solve next.

そして、これが次に解決する最初の問題だ。

But first, we're getting a good start.

その前に、いいスタートを切ることができた。

We have a new user service that we have here, a constructor.

ここに新しいユーザー・サービス、コンストラクターがある。

All fine.

すべて順調だ。

This is optional, of course, if you want to just initialize it without the constructor, that's fine.

もちろん、コンストラクターなしで初期化したいのであれば、これはオプションだ。

But here we have another method.

しかし、ここには別の方法がある。

For example, getOneById.

例えば、getOneById。

But here is our user create method that we had before.

しかし、ここに以前あったユーザー作成メソッドがある。

So we are still inserting the user into the database.

つまり、まだユーザーをデータベースに挿入しているのだ。

So this is still SQL.

つまり、これはまだSQLなのだ。

And then here is the actual business logic using the mailer.

そして、これがメーラーを使った実際のビジネス・ロジックである。

So that is fine, but we can do some improvements here.

それはそれでいいのだが、ここでいくつか改善できることがある。

At least two improvements I see.

少なくとも2つの改善が見られる。

And the first improvement is to actually move this data access logic out of the service layer, because this is not the place for it.

最初の改善は、データ・アクセス・ロジックをサービス・レイヤーの外に移すことだ。

So we can just remove this for now.

だから、今はこれを削除すればいい。

And let's keep the mailer here, because this is what we need.

メーラーはここに置いておこう。

And along the way, what we're going to have is that we're going to have a function called createUsers.

その過程で、createUsersという関数を用意する。

I have my cursor auto-completion enabled, but let's ignore that for now.

カーソルのオートコンプリートを有効にしているが、今は無視しよう。

And then the second improvement is that we can just come here and we can see that we are initializing the mailer here.

そして2つ目の改善点は、ここに来てメーラーを初期化していることを確認できることだ。

So every time we create a user, we're initializing the mailer.

そのため、ユーザーを作成するたびにメーラーを初期化している。

We're doing something good, which is we are using a mailer.

メーラーを使うという良いことをしているんだ。

Actually, it's not good because we're using the implementation, but how can we solve this?

実際、実装を使用しているのだから仕方がないのだが、これを解決するにはどうしたらいいのだろうか？

Check it out here on the mailer.

このメーラーで確認してほしい。

And this is a hint how we're going to do the structure for the storage as well.

そしてこれは、ストレージの構造をどうするかというヒントでもある。

So here we have a mailer.go.

というわけで、ここにメーラー.goがある。

And here we have a client interface.

そしてここにクライアント・インターフェイスがある。

So anyone who implements this client interface is going to be an implementation of a mailer.

つまり、このクライアント・インターフェースを実装する人は誰でも、メーラーを実装することになる。

So here I have a mail trap.

というわけで、ここにメールトラップがある。

This is a service that uses to send emails.

これは電子メールを送信するためのサービスである。

And this is an implementation of that mailer.

そして、これはそのメーラーの実装である。

You can see here the send code.

送信コードをご覧ください。

All this does is that communicates with the mail trap API and sends an email.

これは、メール・トラップAPIと通信してメールを送信するだけである。

So instead of passing here the implementation, let's pass in a mailer, which is going to be a mailer.client.

そこで、ここに実装を渡す代わりに、メーラーを渡そう。メーラーにはmailer.clientを渡そう。

And here is an interface which we can just come here and let's do mailer.send and pass in our arguments as we did before.

ここにインターフェイスがあるので、ここに来てmailer.sendを実行し、前と同じように引数を渡すことができる。

So this is one step cleaner because we can choose which mailer implementation we want to pass.

つまり、どのメーラーの実装を渡したいかを選択できるので、この方が一段階すっきりしている。

So let's come here to the main.

それではメインに参りましょう。

Let's first create our service.

まずはサービスを作ってみよう。

There we go.

これでよし。

And we also need to update the constructor like this to pass in the mailer interface.

また、メーラー・インターフェースを渡すために、コンストラクタをこのように更新する必要がある。

Now we need to pass in a mailer.

あとはメーラーを通すだけだ。

So let me just initialize this dependency as well.

では、この依存関係も初期化しておこう。

There we go.

これでよし。

Now what we have just seen before is actually something I want to show you.

さて、先ほど見たものは、実は皆さんにお見せしたいものだ。

This here is this here actually the mailer is dependency injection.

これはこれ、実はメーラーは依存性注入だ。

So we have an abstraction and we are injecting any dependency we want at runtime.

つまり、私たちは抽象化されたものを持っていて、実行時に好きな依存関係を注入しているのだ。

This database here is not dependency injection.

このデータベースは依存性注入ではない。

This is an implementation.

これは実装である。

So you can see why the repository pattern is different than dependency injection by this example right here.

この例で、なぜリポジトリ・パターンが依存性注入と違うのかがわかるだろう。

This is a clear distinction between those two.

これはこの2つを明確に区別するものだ。

Now the final step is coming here to storage.

さて、最後のステップはここに来ての保管である。

I have just created this folder and I'm going to call a file called store.go.

このフォルダを作成し、store.goというファイルを呼び出すことにする。

So what is the store.go going to have?

では、『store.go』には何があるのだろうか？

It's going to basically just have an interface for the storage.

基本的にはストレージ用のインターフェイスを持つだけだ。

So let's just call this storage and this is going to be an interface.

では、このストレージをインターフェースと呼ぶことにしよう。

Yeah, just like so.

ああ、そうだね。

Now we need to...

あとは...

And this basically holds the definition or the blueprint for the create user which receives the user and returns an error.

これは基本的に、ユーザーを受け取ってエラーを返すcreate userの定義やブループリントを保持している。

What we need to do is move the user out of the main function.

必要なのは、ユーザーをメインファンクションの外に出すことだ。

And you can see that this structure is going to make us write cleaner codes by default because first thing is that the user does not belong here on the transport layer or the entry point of the application.

この構造によって、デフォルトでよりクリーンなコードが書けるようになることがわかるだろう。

This is a model, a representation of the user on the database.

これはモデルであり、データベース上のユーザーの表現である。

So it doesn't make sense to have it on main.

だからメインに置く意味がない。

You can see how the codes made us change the user to this layer without thinking about it.

コードによって、私たちがいかにユーザーを何も考えずにこのレイヤーに変更させたかがわかるだろう。

So you can see how this creates good practices already.

だから、これがすでに良い習慣を生み出していることがわかるだろう。

Now let's create an implementation of SQL.go.

では、SQL.goの実装を作ってみましょう。

For example, let's create this SQL.go file.

例えば、このSQL.goファイルを作ってみましょう。

And just one thing is that usually I wouldn't separate things like this.

それと、ひとつだけ言えるのは、普通はこんな風に物事を分けたりしない。

I wouldn't create just an SQL.go file to have the whole code here.

私なら、SQL.goファイルだけを作って、ここにコード全体を置くことはしない。

I would create small repositories like the user storage, the newsletter store, the post store.

私は、ユーザー・ストレージ、ニュースレター・ストア、ポスト・ストアのような小さなリポジトリを作ります。

We do this in the backend engineering course pretty well.

バックエンドエンジニアリングコースでは、このことをよくやっている。

This is just to demonstrate you for this video so we can move a little bit quicker.

これは、このビデオのデモンストレーションのためです。

So let's create an actual implementation of an SQL store.

では、実際にSQLストアの実装を作ってみよう。

And let me just create also a constructor.

コンストラクターも作ってみよう。

And then let's have the createUser method, which is basically all of this code here.

そして、createUserメソッドを用意しよう。これは基本的に、ここにあるコードすべてである。

Just this bit, not the email sending, because this is the access to the storage layer using SQL.

メール送信ではなく、この部分だけだ。これはSQLを使ったストレージ層へのアクセスだからだ。

So let's just copy this constructor.

では、このコンストラクタをコピーしてみよう。

Now let's go back to the service and let's remove the database into a storage.

では、サービスに戻ってデータベースをストレージに取り出してみよう。

So you can see that we have storage.storage.

storage.storage.storage.storage.storage.storage.storage.storageがあることがお分かりいただけるだろう。

And what I mentioned to you before is that if you pass this as a user repository, this is going to be even cleaner because they're just passing the parts of the user repository.

前にも言ったが、これをユーザー・リポジトリとして渡すと、ユーザー・リポジトリのパーツを渡すだけなので、さらにすっきりする。

And if for some reason the user service communicated with posts, you could have the posts repo as well.

また、何らかの理由でユーザーサービスが投稿と通信する場合は、投稿のレポも持つことができる。

So this makes it even better to test.

だから、テストするのはもっといい。

But for our example, let's just keep the like we did here.

しかし、この例では、ここでやったようにそのままにしておこう。

So what I have just done is updated the constructor to receive the interface.

つまり、インターフェイスを受け取るためにコンストラクタを更新したのだ。

So we're just receiving interfaces right now.

だから、今はインターフェイスを受信しているだけだ。

And here we can actually delete this method.

そして、このメソッドを削除することができる。

This was one of the ones that we didn't have.

これはなかったもののひとつだ。

And the create, we can actually pass a store.user.

そしてcreateでは、実際にstore.userを渡すことができます。

Usually what you do is create here a new type to have the payload.

通常は、ここでペイロードを持つ新しい型を作成する。

This could be, for example, createUserRequest, which we could actually...

これは例えば、createUserRequestである。

Let's actually do this so we can have an idea of how I would do this.

実際にやってみよう。

You might want to create a user with different parameters.

異なるパラメーターを持つユーザーを作りたいかもしれない。

So this is why I'm doing this.

だからこうしているんだ。

And then what you're going to do is that let's uncomment this.

そして、これからすることは、このコメントを解除することだ。

Let's go to the storage.

倉庫に行こう。

And let's create the user.

そしてユーザーを作成しよう。

And here is the user struct from the storage.

そしてこれが、ストレージにあるユーザー構造である。

Let's handle the error.

エラーに対処しよう。

And I think this is pretty much it.

そして、これがほとんどだと思う。

Let's delete this comment as well.

このコメントも削除しよう。

And so this is pretty much the service.

それで、これがかなりのサービスなんだ。

You can see how cleaner it is and how we have separated the concerns of the older code.

いかにすっきりし、古いコードの懸念事項を分離したかがわかるだろう。

You can see that we just communicate with the storage, which could be anything.

ストレージと通信しているのがわかるだろう。

This could be a MongoDB, could be Redis.

これはMongoDBかもしれないし、Redisかもしれない。

In this case, it's SQL, but you don't have any reference of it here.

この場合、SQLだが、ここにはその参照はない。

And here is the mailer, which we don't even know which mailer it is.

そしてこれがそのメーラーで、どのメーラーなのかもわからない。

And actually, recently I had to switch mailers for one of my projects.

そして実は最近、あるプロジェクトのためにメーラーを変えなければならなかった。

All I needed to do was come to the mailer and create a new implementation for the service.

私がすべきことは、メーラーに来て、そのサービスのための新しい実装を作成することだった。

And that's how easy it is.

それくらい簡単なことなんだ。

I don't need to change any code of the services.

サービスのコードを変更する必要はない。

Now, the last step is tying up everything correctly.

さて、最後のステップは、すべてを正しく結ぶことだ。

We need to go to the main and inject the right dependencies.

メインに行き、正しい依存関係を注入する必要がある。

So we have just created the mailer.

メーラーを作成したところです。

We have here the database.

ここにデータベースがある。

Let me actually comment this as well.

これもコメントさせてください。

And this is the service.

そしてこれがサービスだ。

The service now receives a storage.

これでサービスはストレージを受け取る。

So we need to initialize this storage.

そこで、このストレージを初期化する必要がある。

Let me do here.

ここでやらせてくれ。

Actually, yeah, let's just call this storage for now.

実は、そうなんだ。とりあえず、これをストレージと呼ぶことにしよう。

It's fine.

大丈夫だよ。

And as you can see, we have here the constructor for the SQL storage.