Architecture should not be biased by Framework
Biased Thinking
Controller will have all possible code in the same package
As the time progresses the package becomes one big bowl of spaghetti code, writing testcase around the feature would be tough.
Readability becomes zero, you would be scared to dive in
All new feature will take a separate path, as we don’t understand the existing code
Unbiased Thinking
each package will have specific code related to the feature
we would have to tackle different problems here, like where would the abstraction classes go, if the abstraction is defined for couple of features
All the child classes of the abstraction should go in child packages
readability will definitely increase and diving to code would not be scary
The Architecture of the project should show blocks of code with respect to features. The biased thinking is common mistake done.
Data should always be exchanged through interface and never access the objects directly from classes of other features.
Super cool thing is to have all interface in a library and every feature is developed independently based on that library, the library should be version and release when there is a change in interface or an update in interface. Think this interface like a contract document for data interaction.
Library is too much to ask and manage sometimes for lazy people like me, I just put interface in a separate package under each feature. This is not a easy task you really have to find the owner of the interface. All consumers who wants to consume data will register to my feature. I expose Rx Observable’s through the interface, from my feature code I just throw events.
How do you know, if you have a good modular design in your project. Just ask the question How can i Disable a feature X for sometime or How can i Enable a feature Y only for testing.
All though it is easy to directly talk to any class and get data out of it, avoid tight coupling. This is a thinking shift not a new architecture.