Guidance on how to design aggregates

[Sebastian P.R. Gingter]

Hi,

I am currently in the process of learning DDD, and I want to apply what I learn to a private pet project.

Now I ran into an issue where I maybe think too much in database tables, and I don't have a clue how to design that properly.

The project is about handling data from a video game. It's a space sim, and we have star systems with stellar bodies in them.

Now, for the sake of our project, we're mainly interested in certain star system where something is found. So I'd design the star system as an entity and aggregate root, together with its stellar bodies as sub-entities.

Since we have a quite tech-savvy community, someone else built an API for all the stellar data, so we would import the actual star system and body detail data from that other API. We consider the other API as the master of that data and just reference to that and keep a copy of their data for caching purposes.

The things that can be found in these star systems are so-called signal sources. Whenever we find certain signal sources, we would update the system with the type of signal source found there, so that we can update our read models that provide stellar maps (like this: https://map.canonn.technology/nhss-data.html , zoom in a bit to see individual systems).

Now, there are other points of interests (POI) in the galaxy, and some of them do not only reference a system, but are located on a certain stellar body in that system, at specific coordinates (latitude, longitude).

Some POIs just have a category, but others are more specific and have additional information on them, like alien ruins where we provide interactive ground maps for ( https://ruins.canonn.technology/ , select ruins from the list to see examples).

I would make a general POI an aggregate too, and also a Ruin, but there is the issue: I need to reference a specific body. But the body is an entity within the star system aggregate, and telling from what I learned it is a no-no to reference anything that is not an aggregate root.

This body, however, only provides its name to the full location of any POI that is located on the ground. I.e. in the system "COL 137 SECTOR AP-Q B21-2", which is a binary star system, we have three ruins on the eighth planet of the first star (A 8), and one ruin on the fourth planet of the second star (B 4). So the full "address" of a ruin would be a composite of the name of the referenced star system, the name of the referenced body plus the coordinates. Example: COL 137 SECTOR AP-Q B21-2, A 8, 13.33, -61.55.

Since we only use the name, and won't need any other information of that body, I would strongly hesitate to make it an aggregate root of its own.

So, how would you suggest to model these kind of relationships?

Break the rule, and let the POIs that are on the surface of a body hold a reference to the body id, although the body isn't an aggregate root of its own?

A process would take this information a bit later to update read model. It would then fetch the bodies name to build the location string, and also create a link to the external API source for this body i.e. https://www.edsm.net/en/system/bodies/id/9800883/name/Col+173+Sector+AP-Q+b21-2/details/idB/2214164/nameB/Col+173+Sector+AP-Q+b21-2+A+8 ).

Or is there a different way to model that?

Sorry for that wall of text, but I wanted to explain that domain a bit to help you help me ;)

Thanks in advance,

   Sebastian

[Sebastian P.R. Gingter]

Whoops. Big SORRY for the triple-post. 

It looked like google groups did not send the message, so I retried a day later and after that didn't show up too I tried with another account.

Now all three went through. :(

If you have an answer, please answer here: https://groups.google.com/forum/#!topic/dddcqrs/os6k0Zxpw0Y

This post could be deleted.