Domain-driven design (DDD) is an approach to the design of software, based on the two premises that complex domain designs should be based on a model, and that, for most software projects, the primary focus should be on the domain and domain logic [...].

The domain represents structure, knowledge and data. A content management system (CMS) like TYPO3 has to handle the data of the domain with respect to the domain knowledge. It aggregates the data, and visualizes it as a content of an output format.

A question emerges: How should the data stored in a domain be mapped on the content of the output? You might say: “Hey, what’s the problem? The data ‘stored’ in the extension is already the content to be displayed!”. I don’t think so. Nowadays, the domain of an extension and the domain of the CMS are woven into another. And the following questions are answered by the extension itself:

• “What is the title of the article?”
• “How many articles should be shown on the front-page?
• “Should the subtitle of the article be emphasized?”

So, we have to spend hours and hours to adapt all the templates of an extension to fit in the overall context of a web page. That’s annoying. Now, let’s try to solve that issue. The first thing is to assign the questions to the proper domain:

• “What is the title of the article?” → domain of the extension
• “How many articles should be shown on the front-page? → domain of the CMS
• “Should the subtitle of the article be emphasized?” → domain of the CMS

If we finished the separation of the two domains we are ready to take the next step: mapping the domain of the extension onto the output generated by the CMS. I propose a two-step process:

1. Map the domain objects of the extension onto the content object aggregate of the CMS
2. Transform the content object aggregate to the output format

The first step maps the domain objects of the extension onto content objects. These aggregated content objects represent the structure and the semantics of the output, but not its syntax (like “<h1>The Title</h1>”). The second step transforms the content objects to the output format. This can be done with a templating engine as usual.

The benefit of this two-step process is that the CMS “owns” the templates. So we can configure the visual representation of the domain objects of all extensions at one central place.

An Example

An example might clarify the process. Let’s assume I want to write a news extension. The first step is to design the domain of my new extension:

The domain model "News Item" of the extension

Then I have to examine, what the CMS built-in content object catalog offers to me. Hm, okay, there is already a content object called “article”. It seems to fit my purposes:

The domain model "Article" of the CMS

I configure the mapping as follows:

• Author → Author
• Text  → Text
• Title → Header
• Subtitle → Subheader
• Teaser → ShortDescription
• PublishingDate → Date

As a result, I have a generic “Article Object” which can be added to a higher-level content object, like “Main Content Area” or “Page”. My “News Item” will be rendered depending on the configuration of the transformation process and the context the article is displayed in. I—as an extension developer—don’t have to deal with the visualization of my domain objects.

But, what if I want to get the control back over the presentation of my domain object? Then I have to define my own content object class (which can of course extend an existing content object class).

This leads to much more decoupled way of content management based on domain driven design. That’s why I called it “Domain Driven Content Management”.

I’m anxious to read your comments.