Hi David, I think this ties in with the idea of View-Models as a representation of a domain event. Each step in a use case is te definition of a domain event - something that has happened in the domain that we are interested in.
Like entities use cases have a thread of continuity, but it is activity based related to achieving a goal. It might be useful to have an annotation that defines the use case that a view-model that participates in. Also a service to define the start and end of use case activity as events. When a use case is started the instance is given an identity. Every interaction annotated as a participant of the use case is then enriched with this identity in http headers and log messages. This would make filtering a specific use case much easier both in the system and http logs. For example, you could create a report that shows how many registrations are started but not completed, and a what stage the use abandoned. That's useful input for improving the UX. Regards, Ged On Wed, 31 Dec 2014 at 22:09, David Tildesley <[email protected]> wrote: > Hi Jeremy, > The intention of "ViewModel" is provide a Use Case specific mechanism to > aggregate/present/"cut and dice" a view of the problem domain. In this > respect it is certainly not part of the domain layer and logically belongs > the "UI" layer. It was invented as part of ISIS as the mechanism for > significantly influencing the UI. In this way, it is a departure from the > original concept of Naked Objects from which ISIS evolved, however if you > choose not to use ViewModel then you are left with the original concept of > Naked Objects and therefore ISIS remains true to Naked Objects. > The domain layer has long term enduring value to the business who paid for > the application to be built and should never depend on other layers. The > "UI" layer should be thought of as "disposable" and will mutate at a high > rate, whilst the "domain layer" should remain stable in "shape" and > independent of the other layers. There is nothing inherent about ISIS that > would give you a valid reason to ignore this architecture pattern. > If we ignore the data management layer which is no longer of significance > due to persistence frameworks like DataNucleus, JPA, Hibernate, Toplink, > etc., then there are only the traditional three layers in consideration > for the developer (if they choose not to stick to the pure Naked Objects > paradigm for user experience) and the below represents these with the > direction of dependency shown by the arrows: > UI --> PD <-- SI > Where: > UI = User Interface (system or human)*PD = Problem DomainSI = System > Integration. > * UI layer Includes both the ViewModels and the generated UI(s). Where > things got messy for ISIS was when Domain Objects in the domain layer were > required not to be locally persisted but instead required DOI based > integration with an external system (integration). The ISIS Domain Objects > were "locked" into local persistance and that was because that was where > the initial focus was (necessary because you have to get this right as > priority because this is the majority scenario). Then in this vacuum, folk > started proposing to use "ViewModel" as Domain Objects that required DOI > based external system integration because "ViewModel" was free from the > local persistance lock-in. Other proposals were also on the table (e.g roll > your own datanucleus persistance plugin) that came with their own headaches. > Option 1 then tidies this up and nothing is lost. > Speaking to Jereon's point - yes there are some "trivial" system > integrations where it is valid to bypass the PD layer and have a direct > integration from UI layer to SI layer (e.g fetch a controlled value list > from some other system) although I would say that ISIS negates the need to > do this anyway by lowering development cost. > A step in the right direction is to first sort out the semantics with > Option 1 and then later when folk feel comfortable, to have ISIS enforce > the UI --> PD dependency direction (i.e. disallow PD --> UI). > Applications should reinforce the layer separation via package naming > convention. > e.g. > com.mycompany.myapp.pd.*com.mycompany.myapp.ui.* > David. > > On Thursday, 1 January 2015 3:24 AM, "Branham, Jeremy [HR]" < > [email protected]> wrote: > > > What would it look like with @Model? > Giving more specificity than ‘Object’ but opening the interpretation to > Entities and ViewModels. > > Or am I overlooking something? [I am new to Isis] > > (fyi - there is a name clash with Model in Spring-MVC) > > > Jeremy D. Branham > Tel: **DOTNET > > From: Jeroen van der Wal [mailto:[email protected]] > Sent: Wednesday, December 31, 2014 7:37 AM > To: dev; users > Subject: Re: ISIS-970 ... (new annotations) please review if you get a > chance... > > I like this discussion because it's defining where Apache Isis is right > now. Personally I think Isis has grown far beyond the concepts of DDD so > sticking to it's grammar would limit ourselves. > > In the applications I'm developing things aren't black or white: we have > view models that represent documents in a CMIS document store but in DDD > terms they are domain entities. We have view models that are based on > entries in a database view but in DDD terms these are domain entities. We > have view models that are created on the fly and never get persisted but in > DDD terms they are domain entities. > > As you might expect I opt to simply call everything a domain object. > Residing in the application's domain object model. Very easy to explain to > newcomers too. > > Cheers, > > Jeroen > > > On Wed, Dec 31, 2014 at 1:13 PM, GESCONSULTOR - Óscar Bou < > [email protected]<mailto:[email protected]>> wrote: > 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]<mailto: > [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]< > mailto:[email protected]>>: > > > On 30 December 2014 at 23:44, David Tildesley <[email protected]<mailto: > [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]<mailto:[email protected]>> wrote: > > > On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < > [email protected]<mailto:[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 > > [cid:4C38BF6A-D280-4C7F-BFC2-4285B2033897] 902 900 231 / 620 267 520 > [cid:6DF89309-F557-4C28-BDFC-AE5B9D964612] http://www.twitter.com/ > oscarbou > > [cid:DDC0BB1F-E0FC-4120-97F8-E2D5F0DA9BC5] http://es.linkedin.com/in/ > oscarbou > > [cid:F31E93E9-D0D0-4F96-9A7C-496F094117DC] http://www.GesConsultor.com<ht > tp://www.gesconsultor.com/> > > [cid:04E888F1-A5E9-49D1-832D-465FE2C6C940] > > 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. > > > > > > > > ________________________________ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you are > not the intended recipient, please contact the sender and delete all copies > of the message. > > >
