Tag Info

New answers tagged

0

Q:Why objects reference each other? A:To make the model consistent and valid. Let's try to model your domain. Supplier is an aggregate. Customer is an aggregate. Suppliers are created and managed in their bounded context. In this context I can create/update/delete/enable/disable suppliers. Customers are managed in their bounded context. Any customer must ...


0

My answer is biased with Vaughn Vernon's Implementing Domain Driven Design great book (a must read) 1. Favor small aggregates. If I'm to model your domain, I would model a Directory as an aggregate and File as another aggregate. 2. Reference aggregates by ids. Therefore Directory will have a collection of FileId value objects. 3. Use factories to create ...


0

I just can't imagine why I would have two customer objects representing the same customer, and in any case where I did (e.g. took a clone to do something with it), I can't think of any circumstances where I would need to check if it was equal to the orginal object. This can easily happen: You read a list of objects from somewhere (e.g., from the ...


0

As far as the structure, it seems OK to me although I would have come up with different, more self-descriptive names, such as "YourProjectWebApi" instead of "Base", "Dal.External" instead of "Dal.Services" and so on. There might be a smell in the "internal DTO" part though, as you're supposed to get entities out of repositories and be able to take domain ...


1

This folder structure is inspired by the famous Implementing domain driven design book by Vaugh Vernon. Solution: ├ WebService (REST Services reside here) ├ WebServiceTests ├ Application (Application services reside here) ├ ApplicationTests ├ Domain (Entities, VO, Domain services, domain factories, specifications, domain events, Repositories interfaces, ...


1

Sometimes an object doesn't use it's own relationships. A customer doesn't always use it's supplier in code, but others do want to use it. And by putting the relation in your domain model, you allow easy and quick access to this relationship. When you hardly use the relationship it could be better to request the supplier from the repository. But you also ...


-1

There is a relationship that a supplier can have many customers, and a customer (in this case) can only have one supplier. Surely there's a business-driven reason for you to say that. Why is it necessary for a customer to only have one supplier? Is there some crucial invariant you need to enforce? Is there something you can do to a supplier which will ...


-1

This would be an example of a transitive association, through an association object like an order or invoice that references both Customers and Suppliers. If you have no such objects then your model is probably incomplete or decomposed beyond the point of usefulness.


0

If code is what you're struggling with, find the reason it's there. If there's no valid reason to be found, get rid of the code and write code that has a reason to be there. Your question is showing a list of self-inflicted problems caused by the usage of a pattern which might have solved a couple of problems but introduced a lot more, most of them technical ...


0

1) I wouldn't say that. DDD is good for complex systems (which may mean, anything more sophisticated than CRUD). Domain logic can be very complex regardless of its share in the system compared to query logic. 2) I see two ways of adressing this. One is limit aggregate size. Small aggregates are less prone to bloated, slow data loading. The other is separate ...


1

First, I would ensure each entity has reference to DomainRaiser. It would be best if this was set when the entity is created or materialized in repository. Each user/request context would have it's own instance which would then be injected into all entities, that are worked by the context. I don't know what Repository/UnitOfWork implementation are you using, ...


1

If you use the fluent mapping API doing: HasMany(x => x.Products); Should be sufficient to create the foreign key relationship between User and Product without needed the UserId property to be specified on Product. Also note that EF can map data to private properties(and use private ctors and setters) so if a detail like that was absolutely ...



Top 50 recent answers are included