How to reduce the higher time complexity brought by DDD

Peterlits Zo 0
Viewed 19

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:

enter image description here

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.

domain-driven-design
1 Answers

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.

VoiceOfUnreason0
Related