I have a Transaction entity that has a unidirectional to-many relationship with a Product entity. I've made it unidirectional because I want a transaction to be associated with a product, but I don't want a product to be associated with any transactions.
I know Apple suggest that you should make relationships have inverses, but I don't think having an inverse relationship from Product to Transaction is appropriate here is it? I know I will have to manually set the deletion of the product from the Transaction if a Product is deleted, but that's fine.
Does it matter what the delete rule is for the unidirectional relationship, since it won't make any difference will it?
Thanks
You should make the inverse, even if you aren't going to directly use it. There is a reason that Apple suggests doing this:
Core Data uses this information to ensure the consistency of the
object graph if a change is made (see “Manipulating Relationships and
Object Graph Integrity”).
The question I have for you is, why wouldn't you set the inverse? If you don't want the product to be associated with Transactions, then just don't access that relationship.
Related
I am developing an online job portal using DDD patterns.
There are many "objects" that i have figured out like Users, Jobs, Roles, Expertise, ExperienceRange, Country, State, City, Address, Subscriptions, etc
My question is how do i figure out which of these is an entity or a value object or an aggregate? Please advice me if you have ever faced the same dilemma.
I have made the following decision:
Entities - User, Job, SubscriptionPackage
ValueObjects - Role, Expertise, ExperienceRange, City, State, Country
I know that we should not think about persistence while doing DDD modelling but a doubt has surfaced that whichever value objects i am storing in database should have an id or not?
if they have an id do they not violate the fundamental principal of ValueObjects and if we do not save them with ids then how to reference them in foreign key fields?
Please help me answer these queries.
If you can suggest which of the above mentioned objects are entities, which are value objects and which are aggregates that would be great.
Thanking in advance
When thinking of DDD, leave the DB mapping to a later stage. I know I'm repeating what you said, but just because it's true. A value object might have a DB id for other reasons (normalisation, reporting , etc).
First come up with your object model and then figure out how to map it. In some (rare) cases you might need to change slightly your object model if there's something that is too expensive to map properly (I cannot think of an example, but I don't want to be extremist).
So once more, forget about the DB - think about objects. For what reason does an entity have an id? I would say so then later it can be retrieved and modified, while keeping the same id.
And if it is a VO is because the identity is implicit in the values of the object. Does it make sense for a User to have an id? What about an Address? Or a City?... It depends.
To give the example of a city value object, if you need to map that as FK to 'cities' table, then your City object will probably have an id, but the id is not exposed. It's a detail of the implementation. While the user id would be exposed. For example a city might be linked to a province/state and that to a country.
But in another application, where users can add cities and information about them, the city might be an Entity or even an Aggregate. It really depends on your requirements.
Having said that, the list of Entities and VOs you provided looks ok in a general way, but I don't know your requirements.
To answer the first question: you can read Entities, Value Objects, Aggregates and Roots as there are some rules about what is a VO, Entity or Aggregate. The difficulty comes from how to apply them, and experience is the solution to that.
As a summary:
Entities
Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity.
Value Objects
Many objects have no conceptual identity. These objects describe characteristics of a thing.
Aggregates
Aggregates draw a boundary around one or more Entities. An Aggregate enforces invariants for all its Entities for any operation it supports.
I want to know whether we can update the parameter of relationship.
like food delivery, if I am having a relationship of a person and I am inheriting person and making a relationship of it
If you want to create a runtime relationship of any transactions, participants and assets than you can use the Factory(Runtime API) method. Using Factory you can create instances of Resource. you can follow this link.
I hope you get your answer.
We have a SaaS application.
There are rows in the database for Companies, Users, and Entities (generic for stuff users deal with)
So Company A controls Users A-F
Users A-C have rights to view Entity A
Users D-F have rights to view Entity B
When I create my bounded context for Entity A and its aggregate entities, should Entity A only be accessed via Company A?
I am trying to figure out where to apply the rule "only access aggregates via the aggregate root".
Where do I draw the line?
What about when Company A and Company B can both access Entity A?
The idea about aggregates is that they represent consistency boundaries. This means that it should be possible to load two different aggregates at the same time, modify both, and save them back to the DB. As soon as you make the same entity part of multiple aggregates, this is not guaranteed anymore. Reasoning about consistency and concurrency in your domain becomes a lot more difficult if you do this.
This is why an entity must belong to only one aggregate.
The solution is usually simple: Make the entity it's own aggregate. This means that you can only reference it by ID from the aggregate where it was referenced by association before. Note that this also solves your "only access aggregates via aggregate root" problem.
"Only access aggregates via the aggregate root" isn't a useful rule for aggregate design. It's only a practical byproduct of the concept of aggregate to keep in mind when programming -- if you could access any entity directly without restrictions, Aggregates would basically be useless.
When modelling you should instead look for entities that tend to change together in the same business transaction and/or must stay consistent together, and draw aggregate boundaries around those.
Chances are that no data in Company needs to be consistent with its Entities at all times and that they don't change together, so by virtue of the "keep aggregates small" recommendation, you should probably make them 2 aggregates. But only you know the invariants in your domain and can tell.
I have some big Entity. Entity has propertis "Id", "Status" and others.
I have Repository for this Entity.
I want to change status in one entity.
Should I get whole Entity, change property Status and use save method in Repository or should I use method ChangeStatus(id, newStatus) in Repository?
Probably you don't need a domain model. You could try a transaction script that directly use SQL to update the database.
You need a domain model if and only if you need to hire an expert to understand the business.
Otherwise, it's just expensive buzzwords driven development.
And btw, if you have big entity classes containing data that you don't need during most of operations, then you know that you haven't properly defined context boundaries.
The best definition of bounded context is the one of Evans:
The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently.
That is: you have to split the domain expert knowledge in contexts where each term has an unambiguous meaning and a restricted set of responsibility. If you do so, you'll obtain small types and modules with high cohesion an
I'm still wrapping my head around DDD, and one of the stumbling blocks I've encountered is in how to handle associations between separate aggregates. Say I've got one aggregate encapsulating Customers and another encapsulating Shipments.
For business reasons Shipments are their own aggregates, and yet they need to be explicitly tied to Customers. Should my Customer domain entity have a list of Shipments? If so, how do I populate this list at the repository level - given I'll have a CustomerRepository and a ShipmentRepository (one repo per aggregate)?
I'm saying 'association' rather than 'relationship' because I want to stress that this is a domain decision, not an infrastructure one - I'm designing the system from the model first.
Edit: I know I don't need to model tables directly to objects - that's the reason I'm designing the model first. At this point I don't care about the database at all - just the associations between these two aggregates.
There's no reason your ShipmentRepository can't aggregate customer data into your shipment models. Repositories do not have to have a 1-to-1 mapping with tables.
I have several repositories which combine multiple tables into a single domain model.
I think there's two levels of answering this question. At one level, the question is how do I populate the relationship between customer and shipment. I really like the "fill" semantics where your shipment repository can have a fillOrders( List customers, ....).
The other level is "how do I handle the denormalized domain models that are a part of DDD". And "Customer" is probably the best example of them all, because it simply shows up in such a lot of different contexts; almost all your processes have customer in them and the context of the customer is usually extremely varied. At max half the time you are interested in the "orders". If my understanding of the domain was perfect when starting, I'd never make a customer domain concept. But it's not, so I always end up making the Customer object. I still remember the project where I after 3 years felt that I was able to make the proper "Customer" domain model. I would be looking for the alternate and more detailed concepts that also represent the customer; PotentialCustomer, OrderingCustomer, CustomerWithOrders and probably a few others; sorry the names aren't better. I'll need some more time for that ;)
Shipment has relation many-to-one relationship with Customer.
If your are looking for the shipments of a client, add a query to your shipment repository that takes a client parameter.
In general, I don't create one-to-mane associations between entities when the many side is not limited.