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 [...].
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
- Map the domain objects of the extension onto the content object aggregate of the CMS
- 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 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:
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:
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.
- Quoted from: http://en.wikipedia.org/wiki/Domain-driven_design; for a brief introduction, visit http://www.typo3-media.com/blog/domain-driven-design-introduction.html ↑
- Generally it delivers a HTML page but that can also be PDF, SVG, or any other format ↑
- IMO, this has to be done soon for TYPO3 v5 ↑
- This is a well known pattern called Two-Step-View (http://martinfowler.com/eaaCatalog/twoStepView.html). ↑
- 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 ↑
- ordinality and carinality ↑
- This is only a quick sketch. It’s not meant to be a replacement fo tt_news ;-) ↑
- There isn’t such a content object in TYPO3 available at the moment. But, let’s assume to have one ;-) ↑
- IMO a page is nothing but a content element. But that’s worth another post ↑