Skip to content
nenick edited this page Nov 24, 2014 · 8 revisions

Reason for this structure

  • you can only access classes from the direct underlying layer
  • clear separated responsibility for view, domain and data logic

Should show the module diagram

App

Wires all modules together to an android app. Integrations tests based on Robolectric and Espresso are done here.

Data

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.

Domain

Implements use cases which are offered at presentation.

The DomainInteractor module is the connection between Domain and Presentation.

Presentation

View logic.

Shared

Contains data transfer object, perhaps later comes a better solution.

Structure functional vs technical

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