How to reduce the higher time complexity brought by DDD

Question

After reading the book Domain-Driven Design and some characters in the book Implementing Domain-Driven Design, I finally try to use DDD in a small service of a microservice system. And I have some questions here.

Here we have the entities Namespace, Group, and Resource. They are also aggregate roots:

As the picture pointed out, we have many Namespaces for users. And in every Namespace, we have Groups as well. And in every Group, we have Resources.

But I have a business logic:

• The Group should have a unique name in its Namespace. (It is useful that the user can find the Group by its name)

To make it come true, I need to do those steps in the application layer to add a group with time complexity O(n):

• Get the Namespace by its ID from the Repository of Namespace. It has a field Groups, and its type is []GroupID.
• Get []Group value by []GroupID value from the Repository of Group.
• Check if the name of the new group is unique in the existing Groups we get.
• If it does be unique, then use the Repository of Group to save it.

But I think if I just use a sample transaction script, I can finish those in O(lg n). Because I know that I can let the field of Group name be unique in the database. How can I do it in DDD?

My thinking is:

• I should add a comment in method save of the Repository interface for Group to let the user know that the save will check the name if is unique in the same Namespace.
• Or we should use CQRS to check if the name of Group is unique? Another question is that maybe a Namespace may have a lot of Group. Even though we only put the ID of Group in the entity Namespace, it does cost a lot of space size. How to paginate the data?······ If we only want to get the name of Namespace by its ID, why we need get those IDs for Groups?

I do not want the DDD to limit me. But I still want to know what is the best practices. Before I know what happens, I try to avoid breaking rules.

---

My solution:

Thanks for the answer by @voiceofunreason. I find that it is hard to write code for set validation in the domain layer still.

@voiceofunreason tells me that I need consider the real world. I do consider and I am still confused that how to implement it to avoid breaking DDD rules. (Sorry but my question is not do we need the condition or not. My question is HOW to make the condition(or domain logic) come true without higher time complexity)

To be honest, I only have a MongoDB serving for storing all data. If I am using Transaction Script, everything is easy:

• Create an index for the name of Group to make sure the names are unique.
• Just insert a new Group. If the database raises any error, just refuse the request from the user.

But if I want to follow the DDD, and put the logic into the domain layer, I even do not know where to put the logic (it is easy in Transaction Script, right?). It really makes me feel blue. So my solution is:

• Use DDD to split the total project into many bounded contexts.
• And we do not care if we use the DDD or others in the bounded context. So tired I am.
• In this bounded context, we just use Transaction Script.

Is the DDD not well to hold the condition for the set of entities, right? Because DDD always wants to get all data from the database rather than just deal in the database. Sometimes it makes the time complexity higher and I still do not know how to avoid it. Maybe I am wrong. If I am, please comment or post a new answer, thanks a lot.

Answer 1

The Group should have a unique name in its Namespace.

The general term for this problem is set validation. We have some collection of items, and we want to ensure that some condition holds over the entire set....

What is the business impact of having a failure

This is the key question we need to ask and it will drive our solution in how to handle this issue as we have many choices of varying degrees of difficulty. -- Greg Young, 2010

Some questions to consider include: is this a real constraint of the domain, or just an attempt at proofreading? Are we the authority for this data, or are we just storing a local copy of data that belongs to someone else? When we have conflicting information, can the computer determine whether the older or newer entry is in error? Does the business currently have a remediation process to use when the set condition doesn't hold? Can the business tolerate a conflict for some period of time (until end of day? minutes? nanoseconds?)

(In thinking about this last question, you may want to review Race Conditions Don't Exist, by Udi Dahan).

If the business requirement really is "we must never write conflicting entries into the collection", then any change you make must lock the collection against any potential conflicts. And this in turn has implications about, for example, how you can store the collection (trying to enforce a condition on a distributed collection is an expensive problem to have).

---

For the case where you can say: it makes sense to throw all of this data into a single relational database, then you might consider that the domain model is just going to make a "best effort" to avoid conflicts, and then re-enforce that with a "real" constraint in the data model.

You don't get bonus points for doing it the hard way.