1) Attempt to model a database schema that fully and completely supports said data. This will force you to get a sufficiently deep understanding of the domain problem and how it's different parts relate to one another.
2) Is there a part of the domain problem whose dynamic or unstructured nature cannot be properly represented on a fixed database schema and/or this unstructured piece of data must be performantly queried? Add a "companion" Document DB to your architecture.
3) Are there performance issues/requirements on a given part of your system and you need to hold volatile data such as a cache of processed data, or you need to efficiently handle user sessions across multiple machines, or even a queuing system for processing tremendous amounts of data coming in? The add a "companion" Key-Value DB to your architecture.
... And many, many other examples of other specialized NoSQL DBs could be added here, but you get the idea.
Summing up: Understand the data > Attempt to model an RDBMS schema that supports said data > Use proper "companion" DBs for whatever data that does not fit in a RDBMS.
If you have to ask yourself “Should I use SQL or NoSQL?” then you should use SQL. If you have to use NoSQL, you won't have to ask yourself. Usually it's pretty obvious when you will not use joins at all.
However, I feel like the article fundamentally fails to address the core question of "When should I pick NoSQL over SQL?" If SQL is indeed the choice 99 times out of 100, how can you know when you are faced with that 1-in-100 time when NoSQL is actually the right option?