Plugin Architecture: Reversed Effort
Plugin Architecture: Reversed Effort
Join the DZone community and get the full member experience.
Join For FreeHow do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
Are you considering plug-ins in your next application/tool? Plug-in architecture is not a new concept, probably as you know it comes from a long time, and there are a bundle of stable "solutions" to support that, such as "Eclipse/OSGi" and others. Indeed there are several good technical arguments that can catch the development team's eyes when they decide to adopt this kind of solution, taking into account what they are planning for their application. For example:
- How can a functionality be added in a future moment?
- How can the functionality be increased after delivering?
- How can activated a component at runtime, following a specific component/plug-in lifecycle?
There are some strategies/patterns/definitions behind the scenes when the talk is plug-in architecture. I really encourage you delve into this subject.
On the other hand, nowadays we can see interesting points from a business perspective , when a team decide to develop an application/tool on top of a plug-in architecture. It is fact that the market has been accepting these new applications/tool in a good way, not "just" because there are relevant good technical arguments (but again, it depends of what you are planing to develop in terms of application/tool), but because there are different benefits that can be seen through the business perspective.
Usually the business team can take advantage of the ecosystem created around of a plug-in architecture, and define a business model to support the application on the market, involving your costumers and patterns throughout a profit relationship. It is possible to do it in an easy way, because one possibility is introduced naturally:
- The application can just create a "contract", defining a functionality/opening that it does not provide itself, although must be added by plug-ins.
- The extensibility power, what brings for the costumers and patterns the sensation of "freedom", where they want to improve/add function as they want, without your interaction.
- The startup of a plug-in market, where third parties will put their mind to think, trying to create some interesting plug-in adding naturally value for your application, what really well worth. Even if they make money without involving yourself, they will be adding value for your business.
The feedback power, where your application/tool will be all the time being "touched" for others code, and comments/suggestions will popup.
From http://mmayworm.blogspot.com/
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
Like This Article? Read More From DZone
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}