I would vote for most well described DDD terms (described in Evans book) - this would help users to adopt/understand ISIS framework easier and have a kind of reference documentation. Term 'Object' is too general, and "Business Object modelling antipatterns" are also very wide spreaded, e.g. by people like enterpise information modelling architects...
Regs, Vladimir > Am 31.12.2014 um 07:40 schrieb Dan Haywood <[email protected]>: > >> On 30 December 2014 at 23:44, David Tildesley <[email protected]> wrote: >> >> +1 for the counter proposal (although I would suggest cloning/deriving >> "@DomainObjectLayout" to "@ViewModelLayout" etc. so that "Domain*" tags are >> not used in ViewModel - less confusing). > > On a different thread to dev@ I also made a related proposal that > @Property, @Collection, @Action etc be renamed to @DomainProperty, > @DomainCollection, @DomainAction etc... the primary reason being that > clashes with @Collection clashes with java.util.Collection, plus I like the > idea of all Isis-related annotations starting with an @DomainXxx prefix. > > No one's commented on that, yet. > > Given your preference of @ViewModel and reserving "@Domain" to be strictly > for domain layer concepts, would I be right to guess you wouldn't be in > favour of adding "Domain" as a prefix to all those annotations? > > > > > > >> On Tuesday, 30 December 2014 3:07 AM, Dan Haywood < >> [email protected]> wrote: >> >> >> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < >> [email protected]> wrote: >> >>> Ok. >>> >>> So let's raise some questions/doubts :) >>> >>> *** @DomainObject *** >>> >>> Is a ViewModel a DomainObject at all ? >> it's a good question, and I've debated it myself. Let me lay out my >> thinking on this so far and see if we can collectively come to a view on >> this. >> >> First thing to note is that there are two "varieties" of view models (even >> though the implementation is identical) >> >> - those that are part of the domain layer and are, conceptually at least, >> entities, but where the persistence is managed outside of Isis. An example >> is a document in a CMS >> - those that are part of the application layer, and represent a view on top >> of one or more entities. >> >> Of course, we expect an application layer to depend on the domain layer and >> not vice versa, but even so, because some view models are conceptually >> entities I suspect that in a typical Isis application it will be reasonable >> to allow JDO-managed domain entities to interact with externally-managed >> view model entities. >> >> >> Because of this, I've been thinking of "DomainObject" as being a superset >> of both entities and view models. >> >> >> >> >>> I would consider them as a different kind, so the @ViewModel annotation >>> shouldn't be deleted. >> >> You are certainly right that quite a few of the features in @DomainObject >> don't apply to view models (even if conceptually they are entities)... >> because we rely on JDO to implement. Specifically: >> >> - auditing... requires JDO so doesn't apply to view models >> - publishing ... requires JDO so doesn't apply to view models >> - bounded = not sure... even though doesn't depend on JDO, suspect that it >> isn't supported for view models >> >> - autoComplete ... is supported for view models >> - editing ... is supported so long as the ViewModel.Cloneable interface is >> also implemented. I can foresee this restriction being lifted in the >> future >> - objectType ... is supported for view models (used as REST URLs) >> >> >> >> >> >>> Also, perhaps we can introduce Isis platform logic like not >>> "saving/persisting" view models, etc. If that would be the case, the >>> "editing" and "editingDisabledReason" at least might not have any sense. >> Not sure I understand this point. But at any rate, given that some view >> models are basically externally-managed entities, the semantics of >> "saving/persisting" would also apply. >> >> >> >> >> >>> >>> If so, I would better align with DDD naming conventions, in order to gain >>> acceptance. >>> >>> So, names should be @Entity or @DomainEntity (for avoiding name collision >>> with JPA) - instead of @DomainObject -. >> I did consider @DomainEntity, but as I say, sometimes view models act like >> entities. I do quite like it though. >> >> I have a counter-proposal, see below. >> >> >> >>> I like the @DomainService name, as it can act as a DDD Factory and/or >>> Repository. >>> >>> >>> As currently there's no "special" support for AggregateRoots or >>> ValueObjects, no more annotations are needed. >> Sounds like a vote to deprecate. Jeroen has said the same thing. Perhaps >> they should be deleted in v2.0 and reappear, if we want them back, in v3.0. >> >> >> >>> So the proposed set would be: >>> • @ViewModel and @ViewModelLayout >>> • @DomainService and @DomainServiceLayout >>> • @DomainEntity and @DomainEntityLayout >>> • @Property and @PropertyLayout >>> • @Collection and @CollectionLayout >>> • @Action and @ActionLayout >>> • @Parameter and @ParameterLayout >> Here's my counter-proposal. It's not as symmetrical as before, but perhaps >> is less confusing overall: >> >> * replace @DomainObject(viewModel=false) with >> @DomainEntity(persistence=JDO) >> ... this would be the default >> * replace @DomainObject(viewModel=true) with >> @DomainEntity(persistence=EXTERNAL) >> ... for view models representing externally-persisted entities. In the >> Javadoc, say that auditing, publishing and bounded are not supported for >> these >> * keep @ViewModel >> ... extend to include the non-entity stuff from @DomainObject that does >> apply (basically, I think that's just "objectType" ) >> ... the intention being that this is used for application-layer views. >> >> keep @DomainObjectLayout, because everything in it applies equally to both >> view models (either variety) and JDO entities. >> >> >> I'll reply on your points on @Property and @Parameter separately. >> >> Thx >> Dan >> >> >> >> >>
