Architecture
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. An abstraction should not depend on an implementation detail (ie a database, a UI, device hardware).
"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."
They contain the logic that isn’t constrained only to one entity but handles more of them.
Used to pass data (in one or the other direction). How to easily differentiate/separate from Domain Use Cases?
The repository is passed to the use case as an argument. The insides of the UseCase are decoupled from the repository by coding to the interface, not the implementation.
https://softwareengineering.stackexchange.com/questions/371966/is-clean-architecture-by-bob-martin-a-rule-of-thumb-for-all-architectures-or-i : "The Clean Architecture is largely Robert C. Martin's re-branding and evolution of related approaches like the Onion Architecture by Jeffrey Palermo (2008) and the Hexagonal Architecture (“Ports and Adapters”) by Alistair Cockburn and others (< 2008).
Different problems have different requirements. The Clean Architecture and related approaches turn decoupling, flexibility, and dependency inversion up to eleven, but sacrifice simplicity. This is not always a good deal."
https://fernandocejas.com/2018/05/07/architecting-android-reloaded/
- Prove + Enforce decoupling between layers by putting them into different modules
- Modularize even packages "Code/package organization is one of the key factors of a good architecture: package structure is the very first thing encountered by a programmer when browsing source code. Everything flows from it. Everything depends on it."
"My second tip is to have a core module which will have these main responsitilities:
- Handle global dependency injection.
- Contain extension functions.
- Contain the main framework abstractions.
- Initiate in the main application common 3rd party libraries like Analytics, Crash Reporting, etc."
- Faster Build Time.
- Package cohesion.
- Re-usability of common functionality.
- Conflicts reduction (especially when working with git flows).
- Feature encapsulation.
- More controlled dependendencies.
- Team work: collaboration between teams."