What’s the best time to add plugins?
If you predict that certain features are interesting to your system but would look better outside your "core", then it helps to design it from the start so expect plugins.
An example would be a program that handles several file formats, but doesn’t want to get "tied up" with the natively supported formats. In this case, it is better to abstract the treatment of these files, and write a plugin for each desired format. Facilitating, of course, the development and deployment of new plugins, including by third parties.
What is the purpose of a plugin?
A plugin is a complement for your system, a way to extend the basic functionalities of the system. This way, a plugin only does what the system "lets" it do, can not solve whichever possible and imaginary problem that way (unless the "plugin" use Monkey patch or even modify the sources of the original system and recompile them - in which case it is more called "mod" that of "plugin").
There are those who try to design entire systems as a small generic foundation and a large set of plugins. This type of architecture is complicated because it is necessary to carefully manage the dependencies between plugins, but the end result is a system with greater flexibility. At first could replace any plugin by another in order to change the functionality of the system, but in practice the dependencies chain makes it difficult to modify the "base" of the system, so that even this model has limitations.
Apparently many projects see plugins as the basic functionalities of their systems, when in my understanding, plugins should be only functionalities "extras".
Not necessarily, see the first example of file formats, that can be a "basic" functionality (i.e. you need at least 1 file type supported by the system to do anything useful) but still be better modeled in the form of plugins. The key point is to identify which areas of the system require high customization, and prepare to serve them accordingly.
In case I decide to add plugins to an application, is there any methodology ready for me to base myself and avoid making design mistakes?
There is no single solution for all cases, but I would recommend taking a look at Principle of Inversion of Dependence, and its related standards (in particular Dependency injection and the Inversion of Control, among others). The key point is to enable your system to receive extensions without having to recompile it, or better still without even having to stop the same when adding/removing a plugin (more difficult, but very useful during development and also convenient for the end user).
Finally, if you already have a system ready and realize the need to customize it (either with plugins or some other way), it may often be necessary to refactor it, so as to abstract the interface between the components (e.g., how your system communicates with library A) and later carry out this abstraction through two concrete implementations (one that communicates with A, the other that communicates with B). In this case, dependency inversion may help, but it is not necessary to go all the way to making your system "pluggable" to reap the benefits of this abstraction (you can keep everything internal even with only one line in the settings indicating which strategy follow).
Although this question gives some margin for opinions, I find it very interesting and "responsive", so I’m voting to leave it open.
– mgibsonbr
@mgibsonbr I think you’re right, if you take this part of the question into consideration I must worry about them from the system design, or should I leave them for a more opportune time? If you have an answer for the colleague then I will vote to reopen as well.
– Guilherme Nascimento