Extract domain out

[lodenrogue]

Interesting project. Not sure why you need all the database/passwords storage stuff. Couldn't this just be an application that runs in the browser without requiring users to sign up or log in?

I'd highly recommend extracting the domain (typing training) out of this project and bringing it into your front end framework of choice instead of mixing view and domain in one project. That way they could both evolve independently of each other.

[utsav0]

Those login signup stuff are only because I wanted to learn about them.

But yeah, we definitely can make it more simpler by removing all that stuff and making it a simple two pages website ( practice and result) .

And can you please explain what you mean by extracting the domain?

[lodenrogue]

As the application stands you really have 3 layers.

1. Your view - This is your presentation layer which is the web pages and the associated javascript
2. Your domain - This is the logic that relates to typing stuff
3. Storage - This is the database layer

The domain in this case is typing training. Things like exercises, score, results, etc. All of these objects and their associated behaviors are your domain. This layer should be 100% agnostic to your view and your storage mechanism. Ideally, it would be a standalone repository that only does typing training stuff.

You can then have another repository for the view and another one for the back end (users, storing results, etc).

You want to keep all these layers separate and agnostic to the other layers so that you can switch them out whenever you want to. React is popular now but it won't be forever. When you change front end frameworks that doesn't mean you should also touch the domain or database code. Same goes for the storage layer.

There's two ways to go about this. You can either make this a front end only application where your domain is written in some front end language like Javascript and you bring it in as dependency.

Or you could make the domain stuff happen in the back end where you can use a language like python or Java and bring that in as a dependency for your back end webservice. You'll have a front end that communicates with this webservice and the backend web service will handle the database stuff. This is similar to what you have now but the domain is extracted into it's own repository and doesn't know about the front end or back end.

[utsav0]

So, what I understand from it is,

We can create three repos and add in them view, domain and storage.

And we can write the complete logic in JavaScript as of now because it's almost in JavaScript already.

But I'm a bit confused between view and domain.

Is it like, view is the design and layout while domain is the logic?

[lodenrogue]

The main idea is to isolate these three layers so they can evolve and be swapped out independently of each other. This is not specific to your application; this is just good architectural sense.

Each of these layers have layers of their own. Your view has 3 basic layers. The presentation layer, the view's logic layer, and the layer that interacts with external services*.

Some patterns that nicely separate out these layers are MVC, MVP, and MVVM. React is problematic because, as it's normally used, it mixes your presentation and view logic layers. But I won't get into that for now.

*external services here can be external APIs, your domain as a library, etc.

The domain is different. The architecture for the domain should represent the actual domain. Instead of having presentation, view logic, and a layer that interacts with external services your domain is architected in such a way that it reflects the actual domain. You have objects that represent actual objects in your domain. For example, a User, an Exercise, a Score, a Result. These objects interact with each other to solve domain specific problems like taking a typing test, or completing an exercise, etc.

The view layer could interact with the domain through that third layer that interacts with external services. Or, for example, it could talk to a back end.

The information here is just the tip of the iceberg when it comes to architecture. There is more regarding how to actually separate the concerns within a layer, abstracting implementation details behind interfaces, inversion of control, etc.

[utsav0]

Were you talking about something like this?

[lodenrogue]

Yeah that's starting to look much better