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.

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.

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.

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.

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

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

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

So we have getit, which is the service locator.

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.

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.

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.

We have flutter test.

This was here even before I think by default.

And then we have Mockito for creating mocks.

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.

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?

Well, of course, with NumberTrivia entities.

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

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

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.

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.

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.

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

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

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

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.

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.

And let's import Equatable here.

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

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

With Equatable, this is completely changed.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

And inside of here, we will have an abstract class, 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.

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

So getConcreteNumberTrivia, int number.

If I could write number.

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

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.

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

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.

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

But for now, just know that this function, this method, will return either a failure, which is the left side, or number trivia, which is the right side.

And this way, we do not have to deal with catching exceptions anywhere else in the app than in the repository, which will convert the exceptions into failures.

And let's use the nifty little extension for VS Code to fix import, so they will be in the relative manner.