Name: Flutter TDD クリーン・アーキテクチャ・コース [1] - 解説とプロジェクト構成 (Flutter TDD Clean Architecture Course [1] – Explanation & Project Structure)
Uploaded: 2024-06-12T18:17:52.000Z
Duration: 24 min 36 s

Keeping your code clean and tested are the two most important development practices.

コードをクリーンに保つこととテストすることは、最も重要な2つの開発プラクティスである。

基礎受動態

In Flutter, this is even more true than with other frameworks, because on one hand, it's nice to hack a quick app together, on the other hand, larger projects start falling apart when you mix the business logic everywhere, which is so simple to do with Flutter, because even the UI is written in the same programming language in which you write the actual logic.

Flutterでは、これは他のフレームワークよりもさらに真実だ。というのも、手早くアプリをハックするのはいいことだが、一方で、ビジネスロジックをあちこちに混在させると、大きなプロジェクトはバラバラになり始めるからだ。

程度の副詞

Even state patterns like block are not sufficient in themselves to allow for easily extensible codebase, and this is where we can employ clean architecture and test-driven development.

ブロックのようなステート・パターンでも、コードベースを簡単に拡張できるようにするには、それだけでは不十分である。

As proposed by our friendly Uncle Bob, Robert Cecil Martin, we should all strive to separate our code into independent layers, and that's precisely what you are going to learn how to do in Flutter in this course.

私たちのフレンドリーなボブおじさん、ロバート・セシル・マーティンが提唱したように、私たちは皆、コードを独立したレイヤーに分離するよう努力すべきだ。

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 and learn about clean architecture in Flutter.

コーディングスキルを伸ばしたい人、Flutterのクリーンアーキテクチャについて学びたい人は、ぜひ購読してベルを鳴らしてください。

Let's start off with the completely finished app, which you will have built by the end of this is actually a numbers API, which provides some nice trivia about numbers.

まずは完全に完成したアプリから始めよう。このアプリが完成するころには、数字に関する豆知識を提供する数字APIが出来上がっているはずだ。

So we can input a number here, for example, 1, 2, 3, and then search for the trivia.

例えば、1、2、3といったように、ここに数字を入力し、トリビアを検索することができる。

Let's search for yet another number, for example, 42, right?

さらに別の数字、例えば42を検索してみようか？

そして、ランダムなトリビアを得ることもできる。

これもAPIのエンドポイントだ。

And then also this app will cache the gotten number trivia from the API so that if we should not have internet connection, so if we enable airplane mode here and come back to the app and get random trivia, it's not going to get us any new trivia, it's just going to display the lastly gotten cached trivia.

そして、このアプリはAPIから取得したトリビアをキャッシュするので、インターネットに接続できない場合、機内モードを有効にしてアプリに戻ってランダムなトリビアを取得すると、新しいトリビアは取得されず、最後にキャッシュされたトリビアが表示されます。

Of course, once we enable internet, we'll be able to again get new trivia just like before.

もちろん、インターネットが使えるようになれば、また以前のように新しいトリビアを手に入れることができる。

This app has all of the core components, which you will be working with in your own apps on day-to-day basis, such as getting data from API, local cache, error handling.

このアプリには、APIからのデータ取得、ローカル・キャッシュ、エラー処理など、日常的に自分のアプリで扱うことになるコア・コンポーネントがすべて含まれている。

For example, if we input ABC with a keyboard, you can do that.

例えば、キーボードでABCと入力する。

So input that, it says invalid input, the number must be a positive integer or zero.

入力すると、無効な入力です、数値は正の整数かゼロでなければなりません、と表示される。

It has like input validation and all that good stuff, which you should have in production apps.

入力バリデーションなど、本番アプリケーションで必要なものがすべて備わっている。

And as for state management, we're going to use block, but you do not have to use block because as you will see later on in this course, as we progress, it will become apparent that the state management which you choose is really almost inconsequential because everything will be handled in different layers.

というのも、このコースの後半に進むにつれて、どのステート・マネージメントを選択するかはほとんど重要でないことがわかってくるからだ。

So the bottom line is do not worry if you do not want to use block in your apps, you do not have to.

要するに、アプリでブロックを使いたくなければ、使う必要はないということだ。

