> For the complete documentation index, see [llms.txt](https://docs.zongsoft.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zongsoft.com/documentation/en/overview/pluginization.md). # Plugin Architecture Basic concepts and operation methods of Zongsoft plugin-based applications. Plugin architecture is a core feature of Zongsoft. A plugin-based application consists of a host and multiple plugins. The host is responsible for starting and hosting, and the plugins are responsible for providing business capabilities and extension points. ## What Is a Plugin In Zongsoft, a plugin is not an alias of a single assembly, but a combination of a set of files and metadata. The most common plugin content includes: * Plugin description file `*.plugin`. * Plugin assembly `*.dll`. * Option configuration `*.option`. * Data map `*.mapping`. * Localized resource directory, such as `zh-Hans`, `zh-CN`. * Certificates, templates, static resources and other ancillary files. ## How to Load Plugins After the host is started, the plugin framework will scan the `plugins/` directory under the host directory, read the plugin description file, load the assembly and create an application context. Plugins can register services, commands, event handlers, web controllers, or other module capabilities. ## Why Use Plugin Architecture Plugin architecture solves the organizational problems of large business systems: * Business modules can be released independently. * Running the host can remain lightweight and stable. * Different environments can combine different plugins through deployment files. * Business plugins that do not depend on a particular interaction model or protocol can be reused across host types. Controllers and ASP.NET middleware, however, must run within a Web host. * Configurations, mappings, and resources can be deployed with the plugin. ## Plugin Design Essays These articles examine design choices and their costs through the existing forum implementation, beginning with why pluginization exists. Read them in order or start with your current question. “Proposed” in the illustrations identifies a design scenario; the text explains which capabilities currently exist. 1. [Why Pluginize](/documentation/en/overview/pluginization/why-pluginization.md): The pain of a monolith, and the changes that layering, slicing, and organizing by business domain bring. 2. [Finding Module Boundaries Through Business Changes](/documentation/en/overview/pluginization/business-boundaries.md): Use changes to moderation, content, and statistics to establish ownership. 3. [Reusing Business Capabilities Across Hosts](/documentation/en/overview/pluginization/host-independent-business.md): Separate business operations, entry adapters, identity, and lifecycles. 4. [Designing Extension Points as Collaboration Contracts](/documentation/en/overview/pluginization/extension-contracts.md): Define extension paths, service calls, names, and failure semantics. 5. [From Incremental Change to Verified Plugin Delivery](/documentation/en/overview/pluginization/evolutionary-delivery.md): Validate release combinations and evaluate data compatibility and process separation. ## Document Reading Suggestions Read [Plugin Framework](/documentation/en/framework/plugins.md) first to understand the application model, and then read [Deploy Your First Plugin](/documentation/en/get-started/deploy-first-plugin.md) to understand how the plugin enters the host. When you need to delve into data access, enter [Data Engine](/documentation/en/framework/data.md). ## Extension Point Is Also a Contract One plugin provides a service or collection mount point, and another plugin declares dependencies and contributes implementations. Dependencies not only determine assembly visibility, but also describe "which components are required before they can work." Extension paths, service names, and configuration keys should be maintained like public APIs, with consumers synchronized when changed. Plugin architecture does not equal arbitrary hot replacement, nor does it equal process-level isolation. Components loaded into the same host share process resources, and version conflicts or incorrect [workers](https://github.com/Zongsoft/framework/blob/main/Zongsoft.Core/src/Components/IWorker.cs) can affect the entire application. When independent fault boundaries are required, independent processes and communication protocols should be considered. See [basic concepts](/documentation/en/overview/concepts.md) for background terminology and [The first business plugin](/documentation/en/get-started/first-business-plugin.md) for the complete combination path. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.zongsoft.com/documentation/en/overview/pluginization.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.