Project organization / structure / conventions

[Badabum]

Hi, thanks for creating this project!

I'd like discuss the following things about how it's being built:

1. Project structure.
   Atm, the main sdk project is structured per item type - Exceptions, Models etc. While it one of the ways to go I believe it's more future-proof to structure it per feature.
   Example:
   
   Imo, this improves cohesion in the code - related pieces live together.

2. Naming and conventions
   Since this is an SDK I don't think the need to name things with DTO suffix. As that is mainly used to separate domain entities and public contracts when building services. For example: User -> UserDto.
   In case of this sdk types like Subscriber are part of the domain of SDK.
   Also, imo, removing DTO suffix makes it more readable.

3. RestSharp vs Refit
   There is a tool called Refit that can be used to do http calls to novu instead of RestSharp. As shown here https://www.reddit.com/r/dotnet/comments/11fcxdx/dotnetbenchmark_refit_vs_restsharp/ it has slightly better performance. Also it uses source generators underneath so removes quite a lot boilerplate code which will reduce the overall size of this sdk.

I'll happily contribute to addressing these 3 topics if they make sense for the team. Cheers

[wh1337]

@Badabum, thank you for your insights!

1. I will have to agree, moving to a feature based approach would be better. I was thinking about doing this anyways, so it's good to see I wasn't going down the wrong path. Feel free to make a PR showcasing your idea and I'll review it 🚀

2. Yet another task I was going to do and another point I agree with you on. Feel free to make this a PR as well :)

3. I'll be reviewing Refit and taking a look at Replaced RestSharp with Refit #25 thank you for the PR!

[Badabum]

@wh1337 thx for taking the time to review and reply :) Seem that we found common ground here, closing the issue