Clean architecture works with any kind of state management pattern, even something like simple change notifier with a provider will be just fine.

クリーン・アーキテクチャーは、どのようなステート管理パターンでも機能する。プロバイダーを使った単純な変更通知器のようなものでも問題ないだろう。

And be sure to check out the written tutorial from the link in the description if you want to really go through this at your own pace, because this first part will be more about theory behind clean architecture, because we cannot progress forward in this course without first understanding the core concepts of clean architecture and why it's actually useful and why it does things the way it does them.

この最初のパートでは、クリーンアーキテクチャの背後にある理論についてより詳しく説明します。なぜなら、クリーンアーキテクチャの中核となる概念と、なぜそれが実際に有用なのか、なぜそのようにするのかを理解することなしに、このコースを進めることはできないからです。

And in the written post accompanying this first part, you have all of that available and you can go through it at your own pace.

そして、この最初の部分に付随する記事には、そのすべてが掲載されており、自分のペースで読み進めることができる。

So let's first take a look at the clean architecture as it was proposed by Uncle Bob.

ではまず、ボブおじさんが提案したクリーンなアーキテクチャを見てみよう。

So it looks something like this and really it doesn't tell us much when it comes to Flutter because like what is a controller, what is presenter, gateway, what is all of that, it just spits out a bunch of abstractions in our face and all in all it's a bit abstract, pun intended.

というのも、コントローラとは何か、プレゼンターとは何か、ゲートウェイとは何か。

Also, while the essence of clean architecture remains the same for every framework, the devil definitely lies in the details and we will have to adapt this general clean architecture to Flutter.

また、クリーン・アーキテクチャの本質はどのフレームワークでも変わらないが、悪魔は間違いなく細部に潜んでおり、この一般的なクリーン・アーキテクチャをFlutterに適応させなければならない。

So lo and behold, because now I will introduce to you the Resocoder's Flutter clean architecture proposal, yes it's an official thing now, which will demonstrate something, should I say more important than just some dependency flow and the onion, it will show you the data and call flow.

ResocoderのFlutterクリーン・アーキテクチャの提案を紹介する。

It may seem like there's a lot to comprehend here but do not worry, we are going to get through this slowly one by one.

理解することがたくさんあるように見えるかもしれないが、心配しないでほしい。

So the core thing here is that the whole app or should I say every core feature of an app, like for example getting number trivia, will be divided into three parts, three layers, presentation, domain and data.

ここで核となるのは、アプリ全体、あるいはアプリのすべての核となる機能、例えば数字の豆知識を得るような機能を、3つの部分、3つのレイヤー、プレゼンテーション、ドメイン、データに分けるということだ。

And actually the app we are building, this number trivia app, will have only one feature because it's a simple app, the only thing we do here is to get number trivia.

というのも、このアプリはシンプルなアプリで、私たちがここですることは、数字の豆知識を得ることだけだからです。

So we'll have only one such division into folders.

だから、このようなフォルダ分けは1つしかない。

So let's actually create these presentation, domain and data folders right now.

それでは実際に、プレゼンテーション、ドメイン、データの各フォルダを作成してみよう。

So let's open up VS Code, we are starting off with a completely new project here and I will enlarge this so you can see the folders even better.

それではVS Codeを開いて、まったく新しいプロジェクトから始めましょう。フォルダがよく見えるように拡大しておきます。

So inside the lib folder we are going to start off with creating a features folder because every feature as I said will have its own folder which will be divided into presentation, domain and data.

libフォルダーの中にfeaturesフォルダーを作るところから始めましょう。

So let's just create the folders and then I will explain everything more in depth.

では、フォルダーを作成してから、さらに詳しく説明しよう。

So the feature name will be simply number trivia.

というわけで、特集名は単に数字のトリビアとなる。

You can have feature like login or registration or something like that, you can have feature settings and so on if you have those things in your app, we have just one screen number trivia and that's it.

ログインや登録などの機能、機能の設定など、アプリの中にそういったものがあれば、私たちはただ1つのスクリーンに数字のトリビアを表示するだけです。

In here we want to create domain, then another folder will be data and the final one will be presentation.

