Core path ยท 17 of 34
Understand how to design reusable Content Fragments that support multiple digital experiences without becoming coupled to a page, layout, or frontend.
The previous chapter looked at how Content Fragments can reference other pieces of content.
References allow related business content to be connected without putting everything into one fragment.
The next challenge is reuse.
A product may be used on a product detail page, a category page, a mobile application, or another digital experience. The business information remains the same, but each experience may need a different part of that information.
That raises an important modeling question:
Should content be designed around the experience that consumes it, or around the business concept it represents?
This chapter focuses on designing Content Fragments so they can be reused and composed across different digital experiences without becoming tied to a particular page or frontend.
Consider a product represented by a Content Fragment.
The product may contain information such as:
A product detail page may use most of this information.
A category page may only need the product name, image, and a short description.
A mobile application may use the name, features, and specifications.
The content is still describing the same product.
The difference is in how each experience uses that information.
This distinction becomes important when designing Content Fragment models.
A common mistake is to create a separate fragment for every experience:
At first, this appears convenient because each experience gets exactly the fields it needs.
The problem is that the same business information is now stored in multiple places.
The product name may exist in several fragments. The description may be maintained separately. A product update now has to be applied to multiple pieces of content.
The content that was intended to be reusable has become coupled to the experiences consuming it.
A better approach is to model the product as a business concept and allow each experience to decide which information it needs.
A reusable Content Fragment should describe the business concept it represents rather than the page where it happens to be displayed.
For example, a Product Content Fragment represents a product.
It should contain information that belongs to that product:
It should not need to know whether the product will appear as:
Those are presentation decisions.
The consuming experience decides which information to use and how to present it.
This separation is important in a headless architecture.
The content describes the business.
The consuming application controls the presentation.
Reusing the same Content Fragment does not mean every experience has to display every field.
A product detail page may need detailed specifications.
A category page may only need a short description.
A mobile application may use a different combination of product information.
These differences belong to the consuming experience.
The experience decides:
The Content Fragment should remain focused on the business information.
There is another mistake on the opposite side.
After learning about reuse, it can be tempting to put everything related to a business entity into one large Content Fragment.
A Product Fragment might eventually contain:
This may appear flexible because every possible consumer can find what it needs.
Over time, however, the model becomes difficult to understand.
Some fields may belong to the Product itself.
Others may represent marketing content.
Some may have a different lifecycle.
Others may belong to another business concept entirely.
Application-specific information is particularly problematic because it introduces knowledge of a particular consumer into the business content model.
The better approach is to keep the Product Fragment focused on information that genuinely belongs to the Product.
Related or independently managed content can be modeled separately and connected when required.
This gives each Content Fragment a clear responsibility.
Reuse does not mean putting everything into one Content Fragment.
It means identifying meaningful business concepts and modeling them independently so they can be reused and connected when necessary.
Reuse and composition are related, but they are not the same thing.
A Product Content Fragment may represent the product itself.
A digital experience may need to combine that product with other content:
The Product Fragment should not become responsible for the entire experience.
Instead, the consuming experience can bring these pieces together.
For example, a product detail experience might use the Product Fragment together with a promotional Content Fragment and several related Product Fragments.
Each piece retains its own responsibility.
The experience decides how those pieces are combined.
This is composition.
It allows an experience to build something specific without changing the meaning or responsibility of the underlying content.
Good reuse depends on good boundaries.
When deciding whether information belongs in a Content Fragment, ask what business concept owns that information.
For a Product Fragment, ask:
If the answer is yes, the information may belong in the Product model.
If the information represents another business concept, it may deserve its own Content Fragment.
For example, a promotion associated with a product does not necessarily become part of the Product Fragment simply because it appears beside the product.
The promotion may have its own:
Keeping these responsibilities separate makes the content model easier to understand.
It also allows each piece of content to evolve without unnecessarily changing unrelated content.
Consider an organization that manages a large catalog of products.
The product team owns Product Content Fragments. A campaign team manages promotional content separately. Related-product relationships connect products where required.
Experiences can then compose these pieces together without making any single fragment responsible for the entire experience.
Reusable content should not be forced into every situation.
Sometimes two experiences genuinely represent different business concepts.
For example, a Product Fragment and a Product Comparison Fragment may both contain product information, but their responsibilities may be different.
The goal is not to create the smallest possible number of Content Fragments.
The goal is to create clear content boundaries.
A useful question is:
Are these two pieces of content describing the same business concept, or are they only similar because they happen to be displayed together?
If they represent the same concept, reuse may be appropriate.
If they have different ownership, lifecycle, or business meaning, separate models may be more appropriate.
This prevents reuse from becoming another form of coupling.
The main idea of this chapter is simple:
Model reusable content around business concepts, not around individual experiences.
A Product Content Fragment should represent the Product.
A consuming experience decides whether it needs the product name, image, description, specifications, or another supported field.
If the experience needs additional content, it can compose that content with other reusable Content Fragments.
This gives us three separate responsibilities:
Content model
Defines the business information.
Content
Represents the business entity and its data.
Experience
Decides how that information is consumed, composed, and presented.
Keeping those responsibilities separate makes it easier to introduce new digital experiences without creating another copy of the underlying business content.
The goal of Content Fragment reuse is to represent meaningful business concepts independently from the experiences that consume them.
The same Content Fragment can support different experiences while each experience decides which information it needs and how that information should be presented.
Composition allows an experience to combine multiple reusable pieces of content without making any one fragment responsible for the entire experience.
Good content modeling therefore depends on clear boundaries:
As the number of digital experiences grows, these boundaries become increasingly important.
Reusable Content Fragments solve one problem: the same business content can support multiple experiences.
But an enterprise AEM implementation may contain thousands of fragments representing products, categories, campaigns, locations, and other business entities.
At that scale, reuse alone is not enough.
Teams also need to decide how content is organized, discovered, governed, and maintained.
Next, we look at Content Fragment organization and governance and how these decisions become important as a headless content repository grows.
Get an email when I publish the next chapter. No spam โ just new technical deep-dives.
Comments
Share feedback or questions about this blog post.
No comments yet. Be the first to share your thoughts.