Search Results

Search found 8 results on 1 pages for 'aggregateroot'.

Page 1/1 | 1 

• DDD/NHibernate Use of Aggregate root and impact on web design - ex. Editing children of aggregate ro

  - by pbrophy

  Hopefully, this fictitious example will illustrate my problem: Suppose you are writing a system which tracks complaints for a software product, as well as many other attributes about the product. In this case the SoftwareProduct is our aggregate root and Complaints are entities that only can exist as a child of the product. In other words, if the software product is removed from the system, so shall the complaints. In the system, there is a dashboard like web page which displays many different aspects of a single SoftwareProduct. One section in the dashboard, displays a list of Complaints in a grid like fashion, showing only some very high level information for each complaint. When an admin type user chooses one of these complaints, they are directed to an edit screen which allows them to edit the detail of a single Complaint. The question is: what is the best way for the edit screen to retrieve the single Complaint, so that it can be displayed for editing purposes? Keep in mind we have already established the SoftwareProduct as an aggregate root, therefore direct access to a Complaint should not be allowed. Also, the system is using NHibernate, so eager loading is an option, but my understanding is that even if a single Complaint is eager loaded via the SoftwareProduct, as soon as the Complaints collection is accessed the rest of the collection is loaded. So, how do you get the single Complaint through the SoftwareProduct without incurring the overhead of loading the entire Complaints collection?

  Read the article

• DDD: Aggregate Roots

  - by Mosh

  Hello, I need help with finding my aggregate root and boundary. I have 3 Entities: Plan, PlannedRole and PlannedTraining. Each Plan can include many PlannedRoles and PlannedTrainings. Solution 1: At first I thought Plan is the aggregate root because PlannedRole and PlannedTraining do not make sense out of the context of a Plan. They are always within a plan. Also, we have a business rule that says each Plan can have a maximum of 3 PlannedRoles and 5 PlannedTrainings. So I thought by nominating the Plan as the aggregate root, I can enforce this invariant. However, we have a Search page where the user searches for Plans. The results shows a few properties of the Plan itself (and none of its PlannedRoles or PlannedTrainings). I thought if I have to load the entire aggregate, it would have a lot of overhead. There are nearly 3000 plans and each may have a few children. Loading all these objects together and then ignoring PlannedRoles and PlannedTrainings in the search page doesn't make sense to me. Solution 2: I just realized the user wants 2 more search pages where they can search for Planned Roles or Planned Trainings. That made me realize they are trying to access these objects independently and "out of" the context of Plan. So I thought I was wrong about my initial design and that is how I came up with this solution. So, I thought to have 3 aggregates here, 1 for each Entity. This approach enables me to search for each Entity independently and also resolves the performance issue in solution 1. However, using this approach I cannot enforce the invariant I mentioned earlier. There is also another invariant that states a Plan can be changed only if it is of a certain status. So, I shouldn't be able to add any PlannedRoles or PlannedTrainings to a Plan that is not in that status. Again, I can't enforce this invariant with the second approach. Any advice would be greatly appreciated. Cheers, Mosh

  Read the article

• ASP.NET MVC: what mechanic returns ViewModel objects?

  - by Dr. Zim

  As I understand it, Domain Models are classes that only describe the data (aggregate roots). They are POCOs and do not reference outside libraries (nothing special). View models on the other hand are classes that contain domain model objects as well as all the interface specific objects like SelectList. A ViewModel includes using System.Web.Mvc;. A repository pulls data out of a database and feeds them to us through domain model objects. What mechanic or device creates the view model objects, populating them from a database? Would it be a factory that has database access? Would you bleed the view specific classes like System.Web.Mvc in to the Repository? Something else? For example, if you have a drop down list of cities, you would reference a SelectList object in the root of your View Model object, right next to your DomainModel reference: public class CustomerForm { public CustomerAddress address {get;set;} public SelectList cities {get;set;} } The cities should come from a database and be in the form of a select list object. The hope is that you don't create a special Repository method to extract out just the distinct cities, then create a redundant second SelectList object only so you have the right data types.

  Read the article