ここでは、ドメインを作成し、別のフォルダをデータ、最後のフォルダをプレゼンテーションとする。

And with this we have the basic structure, the most high-level structure of our app created.

これで、アプリの基本構造、最もハイレベルな構造ができた。

Of course just having features is not enough because what if for example you have something which can be used across multiple features.

もちろん、機能があるだけでは十分ではない。例えば、複数の機能にまたがって使用できるものがあるとしたらどうだろう。

Let's just say that you have also settings feature and even over you want to do input validation.

例えば、設定機能があり、さらに入力検証を行いたいとします。

Well input validation for example just checking if the inputted text doesn't contain any numbers that's not really feature specific, it can be shared across number trivia, settings, whatever.

例えば、入力されたテキストに数字が含まれていないかどうかをチェックするような入力バリデーションは、特定の機能に特化したものではない。

That kind of functionality will go into the core folder.

そのような機能はコアフォルダーに入るだろう。

All right now that we have the basic folder structure let's continue on with this awesome diagram.

さて、基本的なフォルダー構造がわかったところで、この素晴らしいダイアグラムを続けよう。

Let's take a closer look at the presentation layer which is actually what you are already used to in flutter if you've done any kind of a flutter development before.

プレゼンテーション・レイヤーについて詳しく見てみよう。フラッターで開発したことがある人なら、すでに慣れていることだろう。

So presentation is comprised of widgets so this is where all of the pages live for example number trivia page and this is also where you will have your own custom widgets and then it also has something called presentation logic holders which is either a block, a change notifier or really anything which you would classify as state management.

プレゼンテーションはウィジェットで構成されているので、例えばナンバー・トリビアのページなど、すべてのページがここにあり、独自のカスタムウィジェットもここにある。また、プレゼンテーション・ロジック・ホルダーと呼ばれるものがあり、ブロックや変更通知機能など、状態管理に分類されるものがある。

You can even go the good old stateful widget route but I would really recommend you to at least go for change notifier but I really think that block is the best state management option for flutter out there but really presentation logic holders they're not all that important which you choose.

古き良きステートフルウィジェットを使うこともできるが、少なくとも変更通知機能を使うことをお勧めする。

We are going to choose block for this app and as opposed to what you may be used to these presentation logic holders so block or change notifier will really not do much by themselves.

このアプリではブロックを選択するつもりだが、あなたがプレゼンテーション・ロジック・ホルダーに慣れているのとは対照的に、ブロックや変更通知機能はそれ自体ではあまり役に立たない。

They will only delegate all of their work down to use cases to the domain layer and so on.

彼らは、ユースケースに至るまでのすべての作業をドメインレイヤーなどに委ねるだけだ。

Blocks or change notifiers will be really lean classes.

ブロックや変更通知は、本当に無駄のないクラスになるだろう。

彼らは多くの論理を持たないだろう。

At most you will do some really basic input validation inside of them and that's it.

せいぜい、その中で本当に基本的な入力検証を行うだけだ。

Everything else will be delegated to the next layer which are use cases or the domain layer.

それ以外のことは、ユースケースやドメインレイヤーといった次のレイヤーに委ねられる。

Before we continue with the next layer let's just jump into VS Code and let's create the structure of the presentation folder right now so we're going to create new folder under that.

次のレイヤーに進む前に、VS Codeに飛び込んでプレゼンテーション・フォルダーの構造を作りましょう。

ブロックと呼ばれるようになる

Again you can use anything you want and then pages and finally widgets which will be just widgets which we do not want to have directly inside the page because it would just clutter up the UI code.

ページと、最後にウィジェットがあるが、これはページ内に直接ウィジェットを置きたくない。

The next layer we are going to take a look at is the domain layer.

次に見ていくのはドメイン層だ。

As you can see in this call flow arrow the call flow will happen from the upward layer so presentation down so this presentation logic holder for example a block will delegate its work and call use cases which are from the domain layer.

このコールフロー矢印を見ればわかるように、コールフローは上位レイヤーから起こるので、プレゼンテーション・ロジック・ホルダー、たとえばブロックはその作業を委譲し、ドメイン・レイヤーのユースケースを呼び出す。

では、実際にドメインレイヤーとは何なのか？

