DDD: where to generate url slug of an entity?

Question

how do you deal with url slug generation in DDD?

Inside constructor? But entity relying on other service is not good.

Pass as constructor argument? I think slugs shouldnt be there because they are not business requirements. are they?

or just having a setter?

Forbear

A slug does not seem like a real concept from your underlying business domain, but rather something to provide nice URLs for web applications. As such slug generation is part of another layer or bounded context and does not belong to the core domain. – Nehru

how will you deal with that? We have courses, and I want the title of the course to be the url instead of the id. The url may vary depending on the title if its too long or for other reason so Ive thought its better to save it on database. so you mean by bounded context, I should save it on separate table? – Forbear

Yes, a separate table is probably the best idea. At the end, the slug is just a presentation concern, and if you ever, say, add a mobile-app to your course-system, a slug has no meaning here. – Nehru

Thank you. Havent had the chance to play with it yet. – Forbear

I know it's hard, but I'd think the url slugifier as a service outside the domain layer, today you might use an external package to generate it, tomorrow you might consume an external API, I wouldn't put this logic inside domain. Therefore, like @AlexanderLanger said, I'd create a separeted entity with the url slug, and a reference to the owner entity (id and type). So you can store url slug for any kind of entity (images, videos). Putting a property in the entity is something strong, like it's part of the entity independently of what application is being used to consume said entity. – Discerning

Answer 1

It seems like the URL slug IS part of your domain model, even though it seems like an infrastructure concern at first.

If you are modeling it as a property of your entity, I see no problem in passing it in the constructor arguments. It is certainly better then having it as a property with a public setter, open to be modified by anyone at anytime.

Create an ISlugGenerator interface and inject it into the appropriate layer (ApplicationService or DomainService, see here for more info), to generate the URL string and pass it in the constructor to the entity.

Implement the ISlugGenerator in the Presentation Layer, the one that actually holds the page/route that is going the be accessed via the URL.

---

You could argue that the URL really has no place in the domain model, because it is just some info that is related to the entity, but is not used in any decision making process.

Well, then think about Product Description or Product Image in an e-commerce application. It is the same thing. You most certainly have validation logic for these properties and this validation should be part of the Domain, but you probably don't make any other decisions based on them.

So, shouldn't you remove Description and Image from the Product entity? Actually, no. Even though the image is probably a URL just like the slug from your question.

The product will receive the imageUrl as a string parameter in its constructor, or be set via a method in the entity. But the imageUrl will be generated by some ImageUploadService, whose interface will be defined in the Application Layer and implemented in some Infrastructure Layer.

Sanderson