Hi Alain, Within... Dan
On 19 April 2013 01:23, 张峰昌 <[email protected]> wrote: > > I have read the “Apache Isis Application Library Developing domain driven > applications using Apache Isis” pdf doc, and I have a question about using > Aggregated annotation. > > Yup, there's a lot of info in there. We do intend to move it onto the Isis site as regular pages, to make it a little more discoverable. > > > Part IV Reference Appendices B.2. @Aggregated says: > > *This annotation indicates that the object is aggregated, or wholly owned, > by a root object.* > > *All value types and all collections are automatically aggregated.* > > I should say straight out that the @Aggregated annotation is currently only partly supported. It IS used by the NoSQL objectstore as a hint so that aggregated referenced entities are stored in the same json document in the store. So, for example Order ->* OrderItem, where OrderItem is @Aggregated, then those items are stored "inline" in the JSON, rather than there being references to individual OrderItem JSON docs. It's possible (I don't know for sure) that the scimpi viewer also honours @Aggregated. However, neither the JDO objectstore nor the Wicket viewer pays any particular attention to this annotation. Adam Howard (are you there, Adam?) was doing some work on porting the DDD sample, and has raised a JIRA [1] which if implemented would reduce a lot of boilerplate. > > > 1,Does it means we can’t model a collections which element type is another > root aggregate? (I have checked the tck samples, and found all the > collection child entity have no repository, maybe it implies child entity > is > not root aggregate?) > > No. To be clear, you can have a collections where the referenced entity is a root aggregate. In fact, using Wicket/JDO every entity is treated as a root, whether you like it or not. The statement in the PDF about "collections being automatically aggregated" refers to the java.util.ArrayList or java.util.TreeSet object itself; the thing that holds the references. This is intrinsically part of its owning entity, and so it is not a separate root. Which is obvious (right?) but internally in Isis we have to handle these objects. > For example in a user management application, User,Role are both root > aggregates. There exists a many to many data relationship between User and > Role. > > Is it not necessary to model User with a Collection<Role> property > according > to isis @Aggregated annotion’s advice? > Correct, you shouldn't use @Aggregated for either User or Role. > 2, Is True Invariants the unique reason to use @Aggregated? > > Vaughn says in his article: > > * When trying to discover the aggregates in a bounded context, we must > understand the model's true invariants.* > > Is it true that a user has many roles does not means there exists a “True > Invariants” between them? > > [sigh]. This is a reference to the statement in the blue DDD book about aggregates as being a unit of consistency, with the corollary that links between aggregates are not consistent. Again, this makes sense in a NoSQL context, because they don't support transactions. However, in Isis - at least if using an RDBMS - then we do have transactions, and we have isolation levels. We can rely on the RDBMS to ensure that related entities are changed in a single transaction. In Isis, then, the role of aggregates is really just a way be able to put a boundary around a bunch of objects and say: I conceptually think of these as a single object (Order/OrderItem etc). When ISIS-348 is implemented, then this would remove some boilerplate: the idea being that an @Aggregated entity would be rendered on the page not as a reference to another object but inlined. Until then, you can pretty much forget about this annotation, at least if using JDO/Wicket. HTH Dan > > > Best Regards > > Alain > > > > [1] https://issues.apache.org/jira/browse/ISIS-348
