GithubHelp home page GithubHelp logo

cryptocurrencyappyt's People

Contributors

philipplackner avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

cryptocurrencyappyt's Issues

My comments on Clean Architecture

Hi there. I really like your videos. I've been practising Clean Architecture for some years, but as you know the implementation is open to interpretation, so I'm always interested in other people's perspective. This issue is just a comment/request for opinion (and not a critic!).

Some points I think could be more aligned with Clean Architecture:

  • Data DTOs: I'd try keep the DTOs pure and anemic, without those toDomainVersion convenience functions. The DTOs change with the API while the domain objects change with domain changes. This mapping could be better contained in a different file to decouple both models, although it is Ok if you are 100% sure there will be no changes.

  • Data repository: I would have kept it synchronous (no suspend, no LiveData, no nothing!). Right now you are coupling your interface to a particular async library (Coroutines). But in Clean Architecture you usually want to postpone these decissions for later. You might want to use RxJava or whatever other library. This choice can be made later in a more external layer (domain or better yet, application). This also makes testing of the data package easier, and makes porting it to a different technology also a lot easier.

  • Domain model: Coin and CoinDetail are two different classes, but in real life CoinDetail is also a Coin, just with extra info, and you are not expressing this relationship in the code.
    I'd have created just a single Coin class with an optional Details member inside, that could be retrieved as needed.
    I like that you have kept them immutable and pure Kotlin. If you were implementing persistence, don't add here all those Room annotations. Create instead a separate persistence model in the data package.

  • Domain "use cases" (actually Domain Services): These two existing use cases could be fused into one single class, a CoinService, with two methods. Also notice that there is no significant domain logic whatsoever in these use cases, so for this particular sample app you could get rid of this layer and go straight for an application layer (or even the ViewModels) to wrap your repository calls into async constructs (although in your case they were already async) and handle exceptions. The domain layer is mostly meant for "business transactions", pure domain methods that don't belong in a particular domain class. Calling the network or retrieving from persistence is not really something specific of the domain (the coins).

  • DI: Use it only on your external layers. No @Inject annotations polluting your inner classes (eg: CoinRepositoryImpl). Believe it or not, you can also decide to change your DI library some day, and we don't want the entire code base to be tied to it.

Paging?

How and where would you implement paging to this project using this approach?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.