In DDD, I want to get data of child entity of his AggregateRoot in a property of AggregateRoot and work with the data of that child entity,
But I don't know is it a good idea or not? Is it true that I access the child entity repository and get data from that in an AggregateRoot?
Advanced thanks.
For example I have 'order' AggregateRoot and it contains 'productId' and 'productType' and these properties are in AggregateRoot and came from 'product' child entity, and product has property named 'productType', how can Load data of productType in AggregateRoot?
I want to work and use data of an child entity in his AggregateRoot.
Related
I have a simple relation OneToMany parent - children. There are several operations that change the parent, and add a child. I haven't found yet a way how to do this without loading the children collection. If I don't load the children collection, then the existing children will be deleted (orphaned). No cascading or other options in the OneToMany solved this issue.
I would like to implement transactional outbox pattern using this technique, by adding events as a OneToMany relationship, so for most operations I only need to insert a child object (append only collection). But since the events list can get quite large, I don't want to load the events (eager or lazy).
Get the parent (no sub-classes needed)
In your child class, you have a #ManyToOne attribute set that equals the parent
save the child
example:
const parent:Parent = // your parent object
const child:Child = // your new child object you would like to add
chield.parent = parent
getConnection().getRepository(Child).save(child)
an eager load of the parent will return it with all the children.
I have two domain objects, a Parent and Child. A Parent can have zero or more children, and a Child can belong to zero or more parents (in case of divorced parents).
So thinking about this in the context of Domain Driven Design I'd say that both Parent and Child are an AggregateRoot. Because this is a many-to-many relationship.
Now I'm wondering how I should model this in code. I need to be able to access the parents from the Child class, but also all the children from the Parent class.
So I'm thinking about doing it like this:
public class Parent : AggregateRoot
{
public string FamilyName {get;set;}
public IList<Guid> ChildrenIds {get;set;}
}
public class Child : AggregateRoot
{
public string Name {get;set;}
public IList<Guid> ParentIds {get;set;}
}
Is it OK to have both classes reference each other via their id's?
Or is there perhaps a better way to model this?
Background info
Parents and their children can be registered in our application. Our system then keeps a log of events that that child goes through. Swimming, going to the museum etc.
For example;
a mom and her only child are registered in our application.
In the mean time events are logged to the child entity. Visited a museum, went swimming etc.
Two months later Dad needs to be registered in our system as well (coparenting). Mom and Das obviously should have a reference to the same child entity.
I need to be able to work with the following use case:
On all even weeks of the year Mom is responsible for the child.
On all uneven weeks Dad is responsible.
If something happends on an even week (Mom), then this event will be registered.
If the application later on retrieves the Dad aggregate, then he should not only get a reference of the same child as Mom, but should also see all the events that happend the week before.
So therefor a Parent can have many Children, and a Child can hsve many Parents. My problem is that I'm not sure how to model this in DDD.
When ever I have two models that reference each other I force myself to look for a missing part of my puzzle.
It sounds like your business doesn't care who is the parent of a child is, it cares who is responsible for a child at a given point in time. So its possible that looks like you are missing a 3rd domain model: Guardian (Im sure their is a better name for this) which removes the need for Parent and Child entities to explicitly reference each other.
class Guardian {
GuardianId Id {get;private set;}
ParentId ParentId {get;private set;}
ChildId ChildId {get;private set;}
List<DateRule> WhenResponsible {get;private set;}
bool IsResponsibleForChildAt(date day) {
return WhenResponisble.Any(dr=>dr.AppliesToDate(day));
}
}
Now depending on your business the Guardian model may more naturally fit inside the Child or Parent models, your domain experts should be able to help here.
I looked over the SO, but strangely didn't find similar question.
So the question is: If i have an entity called A and an entity called B, can B object have a property of type A? NOT relationship, but a property. I surely can use relationship as a property, but in my case i need an A object to have a property with type of A object. for example
Entity called Human. And a property called child which is a Human too.
Human* parent=[Nsentity....bla bla
Human* child=parent.child;
Is there a way to do this not using transformable properties? I tried non-inverse relationship to self, but it rises a warning, and im like afraid that its gonna be a mess after all. cos in my case "parent" and "child" might be exactly the same object. so parent.child might be equal to parent
The is no prevention for "self" relationships.
An entity A may have a relation (one-to-one or one-to-many) with entity A or any of its descendants (or any other entity for that matter).
Define A like so (for one-to-one relationship):
parent (reltionship with inverse A->child)
child (relationship with inverse A->parent)
You probably don't want this to be a property as CoreData will not maintain it as part of the object graph (cascade rules and such).
So I've got a Client entity that needs a relationship to a PhoneNumber entity to allow multiple phone numbers. And I've got an Employee entity that also needs a relationship to a PhoneNumber entity to allow multiple phone numbers. Should I create two separate PhoneNumber entities or can I somehow use the same entity for both?
I would create a parent entity called Person for your Client and Employee entities. The Person entity would have a relationship to the PhoneNumber entity.
Inherited entities have the same attributes and relationships as their parent entity. Of course you can add attributes and relationships to the "child"-entities as well. I omitted that in the screenshot.
Something like this:
you can configure the parent entity in the core data inspector in the right side pane.
I have a coredata model with a parent Entity type, and other Entities which are subclasses of the parent.
During runtime, I am first creating entities which are instances of the parent class.
Later on, I want to be able to specialize these entities so they become instances of the subclass. Basically I want to alter the class of entities. The change I want to make is :
entity.class = parent -> entity.class = child
Does coredata offer a way to do it cleanly, or do I have to do it manually, by removing the instance of the parent class and create an instance of the subclass, filling it with the attributes of the parent ?
Thank you for your help.
You have to create a new object of the child entity and delete the previous object. The entity of a managed object cannot be changed after the object has been created.