Domain-Driven Design, part 7 — Alternative Relational Database Mapping
Product Name Story
We worked on an e-shop and the product had exactly one name. One day we faced confronted with the reality — the e-shop has to be multilingual. I imagined a new database table for every language field immediately, and I was disgusted by all the tables that had to be created. But luckily I asked myself — What is the domain?
Use cases
The domain can be extracted from stories and use cases. We discussed this in our team and we extracted a couple of use cases:
- Change the product name in the language.
- Show the product name in the language
- If the name in language is missing, show an empty string
We don’t have a use case to remove a name. The product could exist without a name anyway, so creating one wasn’t a problem.
LangValue Extraction
Use cases were the same for all names or descriptions in the system that had to be multilingual. So we decided to extract use cases and responsibility into a common LangValue.
LangeValue is a multilingual text, this is its responsibility. It has to be able to change the text in the language and read the text in the language. It doesn’t have an identity — LangValue is identified by all its properties, it is a value object. We decided that language identifier can be any string.
The implementation of the multilingual product name is simple. The class is simplified to be instructive.
Relational Database Storage
The LangValue works great in objects but how to save it into a relational database? Well, we could think that text in language must be in a separate table. That would be difficult to map, even impossible without changing the domain model.
Let’s take a step back. What are our use cases? We have to be able to change the text in the language and read it in the given language. This is what our class LangValue does by itself.
Do we have the use case that needs language text in a separated table? I don’t think so. So what if the LangValue would be serialized in a single field? Does it cause problems? It could be difficult to find a product by name in the language, but we do not have such a use case. So the serialization can be a good option.
Disclaimer
In a real project we have the finding use case. We have a dedicated database with a special structure for a quick search.
Serialization
We decided to use LangValue serialization.
We can serialize it by PHP serialize function or extract the internal array and serialize it. Both styles are similar - they end up with PHP structure encoded in a string that is not readable by people and by databases.
We can use custom serialization method, but that would probably be a horrible choice.
We can also serialize the LangValue into a JSON. It is readable by people and some databases and can work with JSON data type too. This seems to be a reasonable choice.
Example of serialized object
{
"cs-CZ": "Televize",
"en-GB": "Television",
"es-ES": "televisión",
"ru-RU": "телевидение"
}LangValue Doctrine Mapping
We need to convert the LangValue to the JSON and vice versa.
Doctrine supports custom mapping type for this particular task. Once the custom type is registered and mapped, all objects are mapped correctly to the database. The custom type is registered in DBAL layer, so even when we hydrate arrays instead of objects, text is hydrated as LangValue object. When we hydrate scalars, we get raw data from the database — string JSONs.
If the target database supports JSON data type, the Doctrine works with it. Otherwise, it uses the text data type.
Registration
We have to add code to the Doctrine integration.
\Doctrine\DBAL\Types\Type::addType(LangValueType::LANG_VALUE, LangValueType::class);/** @var Doctrine\DBAL\Connection */
$connection = ...;
$platform = $connection->getDatabasePlatform();
$platform->registerDoctrineTypeMapping(LangValueType::LANG_VALUE, LangValueType::LANG_VALUE);
Mapping
Database Search in JSON
A relational database isn’t usually a good choice for a full-text search. But some databases allow us to query the JSON data type anyway.
If we want to search using JSON, we can always write a native query. Or we can create a custom DQL function that is translated into engine-specific JSON query.
PostgreSQL
SELECT * FROM Product where name->>'cs-CZ' LIKE '%query%';MySQL
SELECT * FROM Product where name->'$.cs-CZ' LIKE '%query%';TL;DR
Think before mapping. Even if you are experienced, you can find some new and creative mapping styles. Focus on use cases, do the object model first and think about relations and mapping later. JSON object serialization is useful.
References
DOCTRINE TEAM. Custom Mapping Types — Doctrine 2 ORM 2 documentation [online]. 2018 [2018–03–14]. Available: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/cookbook/custom-mapping-types.html
Contact
Are you designing architecture and like DDD approach? Hire me, I can help you — svatasimara.cz
