Architecture

Architecture matters.

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Dependencies should be in the direction of increasing abstraction.

"Top/Inner" in this case == more abstract; business logic should not depend on a database implementation.

Business logic shouldn't even know about the implementation.

"Conforming to these simple rules is not hard, and will save you a lot of headaches going forward. By separating the software into layers, and conforming to The Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that implies. When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss."

Activities and Fragments

---

ViewModel per Activity

---

Business Entities

Domain Use Cases

They contain the logic that isn’t constrained only to one entity but handles more of them.

Application Use Cases

Used to pass data (in one or the other direction). How to easily differentiate/separate from Domain Use Cases?

---

Repository is defined as an Interface that Use Cases can use as an output port

https://martinfowler.com/eaaCatalog/repository.html

---

Data layer(s) with Interface (EntryDao Interface for Room/SQL Database)

Sync with remote server

https://five.agency/android-architecture-part-2-clean-architecture/ https://five.agency/android-architecture-part-3-applying-clean-architecture-android/