Setup skeleton of authenticating client app

[crocsandcoffee]

📑 What does this PR do?

• I added the first example of a network call with more end-to-end architecture between different modules. This example is the authentication call done to register the client app, before taking them to OAuth for login.

At a high level here is how the changes look:

• Updated the domain module to not depend on data module. IMO it should be independent and only depend on platform agnostic shared utilities such as kotlin-utils. (Open for discussion!)
• Added new module under data for repository implementations that wrap network and persistence. data now has network , persistence and repositories
• domain module now has interfaces for repositories, and a new use case has been added that works directly with the repository interface.
• data.network has been updated to expose the relevant mastodon API for authenticating an application
• data.repositories has a new class that implements the AuthenticationRepository interface, and calls the API in data.network to perform the authentication request, then takes the response client metadata and will store in cache via a data.persistence source (TODO added in PR here)

I would appreciate any thoughts, questions, feedback on the PR about the dependency graph and architecture set here in addition to whatever else. Thanks :slightly_smiling_face:

✅ Checklist

• [ ] My pull request adheres to the code style of this project
• [ ] My code requires changes to the documentation
• [ ] I have updated the documentation as required
• [ ] All the tests have passed

🧪 How can this PR been tested?

🧾 Tasks Remaining: (List of tasks remaining to be implemented)

• What is remaining to be implemented in this PR? Mention a list of them

🖼️ Screenshots (if applicable):

[lotdrops]

Sorry if this was discussed elsewhere, I didn't find it. Are we settled on modularization by layer?
UI needs to be separate from the rest because of KMP, that's for sure. However, I think we could split it by features instead of doing domain/data.
As I understand architecture, we want modules with high cohesion and with low coupling. If we split by layer I think we do not achieve those goals. Also, modularization by feature mimics how we'd split by "teams". Also, I think it used to be common to modularize by layer but now I believe it is mostly done by feature. For example, it is shown in the android architecture page. Fernando Cejas made it popular, but then changed his mind about this because of feedback from the community. I usually follow an approach similar to this. For small/medium apps I don't split features in api/impl, and my module-injector is inside of app.

[crocsandcoffee]

Sorry if this was discussed elsewhere, I didn't find it. Are we settled on modularization by layer? UI needs to be separate from the rest because of KMP, that's for sure. However, I think we could split it by features instead of doing domain/data. As I understand architecture, we want modules with high cohesion and with low coupling. If we split by layer I think we do not achieve those goals. Also, modularization by feature mimics how we'd split by "teams". Also, I think it used to be common to modularize by layer but now I believe it is mostly done by feature. For example, it is shown in the android architecture page. Fernando Cejas made it popular, but then changed his mind about this because of feedback from the community. I usually follow an approach similar to this. For small/medium apps I don't split features in api/impl, and my module-injector is inside of app.

I think what we have in place right now is a mix of both, sort of.

We are doing somewhat feature modules. For example, right now we have ui/timeline, ui/settings, ui/welcome. Each of these feature modules contains the relevant UI/ViewModel/Screen(s)/Navigation. There is also a ui/common for shared UI components etc

We then have an optional domain/use-case layer that sits between these feature modules and data.

Our data layer is also broken up into separate modules: data/network, data/persistence, and data/repository. Here is where it's more by "layer" than by feature.

So we are in a way doing a mix of modules broken down by features and by layer. I'm open to all and any suggestions, changes, etc.

The purpose of this community-led project is to build something fun and useful, but also serve as a community-built example of good architecture, best practices, and bleeding-edge tech.

[lotdrops]

Yes, to this mix is what I refer to. The UI modularization looks good to me, it is with the data and domain layers where I'm not so sure about. At least from a theoretical point of view, what makes more sense to me would be having modules such as feature/timeline, feature/authentication, feature/search, etc. And in those feature modules, I'd have both the domain and the data. Then, some core or common modules to provide with the setup and utils needed. That said, I have used ktor and sqldelight very little, and I'm not sure how manageable it is to split them in modules. Maybe it is not doable and we have to stick with data/network and data/persistence...

[crocsandcoffee]

Yes, to this mix is what I refer to. The UI modularization looks good to me, it is with the data and domain layers where I'm not so sure about. At least from a theoretical point of view, what makes more sense to me would be having modules such as feature/timeline, feature/authentication, feature/search, etc. And in those feature modules, I'd have both the domain and the data. Then, some core or common modules to provide with the setup and utils needed. That said, I have used ktor and sqldelight very little, and I'm not sure how manageable it is to split them in modules. Maybe it is not doable and we have to stick with data/network and data/persistence...

@lotdrops Yup I am in same boat here WRT experience with those two libraries and how all this will come together. Would you mind creating a discussion in the repo and link to your comment here so the community can give opinions/insight etc? For the time being I will continue with this as-is and we can also move things around once things become more clear or after getting more input. Thanks!