0

I'm learning DDD and I have a question.

Suppose there is a Graph entity with associated Node and Edge entities, corresponding to the vertices and edges of the graph. A node represents some business domain process, and an edge represents the interaction between processes. There are some business logic rules. For example "Nodes has unique names in graph". And there are 2 types of operations in the application:

  1. Node and edge creation using REST API (for example POST /nodes/ and POST /edges/).
  2. Import Graph data with all nested entities.

Logically, Graph is the root aggregate, and Node and Edge should be created and modified using it. But then 2 questions arise:

  1. To implement a REST API, do I really need to read all nested graph edges (there could be about 10,000 of them) from the DB in order to create or update just 1 object and check the necessary business logic invariants?
  2. Suppose, after all, there is some kind of EdgeCreateService service created within the REST API, which performs business logic checks and creates a new record. Then, when implementing Graph import operation, you will have to process all records through this service in order to perform business logic checks and not break DRY.

It's possible to create EdgeCreateService which accepts an IRepository interface containing the necessary methods to perform business logic checks. For example, IRepository.get_nodes_by_name(...) to check the uniqueness of nodes names inside EdgeCreateService. And 2 implementations of this interface: DBRepository (for REST API) and InMemoryRepository (for import). But in this case, it turns out that the work is not done using the root aggregate. And this contradicts DDD.

Can someone tell what is the right thing to do in this case?

Improve this question
10
  • 1
    This doesn’t sound like a typical business domain. Why do you think the DDD tactical patterns are a good fit for this problem space?
    – Rik D
    Commented Dec 11, 2023 at 19:49
  • That said, it’s advised to always design at least two different models to solve the same problem. That forces you to think outside of the box and could lead to a better model than what might seem most logical at first.
    – Rik D
    Commented Dec 11, 2023 at 19:54
  • 2
    How do you intend to enforce a unique name for all nodes of a graph as a business rule, while being unwilling to look at all of the nodes (and therefore their names) when creating a new node? That's not a rhetorical question.
    – Flater
    Commented Dec 12, 2023 at 4:00
  • 2
    Does this answer your question? How to handle business rules that are "uniqueness" constraints?
    – guillaume31
    Commented Dec 14, 2023 at 9:44
  • 3
    I meant two (or more) different domain models. Don’t take for granted that Graph should be the aggregate root. Explore other ways to tackle the business problems. Btw. what you’re facing here is what Khorikov calls the DDD trilemma in his blog, it might be useful to read: enterprisecraftsmanship.com/posts/…
    – Rik D
    Commented Dec 18, 2023 at 23:11

1 Answer 1

Reset to default
1

Eventually I found this article by Vladimir Khorikov about a similar problem https://enterprisecraftsmanship.com/posts/ddd-bulk-operations/.

It partially answer my question, but solution is quite complicated.

Also this article was helpful (thanks @Rik D) https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/

Improve this answer
1
  • Please describe the content of the links you provide. In case those links die, the information might get lost.
    – Dominique
    Commented Jan 2 at 7:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.