When we want to organize a lot of products and its behaviors into multiple Extensions, it can get daunting on what strategies to use.
Going into this unplanned could lead to a very messy code base, making it unnecessarily difficult to navigate, maintain, and control.

Here are the strategies we usually use and recommend.

Strategy 1 - Core & Product Specific Extensions

This concept is based on having one main Core Extension and several Product Specific Extensions.
As such, common behaviors shared from multiple Product Specific Extensions will reside in the Core Extension.

Core Extension

This Extension has its own packages and must be included in the release box when building a release in CET Build Central, just like how we do with any abstracts. When releasing this Extension in MyConfigura, make sure to make this Extension free and NOT visible in the marketplace using the checkboxes:

If a main toolbox will be shown from this Extension, we can set up its visibility using channels or flags in the sub-Extensions.

Product Specific Extensions

These are sub-Extensions with product specific packages. We will have to add dependency to its Core Extension. These Extensions handle their own licenses and costs and will be released in the marketplace.

Pros

• This is an easy structure to build as we only need to add new packages for each Extension needed and include necessary packages in each of them.
• Multiple Extensions can be installed at the same time, each of them using the same core Extension.

Cons

• Problems may arise if we need to move around the Extensions or their functionalities at later stages of the development lifecycle.
• Major changes made to the core Extension may require updates or refactoring to the sub-Extensions.
• Collision may arise if the same packages are used in more than one sub-Extension. (This can be solved by using another hidden Extension that we add our dependencies on)

Strategy 2 - Channels

In this alternative, we only have one Extension, and we handle everything using channels.

Pros

• Only need to rebuild one Extension on new releases.
• Extension visibility can be changed even without new releases.
• No conflicts between sub-Extensions.
• No dependency issues when rearranging codes or functionalities.

Cons

• Implementing channels require a great deal of programming.
• An entire code base will be installed for every user.
• When updates are made to the Extension, every user will get an update even if it does not affect their usage area of the Extension.
• No flexibility for licensing and costs.

Strategy 1 & 2

The two alternatives provided are merely concepts we can leverage on, we can adjust our Extension based on our own requirements, such as using both concepts together.
An example will be having the Core and Product Specific Extension structure, but within each Product Specific Extension, we have behaviors (i.e., sub-Extensions, visible buttons) controlled by channels. 

Even though there is flexibility in creating multi-Extensions, it is recommended to have the Extension structure planned out beforehand to avoid unnecessary headaches.