Hi to all.
I'm thinking about it but still convinced of option 1 ... In my opinion, annotations are going to be "our main API". So they must be thought from the user's perspective, more than from the implementation's perspective. In that way, aligning with DDD concepts (that are the most widely spread) is more important to me than implementation criteria. So I would keep my vote for implementing: @DomainEntity @ViewModel @DomainEntityLayout @ViewModelLayout Regarding adding the "Domain" preffix to properties and collections, I think it's not needed. As Dan's exposed, they are present on any type of class (despite being a "domain" or "application" level one). As they're annotations an not classes, in my current setup (based on Apache Isis latest snapshot): - @Property does not conflict with any other annotation (i.e., no identically named annotation is present on any dependency). - @Collection does not conflict with any other annotation. - @Action clashes with the javax.xml.ws.Action annotation. - @Parameter clashes with the org.junit.runners.parammetrized.Parameter annotation. None of them can be confused with Isis ones by a junior developer. In fact, this clash conflict was already present with @Named (that it's going to be kept) and same other Apache Isis annotations without being more relevant. So my opinion would be to not add the "Domain" prefix to them. Perhaps this could also be a good moment to add a "collateral" debate :) In my head, I also associate Collections with Properties. I would consider "Simple Properties" and "Collection Properties". So perhaps naming could be instead "SimpleProperty" and "CollectionProperty" ? :-)) HTH, Oscar > El 31/12/2014, a las 12:39, Vladimir Nišević <[email protected]> escribió: > > 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 >>> >>> >>> >>> >>> Óscar Bou Bou Responsable de Producto Auditor Jefe de Certificación ISO 27001 en BSI CISA, CRISC, APMG ISO 20000, ITIL-F 902 900 231 / 620 267 520 http://www.twitter.com/oscarbou <http://www.twitter.com/oscarbou> http://es.linkedin.com/in/oscarbou <http://es.linkedin.com/in/oscarbou> http://www.GesConsultor.com <http://www.gesconsultor.com/> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
