-
Notifications
You must be signed in to change notification settings - Fork 4
Module Structure
- you can only access classes from the direct underlying layer
- clear separated responsibility for view, domain and data logic
Wires all modules together to an android app. Integrations tests based on Robolectric and Espresso are done here.
Storage (database, file, ...) and network handling. Synchronisation between network and storage. Hides how to access necessary data.
Good article how to organise database and network synchronisation with content provider https://drive.google.com/file/d/0B2dn_3573C3RdlVpU2JBWXdSb3c/edit and some nice improvement notes (german) https://docs.google.com/file/d/0B4rncoVb9uFGaUlpUnlLSzdoZ1U/edit?pli=1
The DataRepository module is the connection between Data and Domain.
Implements use cases which are offered at presentation.
The DomainInteractor module is the connection between Domain and Presentation.
View logic.
Contains data transfer object, perhaps later comes a better solution.
I'm prefer the functional approach to structure the packages. This conflicts a bit with clean architecture module structure but inside each module is the functional package approach. This not implies that each package is contained in each module. Each module will have its own functional view how organise the classes. See also http://www.javapractices.com/topic/TopicAction.do;jsessionid=0BF4844350780B6F55476E1137FF4893?Id=205