This is the inner layer which should not be susceptible to the whims of changing data sources or porting our app to angular dart.

これは、データソースを変更したり、アプリをangular dartに移植したりする際に、気まぐれな影響を受けてはならない内部レイヤーである。

It should be really platform independent and actually independent of anything else inside the app.

プラットフォームに依存せず、アプリ内の他のものにも依存しないものでなければならない。

It will contain only the core business logic which will be executed inside use cases and then also business objects which we are going to call entities and by the way use cases are classes which encapsulate all the business logic of a particular use case of the app so for example we will have use cases for getting concrete number trivia right here which will be executed whenever we press the search button here so this is get those will be two classes get concrete number trivia and get random number trivia.

ユースケースは、アプリの特定のユースケースのすべてのビジネスロジックをカプセル化したクラスである。例えば、具体的な数字のトリビアを取得するためのユースケースがここにあり、検索ボタンを押すたびに実行される。

Of course in our app we will not have a lot of business logic and even the entity which will hold the number trivia actually they are gonna be pretty lean classes because we are not doing much in this example app but in your own projects when you are building something more substantial the domain layer is where the bulk of the code will be located and if you've been listening to me carefully I've said that the domain layer should be completely independent of every other layer.

もちろん、私たちのアプリではビジネス・ロジックは多くありませんし、数字のトリビアを保持するエンティティでさえ、実際にはかなり無駄のないクラスになっています。

Well I know that you probably cannot tell much just from this diagram but it seems that the domain layer is independent of the presentation layer but here it gets kind of fancy looking because the repository is seemingly inside the domain layer and also in the data layer right so what's up with that half of the repository is domain and half is in data no that's not how it is.

この図だけではよくわからないと思いますが、ドメインレイヤーはプレゼンテーションレイヤーから独立しているように見えますが、ここでは、リポジトリが一見ドメインレイヤーの中にあり、データレイヤーの中にもあるので、ちょっと派手な見た目になります。

The repository class is on the edge between data and domain layers and to allow for the independence of the domain layer we are going to do something called dependency inversion.

リポジトリ・クラスはデータレイヤーとドメインレイヤーの端にあり、ドメインレイヤーの独立性を確保するために、依存関係の逆転と呼ばれることを行う。

では、依存関係の逆転とは何か？

I know that you may be getting some goosebumps because they're just scary words but dependency inversion is in essence very very simple and straightforward it's just a fancy way of saying that we create an abstract class repository which will define a contract of what the repository must do so for example in our app we will have a repository which must provide us with random trivia and concrete number trivia those are the two things which the repository just must do and that goes into the domain layer.