• DDD: Getting aggregate roots for other aggregates

  - by Ed

  I've been studying DDD for the past 2 weeks, and one of the things that really stuck out to me was how aggregate roots can contain other aggregate roots. Aggregate roots are retrieved from the repository, but if a root contains another root, does the repository have a reference to the other repository and asks it to build the subroot?

  Read the article

• DDD: Persisting aggregates

  - by Mosh

  Hello, Let's consider the typical Order and OrderItem example. Assuming that OrderItem is part of the Order Aggregate, it an only be added via Order. So, to add a new OrderItem to an Order, we have to load the entire Aggregate via Repository, add a new item to the Order object and persist the entire Aggregate again. This seems to have a lot of overhead. What if our Order has 10 OrderItems? This way, just to add a new OrderItem, not only do we have to read 10 OrderItems, but we should also re-insert all these 10 OrderItems again. (This is the approach that Jimmy Nillson has taken in his DDD book. Everytime he wants to persists an Aggregate, he clears all the child objects, and then re-inserts them again. This can cause other issues as the ID of the children are changed everytime because of the IDENTITY column in database.) I know some people may suggest to apply Unit of Work pattern at the Aggregate Root so it keeps track of what has been changed and only commit those changes. But this violates Persistence Ignorance (PI) principle because persistence logic is leaking into the Domain Model. Has anyone thought about this before? Mosh

  Read the article

• NHibernate : Root collection with an root object

  - by Daniel

  Hi, I want to track a list of root objects which are not contained by any element. I want the following pseudo code to work: IList<FavoriteItem> list = session.Linq<FavoriteItem>().ToList(); list.Add(item1); list.Add(item2); list.Remove(item3); list.Remove(item4); var item5 = list.First(i => i.Name = "Foo"); item5.Name = "Bar"; session.Save(list); This should automatically insert item1 and item2, delete item3 and item3 and update item5 (i.e. I don't want to call sesssion.SaveOrUpdate() for all items separately. Is it possible to define a pseudo entity that is not associated with a table? For example I want to define the class Favorites and map 2 collection properties of it and than I want to write code like this: var favs = session.Linq<Favorites>(); favs.FavoriteColors.Add(new FavoriteColor(...)); favs.FavoriteMovies.Add(new FavoriteMovie(...)); session.SaveOrUpdate(favs); FavoriteColors and FavoriteMovies are the only properties of the Favorites class and are of type IList and IList. I do only want to persist the these two collection properties but not the Favorites class. Any help is much appreciated.

  Read the article

• When to update audit fields? DDD

  - by user676767

  I have a Meeting Object: Meeting{id, name, time, CreatedBy, UpdatedBy} and a MeetingAssignee{id, MeetingID, EmployeeId, CreatedBy, UpdatedBy) Meeting, as Aggregate root, has a method AssignEmployee. I was about to pass in the current user to the Meeting object as I call AssignEmployee, so that it can update its audit fields accordingly. But this doesn't seem right - is it? Obviously I can keep the audit fields public and change them later - perhaps at service level? What is everyone's else preferred method for updating these fields? Please note: We are not using Nhibernate, but a custom ORM which does not have anything automatic in place. Thanks.

  Read the article

• DDD and validation of aggregate root

  - by Mik378

  Suppose an aggregate root : MailConfiguration (wrapping an AddressPart object). The AddressPart object is a simple immutable value object with some fields like senderAdress, recipentAddress (to make example simple). As being an invariant object, AddressPart should logically wrap its own Validator (by the way of external a kind of AddressValidator for respecting Single Responsibility Principle) I read some articles that claimed an aggregateRoot must validate its 'children'. However, if we follow this principle, one could create an AddressPart with an uncohesive/invalid state. What are your opinion? Should I move the collaborator AddressValidator(used in constructor so in order to validate immediately the cohesion of an AddressPart) from AddressPart and assign it to aggregateRoot (MailConfiguration) ?

  Read the article

1