Here for any request to the application the following logic applies:
The diagram therefore suggest to develop the interface public interface of controller first. Then you can simultaneously develop each PV pair independently from the other PV pairs while you can also be developing your MC pair. This hign level of decoupling allows several developers to work on the bounded context at once.
This level of decoupling also allows to use Nette for what is its strength. If we look where Nette fits in the diagram, it is a perfect example of PV framework.
This statement is further supported by the fact that Nette didnt have a model layer by default for a long time and that is heavily build around services (more on this in the next article). With this design, Nette does not have to care about model, it is completely isoled from ani API or CLI calls. It only serves the website.
You could use Nette(or any other website framework) for the website, but what about the other two cases? Well this is the beauty of this design. It does not matter. It doesn't even have to be the same language. You could use restify nodeJS module for your REST API and resty wapper for cURL for your CLI. But with using different languages for your presenters brings problem in collaboration with your controller. What the problem is, how to solve it and the finalization of MVPC design will be in the next article.
Continues by MVPC – Introducing mSPV