怖い言葉なので鳥肌が立つかもしれないが、依存関係の逆転とは、要するにとてもシンプルでわかりやすいもので、抽象的なクラスのリポジトリを作成し、リポジトリが何をしなければならないかという契約を定義することだ。

 The domain layer does not care how the number trivia will be gotten it just cares that it will be gotten right this is all possible with an interface or because dart does not support interfaces we have to use abstract classes and then the other side of the coin or in this case repository is inside the data layer the data layer will define how the data will be gotten and managed and all of that we're get to that in just a short while but the important thing is that the repository in the data layer will implement the abstract class so it will have to conform to the so-called contract so that domain can really not care what's going on behind the scenes it just knows what kind of data it will always receive from the repository in this case it will be the number trivia so let's create the folder structure shall we inside VS Code the domain layer will have three subfolders entities which will be the number trivia entity which will simply hold the text of the trivia and the number of the number trivia then we will have also another subfolder repositories this is where the contract or the abstract class of repository will go and then also the last folder is use cases so use cases are get concrete number trivia and as you can see there was some server failure now so error handling works correctly but I don't know why there was a server failure but anyway now we have 42 so this is the concrete or get concrete use case and we also have the random use case and let's now move on to the data layer as you already know it contains repositories which implement the abstract classes from the domain so that they will have to just fulfill the contract defined by domain and then it also contains remote data sources local data sources any kind of data sources obviously go into the data layer usually you have one data source for getting remote data from the API and then you also have another one for getting local data in our case we will use shared preferences to cache the data locally and local data sources are also where you would have your for example GPS location code and all of that good stuff data sources do not have to just operate with databases they can also operate with the underlying platform or device and the repository is the brains of the data layer because this repository will decide when to cache, what to cache, when to get data from the remote data source, when to get data from local data source so for example if there is no internet connection we definitely want to get data the cached data from local data sources and you may notice that repositories output entities which kind of makes sense and again entity is just the number and the text of the number trivia really simple in our case but data sources do not output entities they deal with something called models and this nomenclature is really not all that important it doesn't matter how you call these things it's just that you know what those names mean and the reason behind having models is that transforming raw data which is for example JSON requires some conversion logic because we cannot work with JSON in our app we have to Dart objects but now let's think about this we definitely do not want to put our JSON conversion logic so to JSON and from JSON as we are all used to for example from built value or JSON serializable we do not want to put those conversion methods into entities and why is that well entities should be completely platform and data layer independent so for example if we switch from JSON to XML or to some binary data craziness we do not want to change the domain layer at all we only want to change the data layer when something data related changes but the domain should remain untouched therefore these models will be simple classes which extend entities and add some functionality on top of them and because they are subclasses of entities we can then simply cast them into entities and the repository will output the entity which does not have any additional functionality or fields added on top of it in the number trivia app since we do not have anything really difficult to do models will have only to JSON and from JSON methods but if you are storing something locally in an sqli database and for some reason you have to have the id inside the database stored inside the model you can also add some custom fields to the model not just methods in our app the remote data source will perform an HTTP get request to numbers API which is simply numbersapi.com and all of these links and all of that which I am explaining here is also available from the written tutorial so definitely check that out but here is numbersapi.com this is the API we will be using so as you can see we can get random trivia right this is what we are doing from within the app so this is what the remote data source will do it will perform get requests and then we have also local data source which will simply cache data using the shared preferences package and then these two data sources will be just a simple thing it will check whether or not the user is connected to the internet if there is internet connection it will always prefer to get fresh data from the remote data source if there is no internet it will get the cached data and it will also have a simple caching logic which is that we always cache everything as soon as it's gotten from the API so that if there is no internet connection it will always return the cached data the last cached data to be precise all right so let's now create the folder structure even for the data layer because the things below are not actually a part of our app these are some external things we do not care about them it's not a part of our code base and the data layer will be comprised of data sources, models and finally implementations of repositories so the repositories folder in data will hold implementations and the repositories folder in domain will hold the abstract classes or interfaces which are the contracts which the repositories implemented in data must fulfill and again this abstraction is necessary so that the domain layer can be completely independent of every other layer all right so this first part of this test driven development clean architecture flutter course was really theory heavy that's because something like clean architecture requires a lot of explanation because after all you cannot just start building a house without first planning how the house will look like you have to have at least some basic structure some basic drawings in place and these drawings were laid down in this first part so in the next parts we are going to actually get coding and doing test driven development and we are going to start off with this domain layer so if you do not want to miss that tutorial and more other tutorials like this definitely subscribe to this channel and also join the notification squad by hitting the bell button to make sure you grow your flutter skills because here on resocoder i am determined to provide you with the best app development tutorials and resources out there also make sure to check out the written tutorial available from the link in the video description to go through all of this at your own pace you will highly benefit from reading the written tutorial if you want to learn the most about clean architecture which i'm sure you want to do if this video helped you with clearing the concepts of clean architecture give it a like and also share it with our developers who will surely benefit from this too follow me on instagram i go under the name resocoder everywhere leave a comment if you have anything to say any suggestions or questions stay tuned for the next part in which we are going to finally start writing code doing test-driven development and see you in the next video you

ドメインレイヤーは、ナンバー・トリビアがどのように取得されるかを気にすることはありません。そのため、ドメインは裏で何が起こっているかなんて気にする必要はない。ただ、リポジトリからどのようなデータを常に受け取ることができるかを知っているだけだ。最後のフォルダはユースケースで、ユースケースは具体的な数字トリビアを取得するものである。データレイヤーには、ドメインの抽象クラスを実装するリポジトリがあり、ドメインが定義したコントラクトを満たす必要がある。ローカル・データ・ソースは、例えばGPSのロケーション・コード