Domain Driven Content Management

Domain Driven Design is—by experience—a strong concept and a good foundation to build TYPO3 extensions upon.

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 [...].[1]

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[2].

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[3] 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[4]:

  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[5]. These aggregated content objects represent the structure[6] 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[7]:


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”[8]. It seems to fit my purposes:

The domain model "Article" of the CMS

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”[9]. 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.


  1. Quoted from:; for a brief introduction, visit 
  2. Generally it delivers a HTML page but that can also be PDF, SVG, or any other format 
  3. IMO, this has to be done soon for TYPO3 v5 
  4. This is a well known pattern called Two-Step-View ( 
  5. These content objects should be “naked” content objects and not be overloaded like the cObj today. And they should “real” objects in the sense of OOP 
  6. ordinality and carinality 
  7. This is only a quick sketch. It’s not meant to be a replacement fo tt_news ;-)  
  8. There isn’t such a content object in TYPO3 available at the moment. But, let’s assume to have one ;-)  
  9. IMO a page is nothing but a content element. But that’s worth another post 
  1. Sebastian Kurfürst says:

    Cool website – I’ll follow this blog! :-)

  2. In this kind of articles, examples are very important… other wise the reading becomes too abstract. Good that you gave good ones!

    I feel I will like Domain-driven design.

  3. Jeff Segars says:

    Great to see you blogging now! Looking forward to following your progress on the MVC project…


  4. I think I just started to understand what DDD is. Thanks, you’ve got one more follower!

  1. There are no trackbacks for this post yet.