Skip to main content

Timeline for DDD concept and bulk create

Current License: CC BY-SA 4.0

15 events
when toggle format what by license comment
Dec 27, 2023 at 8:35 answer added Denis Nikanorov timeline score: 1
Dec 21, 2023 at 13:27 comment added Denis Nikanorov @RikD thanks for link! Seem there is no "right" answer to this question..
Dec 19, 2023 at 12:34 comment added guillaume31 @DenisNikanorov The additional invariants you mentioned probably belong more at the Node level or in a domain service than at the Graph level. Also, graphs being a well-studied computer science subject matter, there is probably already a proven optimal way to do it. As the first comment suggests, DDD might not be the right tool for the job here.
Dec 18, 2023 at 23:11 comment added Rik D 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/…
Dec 18, 2023 at 8:09 comment added Denis Nikanorov @guillaume31 thanks for link, but it does not answer my question. I wrote about checking uniqueness as an example and to shorten the question. In this application, there are more complex rules, for example that between two nodes there cannot be edges of the same type (type is an attribute of edges) or, for example, that when creating an edge with a certain type, you must also create an edge with the opposite direction and the certain type. I added some information to the question about what vertices and edges are. I am limited by NDA, unfortunately.
Dec 18, 2023 at 8:06 history edited Denis Nikanorov CC BY-SA 4.0
added 106 characters in body
Dec 18, 2023 at 7:37 comment added Denis Nikanorov @Flater I forgot to add that currently import occurs with the creation of a new graph. That is, to answer your question, during import, uniqueness can only be checked using the data that is in the import file.
Dec 18, 2023 at 7:33 comment added Denis Nikanorov @RikD 1. I have greatly simplified the description of the domain so that the question is brief and so as not to reveal what may fall under the NDA. In reality, there are more rules, as well as entities. The described entities are key to the project and business problems are solved with their help. 2. Could you clarify your point about the "two models"? Are you suggesting to duplicate validation of business rules in REST API service and in import service?
Dec 14, 2023 at 10:01 review Close votes
Dec 30, 2023 at 3:02
Dec 14, 2023 at 9:44 comment added guillaume31 Does this answer your question? How to handle business rules that are "uniqueness" constraints?
Dec 12, 2023 at 4:00 comment added Flater 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.
Dec 11, 2023 at 19:54 comment added Rik D 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.
Dec 11, 2023 at 19:49 comment added Rik D 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?
S Dec 11, 2023 at 17:06 review First questions
Dec 12, 2023 at 8:19
S Dec 11, 2023 at 17:06 history asked Denis Nikanorov CC BY-SA 4.0