Content Driven Development
When developing components for Adobe Experience Manager, it is very common to develop your functionality first and figure out the content later. The html and styling is crafted and sling models developed. These factors drive decisions about content, such as what dialog fields are needed, what the structure of the content is, and what the limitations of the data are.
One problem with this approach is that it assumes that content should be created in order to meet the needs of the functionality. This "functionality primacy" mentality is common when developing components because businesses needs and functional requirements rarely go beyond describing the end user experience. However, content is here to stay, and can only be changed with costly content migrations, and that is assuming that the content was structured well enough in the first place.
Functionality changes over time, adapting to fit the needs of the customer. The content that supports that functionality is being carefully crafted by manual effort. While the specific messaging of that content changes, its structure does not. The content is the real product that you are creating. The functionality simply presents that product in a new way.
With these ideas in mind, a changed mindset to developing CMS components is required: content first development. Treat the content for what it really is: the product that you are crafting. While web authors are creating the specifics of the content: the text and images and so forth, it is the web engineers that are creating the structure that it fits into.
In the scope of AEM this can be combined with a test driven development approach that enables you to treat your content structure as a testable piece of the architecture. To do this, you will want to create page and component content as apart of your development process, treating them as code. If using the AEM archetype project, you can add a testing section under the /content path of the ui.content project. Under this path, create a page for each component that you build.
Prior to developing the functionality of the component, add instances of the soon-to-exist resource type in the .content.xml files of the new components page. Craft the content of these components, with each instance testing some unique variation of the component. Think about edge cases such as text length and image size and any required hierarchy such as children components, page properties, and so forth. As you develop new features, come back to this testing page and add new variations that test the new features. You can also come back to this testing page to regression test old features. Additionally, these pages could be included in a testing workflow and CICD testing automation pipeline.
These components give you a content first approach to development, so that the content structure is planned in advance, not just crafted last minute to fit the needs of the current feature. Additionally, they give you the ability to do test driven CMS component development, a regression test suite, and the ability to do test automation against a thorough test suite.
Being treated as code, this content act as version controlled tests that sit along side the code that enables them to work. This means other developers have ready access to a set of examples, so they aren't spending time hunting them down, downloading content packages, or figure out what a component is supposed to do.
This has been a tremendous practical help in my own Adobe Experience Manager development efforts. Additionally, the concept of content first development applies beyond the scope of AEM or even CMS, and can be of benefit in many domains. The data that you pay to create will likely live for as long as the company is around (think about ecommerce product data). The instantiation of that data in the features of an app is temporary, short lived, and bound by the inherit limitations of the data itself. This data, not the features that temporarily instantiate it, is your product. Treat it as such!
