Refactor project structure to one single module

[android10]

Back in time, there were limitations for configuring test frameworks to work all together in the same module on an Android Application, specially if your test battery included Acceptance, Integration and Unit Test.

This PR aims to refactor project structure to sit on one application module avoiding maintainability and configuration overhead. Basically, the idea is to get rid of current presentation, domain and data module, and create an application module with a better package organization/structure.

This is a WORK IN PROGRESS and a good candidate for discussion. There is no final decision to merge it.

[amatkivskiy]

@android10 will this structure changes affect the time required for gradle to build the project?

[FranRiadigos]

English below.

Hola Fernando, en mi opinión no veo conveniente mover las capas en un único módulo, ya que perderíamos la restricción que los módulos nos proporcionan, y por desgracia se podrían, por ejemplo, hacer referencias a elementos u objetos de la capa de presentación dentro de la capa de datos.
Por poner un ejemplo, no tiene sentido que un repositorio tenga una referencia a una constante o cualquier otra cosa que esté definida en un Activity ¿verdad? Pero si lo ponemos todo en un mismo módulo, y sobre todo hablando dentro de un equipo, algún desarrollador podría hacer este tipo de malas prácticas.

He tenido el mismo problema para compilar la batería de todos los tests en el servidor de integración, pero como solución temporal y para evitar tener que usar sólo un módulo podríamos, por ejemplo, sólo mover los tests al módulo principal, ¿que te parece por ahora?

————————

In my opinion, I don’t think it’s a good idea moving everything into a unique module, because we are going to miss the good restrictions the modules give us, so unfortunately someone could reference objects or any other kind of elements from the presentation layer into data layer.
For instance, it doesn't make sense that a repository can have a reference of a constant or whatever is defined in an Activity right? So, if we finally put everything in just one module, and especially relating to a working team, some developer could do this kind of wrong stuff.

The compiling tests issue you mention happened to me as well in the CI server, but to avoid merging everything in one module, I would like to suggest for now, to move just those tests from the other modules into the main module, What do you think?

[android10]

@amatkivskiy @kuassivi really appreciate the input and I do understand the needs, so that is why I started a discussion here: #112

Feel free to join, we wanna take the best path here 🔥 😄

[DmitriyZaitsev]

Hello Fernando!

I believe, the division into modules makes it impossible to shoot yourself in the foot, and also makes it impossible to resist the temptation to use wrong dependencies between layers. Modularity helps us to have our code clean, restrictions save us from spaghetti code.

UPD 26 Sep 2016:
Having several modules isn't that convenient than having one single module.

• Top-level architecture and package structure should describe the intent of the app instead of its components.
• Current modules aren't completely indepent and isolated from each other. They're coupled, so it makes no sense to have them separately.
• Application isn't a library, so I don't see a strong reason for modularity here.
• Single module is easier to configure.
• It's much simpler to create logical layer separation within concrete package.
• Adding/removing/changing the feature will affect only one package instead of three modules.