When the app dictates the database structure and the app is the only thing using the database structure then you are in a happy place. Every decision you make is for the benefit of the application alone.
Data modelling in Apache Cassandra is aligned to this. It works on the principle that you design your tables (column families) for the way that the app wishes to consume them. Even if this means data duplication and the headache of maintaining consistency of data between the tables (as opposed to consistency across the nodes in the Cassandra ring). Used correctly this can be extremely effective. It seems to work well for iTunes which has a multi-petabyte Cassandra cluster.
Where things get tricky is when someone decides that the data in your application would be jolly useful for a variety of purposes especially when some of those purposes require the same level of data consistency as the app that spawned the database in the first place. In other words, the implications of "Data is Shared" become apparent.
There is no perfect world. It's a case of which set of compromises are most important to your organisation. Is one particular app the king? Are the apps more or less equal partners? What is the value put on data beyond the obvious value to the original application? How fast does the data have to flow between the different applications?
These things have a profound affect on the data modelling decisions.
Perhaps today we have to take a decision that we know will have to be reconsidered if the application becomes successful. To give an example today the app is King. We have to find out if the app gives customer value and delivers a profit. We will simply copy the data as is from the front-end data store to the data store used for reporting. People doing the reporting will just have to cope with what they are given.
Tomorrow people want more than simple reporting, they want analytics and machine learning. Translation of data from a front-end application data structure to one suited to machine learning and analytics becomes more burdensome and eventually proves to be a bottleneck in what the business wishes to do. Unless the business completely turns on its head it is unlikely that the back end needs will dictate the front-end structures. What I have seen is an evolution towards a master representation of the data with the transforms to front-end/back-end being a much smaller change in either direction. In effect both front and back end applications use abstractions of master data. Yes the app loses some of the rapidity of change but does not come to a shuddering halt.