You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Jeroen van der Wal <je...@stromboli.it> on 2014/12/31 14:37:09 UTC
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 <
o.bou@gesconsultor.com> 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ć <vn...@gmail.com>
> 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 <da...@haywood-associates.co.uk>:
>
> On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz> 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 <
> dan@haywood-associates.co.uk> wrote:
>
>
> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
> o.bou@gesconsultor.com> 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://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.
>
>
>
>
>
>
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Ged Byrne <ge...@gmail.com>.
It seems here that the key question is 'what is a View-Model in DDD terms'?
They are not entities - they do not have Identity and a thread of
continuity although they may expose the properties of entities that do.
The are not value objects - they are not immutable.
I would argue that View-Models are actually a way of allowing the user to
define a domain event.
>From the DDD Pattern:
"Model information about activity in the domain as a series of discrete
events. Represent each event as a domain object. These are distinct from
system events that reflect activity within the software itself, although
often a system event is associated with a domain event, either as part of a
response to the domain event or as a way of carrying information about the
domain event into the system.
"A domain event is a full-fledged part of the domain model, a
representation of something that happened in the domain. Ignore irrelevant
domain activity while making explicit the events that the domain experts
want to track or be notified of, or which are associated with state change
in the other model objects"
https://domainlanguage.com/ddd/patterns/DDD_Reference_2011-01-31.pdf
As Jeroen says, these are domain objects. I would argue that the purpose
of these domain objects is to represent activity in the domain.
View-models are a mechanism to make information about domain activity
available while filtering out irrelevant detail.
The requesting of the view-model and the submitting of data are both
system-events, but the purpose they serve is to carry information about the
domain events between the user and the system.
Any thoughts?
Regards,
Ged
On Wed Dec 31 2014 at 13:38:19 Jeroen van der Wal <je...@stromboli.it>
wrote:
> 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
>
>
Re: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
Hi Jeremy,
That's correct.
Regards,David.
On Thursday, 1 January 2015 11:48 AM, "Branham, Jeremy [HR]" <Je...@sprint.com> wrote:
At least it wasn’t DOA =]
That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
Do I understand this correctly?
Jeremy D. Branham
Tel: **DOTNET
-----Original Message-----
From: David Tildesley [mailto:davotnz@yahoo.co.nz]
Sent: Wednesday, December 31, 2014 4:36 PM
To: dev@isis.apache.org; users@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
________________________________
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.
Re: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
Hi Jeremy,
That's correct.
Regards,David.
On Thursday, 1 January 2015 11:48 AM, "Branham, Jeremy [HR]" <Je...@sprint.com> wrote:
At least it wasn’t DOA =]
That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
Do I understand this correctly?
Jeremy D. Branham
Tel: **DOTNET
-----Original Message-----
From: David Tildesley [mailto:davotnz@yahoo.co.nz]
Sent: Wednesday, December 31, 2014 4:36 PM
To: dev@isis.apache.org; users@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
________________________________
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.
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
After David's explanations I've started favoring option 1) (i.e. separate
annotations for ViewModel).
I am not into DDD (yet!) and I haven't seen a simple and clear example of
ViewModel in action, so I cannot still visualize it in my head.
I understand Dan's suggestion to make everyone happy by supporting two ways
to define the same but adding to the mix "implements ViewModel" (see
org.apache.isis.applib.ViewModel vs.
org.apache.isis.applib.annotation.ViewModel) makes it even harder for me to
decide which approach would be the best for my future use cases.
Assuming we have a @DomainObject with 3 natures (jdo, external and
view_model) then what would be the expected behavior of:
@DomainObject(nature=jdo)
public class Foo implements ViewModel, ... { ... }
?
I guess the metamodel validation should tell me that I'm doing something
fishy here ?! Is there such validation in Isis runtime now ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sat, Jan 3, 2015 at 8:44 PM, GESCONSULTOR <o....@gesconsultor.com> wrote:
> Good consensus for me also :)
>
>
>
> > El 3/1/2015, a las 18:48, Branham, Jeremy [HR] <
> Jeremy.D.Branham@sprint.com> escribió:
> >
> > This is a good compromise IMHO.
> >
> >
> > Jeremy D. Branham
> > Tel: **DOTNET
> >
> >
> > -----Original Message-----
> > From: Dan Haywood [mailto:dan@haywood-associates.co.uk]
> > Sent: Saturday, January 03, 2015 7:27 AM
> > To: users
> > Cc: dev@isis.apache.org
> > Subject: Re: ISIS-970 ... (new annotations) please review if you get a
> chance...
> >
> >> On 3 January 2015 at 13:14, Jeroen van der Wal <je...@stromboli.it>
> wrote:
> >>
> >>
> >> I have one more thought: since @ViewModel and
> >> @DomainObject(nature=UI_VIEW) are the same concepts it might be more
> >> intuitive to use
> >> @DomainObject(nature=VIEW_MODEL)
> >
> > Yes, that probably does make sense; we are just providing two equivalent
> syntaxes for describing a (UI) view model.
> >
> > So the revised proposal is:
> >
> > for the UI/app layer, retain/introduce:
> > * @ViewModel
> > * @ViewModelLayout
> >
> > for the domain layer:
> > * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | VIEW_MODEL)
> > * @DomainObjectLayout
> >
> > for both:
> > * @Property(domainEvent=..., ) and @PropertyLayout
> > * @Collection(domainEvent=..., ) and @CollectionLayout
> > * @Action(domainEvent=..., ) and @ActionLayout
> > * @Parameter and @ParameterLayout
> >
> > where @ViewModel and @DomainObject(nature=VIEW_MODEL) are basically
> equivalent; choose whichever notation you prefer (and use a metamodel
> validator to exclude the other).
> >
> >
> > thx
> > Dan
> >
> > ________________________________
> >
> > 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.
>
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
After David's explanations I've started favoring option 1) (i.e. separate
annotations for ViewModel).
I am not into DDD (yet!) and I haven't seen a simple and clear example of
ViewModel in action, so I cannot still visualize it in my head.
I understand Dan's suggestion to make everyone happy by supporting two ways
to define the same but adding to the mix "implements ViewModel" (see
org.apache.isis.applib.ViewModel vs.
org.apache.isis.applib.annotation.ViewModel) makes it even harder for me to
decide which approach would be the best for my future use cases.
Assuming we have a @DomainObject with 3 natures (jdo, external and
view_model) then what would be the expected behavior of:
@DomainObject(nature=jdo)
public class Foo implements ViewModel, ... { ... }
?
I guess the metamodel validation should tell me that I'm doing something
fishy here ?! Is there such validation in Isis runtime now ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sat, Jan 3, 2015 at 8:44 PM, GESCONSULTOR <o....@gesconsultor.com> wrote:
> Good consensus for me also :)
>
>
>
> > El 3/1/2015, a las 18:48, Branham, Jeremy [HR] <
> Jeremy.D.Branham@sprint.com> escribió:
> >
> > This is a good compromise IMHO.
> >
> >
> > Jeremy D. Branham
> > Tel: **DOTNET
> >
> >
> > -----Original Message-----
> > From: Dan Haywood [mailto:dan@haywood-associates.co.uk]
> > Sent: Saturday, January 03, 2015 7:27 AM
> > To: users
> > Cc: dev@isis.apache.org
> > Subject: Re: ISIS-970 ... (new annotations) please review if you get a
> chance...
> >
> >> On 3 January 2015 at 13:14, Jeroen van der Wal <je...@stromboli.it>
> wrote:
> >>
> >>
> >> I have one more thought: since @ViewModel and
> >> @DomainObject(nature=UI_VIEW) are the same concepts it might be more
> >> intuitive to use
> >> @DomainObject(nature=VIEW_MODEL)
> >
> > Yes, that probably does make sense; we are just providing two equivalent
> syntaxes for describing a (UI) view model.
> >
> > So the revised proposal is:
> >
> > for the UI/app layer, retain/introduce:
> > * @ViewModel
> > * @ViewModelLayout
> >
> > for the domain layer:
> > * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | VIEW_MODEL)
> > * @DomainObjectLayout
> >
> > for both:
> > * @Property(domainEvent=..., ) and @PropertyLayout
> > * @Collection(domainEvent=..., ) and @CollectionLayout
> > * @Action(domainEvent=..., ) and @ActionLayout
> > * @Parameter and @ParameterLayout
> >
> > where @ViewModel and @DomainObject(nature=VIEW_MODEL) are basically
> equivalent; choose whichever notation you prefer (and use a metamodel
> validator to exclude the other).
> >
> >
> > thx
> > Dan
> >
> > ________________________________
> >
> > 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.
>
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
For me also. It is a good consensus.
Thanks,
David.
Sent from Yahoo Mail on Android
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
For me also. It is a good consensus.
Thanks,
David.
Sent from Yahoo Mail on Android
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Good consensus for me also :)
> El 3/1/2015, a las 18:48, Branham, Jeremy [HR] <Je...@sprint.com> escribió:
>
> This is a good compromise IMHO.
>
>
> Jeremy D. Branham
> Tel: **DOTNET
>
>
> -----Original Message-----
> From: Dan Haywood [mailto:dan@haywood-associates.co.uk]
> Sent: Saturday, January 03, 2015 7:27 AM
> To: users
> Cc: dev@isis.apache.org
> Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
>
>> On 3 January 2015 at 13:14, Jeroen van der Wal <je...@stromboli.it> wrote:
>>
>>
>> I have one more thought: since @ViewModel and
>> @DomainObject(nature=UI_VIEW) are the same concepts it might be more
>> intuitive to use
>> @DomainObject(nature=VIEW_MODEL)
>
> Yes, that probably does make sense; we are just providing two equivalent syntaxes for describing a (UI) view model.
>
> So the revised proposal is:
>
> for the UI/app layer, retain/introduce:
> * @ViewModel
> * @ViewModelLayout
>
> for the domain layer:
> * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | VIEW_MODEL)
> * @DomainObjectLayout
>
> for both:
> * @Property(domainEvent=..., ) and @PropertyLayout
> * @Collection(domainEvent=..., ) and @CollectionLayout
> * @Action(domainEvent=..., ) and @ActionLayout
> * @Parameter and @ParameterLayout
>
> where @ViewModel and @DomainObject(nature=VIEW_MODEL) are basically equivalent; choose whichever notation you prefer (and use a metamodel validator to exclude the other).
>
>
> thx
> Dan
>
> ________________________________
>
> 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.
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Good consensus for me also :)
> El 3/1/2015, a las 18:48, Branham, Jeremy [HR] <Je...@sprint.com> escribió:
>
> This is a good compromise IMHO.
>
>
> Jeremy D. Branham
> Tel: **DOTNET
>
>
> -----Original Message-----
> From: Dan Haywood [mailto:dan@haywood-associates.co.uk]
> Sent: Saturday, January 03, 2015 7:27 AM
> To: users
> Cc: dev@isis.apache.org
> Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
>
>> On 3 January 2015 at 13:14, Jeroen van der Wal <je...@stromboli.it> wrote:
>>
>>
>> I have one more thought: since @ViewModel and
>> @DomainObject(nature=UI_VIEW) are the same concepts it might be more
>> intuitive to use
>> @DomainObject(nature=VIEW_MODEL)
>
> Yes, that probably does make sense; we are just providing two equivalent syntaxes for describing a (UI) view model.
>
> So the revised proposal is:
>
> for the UI/app layer, retain/introduce:
> * @ViewModel
> * @ViewModelLayout
>
> for the domain layer:
> * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | VIEW_MODEL)
> * @DomainObjectLayout
>
> for both:
> * @Property(domainEvent=..., ) and @PropertyLayout
> * @Collection(domainEvent=..., ) and @CollectionLayout
> * @Action(domainEvent=..., ) and @ActionLayout
> * @Parameter and @ParameterLayout
>
> where @ViewModel and @DomainObject(nature=VIEW_MODEL) are basically equivalent; choose whichever notation you prefer (and use a metamodel validator to exclude the other).
>
>
> thx
> Dan
>
> ________________________________
>
> 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.
RE: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by "Branham, Jeremy [HR]" <Je...@sprint.com>.
This is a good compromise IMHO.
Jeremy D. Branham
Tel: **DOTNET
-----Original Message-----
From: Dan Haywood [mailto:dan@haywood-associates.co.uk]
Sent: Saturday, January 03, 2015 7:27 AM
To: users
Cc: dev@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
On 3 January 2015 at 13:14, Jeroen van der Wal <je...@stromboli.it> wrote:
>
> I have one more thought: since @ViewModel and
> @DomainObject(nature=UI_VIEW) are the same concepts it might be more
> intuitive to use
> @DomainObject(nature=VIEW_MODEL)
>
>
Yes, that probably does make sense; we are just providing two equivalent syntaxes for describing a (UI) view model.
So the revised proposal is:
for the UI/app layer, retain/introduce:
* @ViewModel
* @ViewModelLayout
for the domain layer:
* @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | VIEW_MODEL)
* @DomainObjectLayout
for both:
* @Property(domainEvent=..., ) and @PropertyLayout
* @Collection(domainEvent=..., ) and @CollectionLayout
* @Action(domainEvent=..., ) and @ActionLayout
* @Parameter and @ParameterLayout
where @ViewModel and @DomainObject(nature=VIEW_MODEL) are basically equivalent; choose whichever notation you prefer (and use a metamodel validator to exclude the other).
thx
Dan
________________________________
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.
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Mike Burton <mi...@mycosystems.co.uk>.
Sounds good.
Mike
> On 3 Jan 2015, at 13:27, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>> On 3 January 2015 at 13:14, Jeroen van der Wal <je...@stromboli.it> wrote:
>>
>>
>> I have one more thought: since @ViewModel and @DomainObject(nature=UI_VIEW)
>> are the same concepts it might be more intuitive to use
>> @DomainObject(nature=VIEW_MODEL)
>
> Yes, that probably does make sense; we are just providing two equivalent
> syntaxes for describing a (UI) view model.
>
> So the revised proposal is:
>
> for the UI/app layer, retain/introduce:
> * @ViewModel
> * @ViewModelLayout
>
> for the domain layer:
> * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | VIEW_MODEL)
> * @DomainObjectLayout
>
> for both:
> * @Property(domainEvent=..., ) and @PropertyLayout
> * @Collection(domainEvent=..., ) and @CollectionLayout
> * @Action(domainEvent=..., ) and @ActionLayout
> * @Parameter and @ParameterLayout
>
> where @ViewModel and @DomainObject(nature=VIEW_MODEL) are basically
> equivalent; choose whichever notation you prefer (and use a metamodel
> validator to exclude the other).
>
>
> thx
> Dan
RE: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by "Branham, Jeremy [HR]" <Je...@sprint.com>.
This is a good compromise IMHO.
Jeremy D. Branham
Tel: **DOTNET
-----Original Message-----
From: Dan Haywood [mailto:dan@haywood-associates.co.uk]
Sent: Saturday, January 03, 2015 7:27 AM
To: users
Cc: dev@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
On 3 January 2015 at 13:14, Jeroen van der Wal <je...@stromboli.it> wrote:
>
> I have one more thought: since @ViewModel and
> @DomainObject(nature=UI_VIEW) are the same concepts it might be more
> intuitive to use
> @DomainObject(nature=VIEW_MODEL)
>
>
Yes, that probably does make sense; we are just providing two equivalent syntaxes for describing a (UI) view model.
So the revised proposal is:
for the UI/app layer, retain/introduce:
* @ViewModel
* @ViewModelLayout
for the domain layer:
* @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | VIEW_MODEL)
* @DomainObjectLayout
for both:
* @Property(domainEvent=..., ) and @PropertyLayout
* @Collection(domainEvent=..., ) and @CollectionLayout
* @Action(domainEvent=..., ) and @ActionLayout
* @Parameter and @ParameterLayout
where @ViewModel and @DomainObject(nature=VIEW_MODEL) are basically equivalent; choose whichever notation you prefer (and use a metamodel validator to exclude the other).
thx
Dan
________________________________
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.
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 3 January 2015 at 13:14, Jeroen van der Wal <je...@stromboli.it> wrote:
>
> I have one more thought: since @ViewModel and @DomainObject(nature=UI_VIEW)
> are the same concepts it might be more intuitive to use
> @DomainObject(nature=VIEW_MODEL)
>
>
Yes, that probably does make sense; we are just providing two equivalent
syntaxes for describing a (UI) view model.
So the revised proposal is:
for the UI/app layer, retain/introduce:
* @ViewModel
* @ViewModelLayout
for the domain layer:
* @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | VIEW_MODEL)
* @DomainObjectLayout
for both:
* @Property(domainEvent=..., ) and @PropertyLayout
* @Collection(domainEvent=..., ) and @CollectionLayout
* @Action(domainEvent=..., ) and @ActionLayout
* @Parameter and @ParameterLayout
where @ViewModel and @DomainObject(nature=VIEW_MODEL) are basically
equivalent; choose whichever notation you prefer (and use a metamodel
validator to exclude the other).
thx
Dan
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 3 January 2015 at 13:14, Jeroen van der Wal <je...@stromboli.it> wrote:
>
> I have one more thought: since @ViewModel and @DomainObject(nature=UI_VIEW)
> are the same concepts it might be more intuitive to use
> @DomainObject(nature=VIEW_MODEL)
>
>
Yes, that probably does make sense; we are just providing two equivalent
syntaxes for describing a (UI) view model.
So the revised proposal is:
for the UI/app layer, retain/introduce:
* @ViewModel
* @ViewModelLayout
for the domain layer:
* @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | VIEW_MODEL)
* @DomainObjectLayout
for both:
* @Property(domainEvent=..., ) and @PropertyLayout
* @Collection(domainEvent=..., ) and @CollectionLayout
* @Action(domainEvent=..., ) and @ActionLayout
* @Parameter and @ParameterLayout
where @ViewModel and @DomainObject(nature=VIEW_MODEL) are basically
equivalent; choose whichever notation you prefer (and use a metamodel
validator to exclude the other).
thx
Dan
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Jeroen van der Wal <je...@stromboli.it>.
Thank you Dan for your excellent recap and proposal.
I have one more thought: since @ViewModel and @DomainObject(nature=UI_VIEW)
are the same concepts it might be more intuitive to use
@DomainObject(nature=VIEW_MODEL)
On Sat, Jan 3, 2015 at 1:27 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> On 3 January 2015 at 12:16, GESCONSULTOR <o....@gesconsultor.com> wrote:
>
> >
> >
> > Just some thoughts. i don't see compatible an option called "UI_VIEW" in
> a
> > "domain" object.
> >
> > Perhaps just "VIEW"?
> >
> >
> The reason I'm suggesting UI_VIEW is that (as you stated yourself) "VIEW"
> is overloaded.... it might refer to a UI/app-layer view on top of the
> problem domain, or it might refer to a proxy on top of some externally
> managed entity.
>
>
>
>
> If that's the case, what would differentiate it from a @ViewModel?
> >
> >
>
> Nothing; it's the same concept.
>
> In other words, my proposal is that we allow a UI-layer view model to be
> expressed either as @ViewModel or as @DomainObject(nature=UI_VIEW).
>
> Both are supported out-of-the-box in Isis, but we expect that any given
> project/developer will only use one or the other. It's a matter of
> personal preference.
>
> Then, the new Isis Maven plugin plus metamodel validators can be used to
> enforce this preference in the build pipeline.
>
> Hope that helps clarify the proposal
>
> Dan
>
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Jeroen van der Wal <je...@stromboli.it>.
Thank you Dan for your excellent recap and proposal.
I have one more thought: since @ViewModel and @DomainObject(nature=UI_VIEW)
are the same concepts it might be more intuitive to use
@DomainObject(nature=VIEW_MODEL)
On Sat, Jan 3, 2015 at 1:27 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> On 3 January 2015 at 12:16, GESCONSULTOR <o....@gesconsultor.com> wrote:
>
> >
> >
> > Just some thoughts. i don't see compatible an option called "UI_VIEW" in
> a
> > "domain" object.
> >
> > Perhaps just "VIEW"?
> >
> >
> The reason I'm suggesting UI_VIEW is that (as you stated yourself) "VIEW"
> is overloaded.... it might refer to a UI/app-layer view on top of the
> problem domain, or it might refer to a proxy on top of some externally
> managed entity.
>
>
>
>
> If that's the case, what would differentiate it from a @ViewModel?
> >
> >
>
> Nothing; it's the same concept.
>
> In other words, my proposal is that we allow a UI-layer view model to be
> expressed either as @ViewModel or as @DomainObject(nature=UI_VIEW).
>
> Both are supported out-of-the-box in Isis, but we expect that any given
> project/developer will only use one or the other. It's a matter of
> personal preference.
>
> Then, the new Isis Maven plugin plus metamodel validators can be used to
> enforce this preference in the build pipeline.
>
> Hope that helps clarify the proposal
>
> Dan
>
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 3 January 2015 at 12:16, GESCONSULTOR <o....@gesconsultor.com> wrote:
>
>
> Just some thoughts. i don't see compatible an option called "UI_VIEW" in a
> "domain" object.
>
> Perhaps just "VIEW"?
>
>
The reason I'm suggesting UI_VIEW is that (as you stated yourself) "VIEW"
is overloaded.... it might refer to a UI/app-layer view on top of the
problem domain, or it might refer to a proxy on top of some externally
managed entity.
If that's the case, what would differentiate it from a @ViewModel?
>
>
Nothing; it's the same concept.
In other words, my proposal is that we allow a UI-layer view model to be
expressed either as @ViewModel or as @DomainObject(nature=UI_VIEW).
Both are supported out-of-the-box in Isis, but we expect that any given
project/developer will only use one or the other. It's a matter of
personal preference.
Then, the new Isis Maven plugin plus metamodel validators can be used to
enforce this preference in the build pipeline.
Hope that helps clarify the proposal
Dan
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 3 January 2015 at 12:16, GESCONSULTOR <o....@gesconsultor.com> wrote:
>
>
> Just some thoughts. i don't see compatible an option called "UI_VIEW" in a
> "domain" object.
>
> Perhaps just "VIEW"?
>
>
The reason I'm suggesting UI_VIEW is that (as you stated yourself) "VIEW"
is overloaded.... it might refer to a UI/app-layer view on top of the
problem domain, or it might refer to a proxy on top of some externally
managed entity.
If that's the case, what would differentiate it from a @ViewModel?
>
>
Nothing; it's the same concept.
In other words, my proposal is that we allow a UI-layer view model to be
expressed either as @ViewModel or as @DomainObject(nature=UI_VIEW).
Both are supported out-of-the-box in Isis, but we expect that any given
project/developer will only use one or the other. It's a matter of
personal preference.
Then, the new Isis Maven plugin plus metamodel validators can be used to
enforce this preference in the build pipeline.
Hope that helps clarify the proposal
Dan
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Hi Dan!
Thanks for this proposal.
Just some thoughts. i don't see compatible an option called "UI_VIEW" in a "domain" object.
Perhaps just "VIEW"?
If that's the case, what would differentiate it from a @ViewModel?
That said, it would keep "JDO_ENTITY", "EXTERNAL_ENTITY" (I love that concept :).
Regarding the "VIEW" option, if implementation is nearly the same as @ViewModel the only reason to keep it would be the consensus. So it ok for me.
If that wouldn't be introduced, the only options available would "JDO_ENTITY" and "EXTERNAL_ENTITY" given as a clear indication that the annotation could be named @DomainEntity ... :))
What a pity!!!
> El 3/1/2015, a las 12:59, Dan Haywood <da...@haywood-associates.co.uk> escribió:
>
> Folks,
>
> Thank you all so much for your contributions to this thread and also one I
> created on users@isis.a.o [1], discussing simplified a new set of
> annotations, as suggested in ISIS-970 [2].
>
> I've decided to continue the discussion on this thread as it's hosted most
> of the conversation to date. If you reply then please include both users@
> and dev@ so both users and contributors are kept in the loop.
>
> ~~~~~
> It seems to me that there's no clear consensus as to what set of
> annotations we should go with; any decision will be seen as not ideal by at
> least some users. The most debate has been about whether to retain
> @ViewModel, or whether or not to merge it into @DomainObject.
>
> Oscar, David, Ahmed, Vladimir, Jeremy and Mike all (I think) expressed a
> preference for retaining @ViewModel. Jeroen, Martin, Kevin and I all
> preferred removing @ViewModel and merging it into @DomainObject (though
> some of those opinions were made prior to the spirited debate that
> followed, so I don't know if anyone in this second list has revised their
> opinion).
>
> If @ViewModel is retained, then there was a subsidiary idea as to whether
> to replace @DomainObject with @DomainEntity (so it would be @ViewModel and
> @DomainEntity). One or two have been in favour of that idea, but it's not
> had overwhelming endorsement.
>
> Ged offered the opinion that a view model is more like a domain event. No
> one else replied to that idea. For myself, I don't think that's correct,
> but it got me thinking. Rather, domain events are what we emit through the
> (current) @ActionInteraction/@PropertyInteraction/@CollectionInteraction
> annotations. In ISIS-970 I proposed replacing @ActionInteraction with
> @Action(interaction=...) etc. Ged's mention of domain events makes me
> think it should instead be @Action(domainEvent=...). I've updated the
> JIRA ticket accordingly.
>
> I also made a proposal about adding "Domain" as a prefix to @Property,
> @Collection, @Action... but no-one seems particularly in favour of that.
>
> ~~~
> Before I go onto my own proposal for resolving this debate, let me just
> remind everyone that in Isis it's possible to write metamodel validators.
> We use these to check for no orphaned methods such as disableXxx(); I'm
> sure many will have encountered this. But it's also possible to write and
> register your own metamodel validators via isis.properties.
>
> Also, for Isis 1.8.0 we'll be releasing an Isis Maven plugin that allows
> the metamodel validation to be performed as part of the build, rather than
> rely on running up the app or its integration tests. There's an example of
> this in the simpleapp example [3] (and thus, will be part of the 1.8.0
> archetype).
>
> I mention this because it opens up the concept of "dialects" of the Isis
> programming model, enforceable through the build pipeline. Out-of-the-box
> Isis can provide support for all dialects, but individual projects can
> constrain these by registering appropriate metamodel validators as they see
> fit.
>
> ~~~
> So, my proposal is as follows:
>
> for the UI/app layer, retain/introduce:
> * @ViewModel
> * @ViewModelLayout
>
> for the domain layer:
> * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | UI_VIEW)
> * @DomainObjectLayout
>
> for both:
> * @Property(domainEvent=..., ) and @PropertyLayout
> * @Collection(domainEvent=..., ) and @CollectionLayout
> * @Action(domainEvent=..., ) and @ActionLayout
> * @Parameter and @ParameterLayout
>
> Those that want to draw explicit attention to UI/app layer view models
> should use @ViewModel, and should ignore @DomainObject(nature=UI_VIEW).
> These folks might want to use a metamodel validator to ensure that
> @DomainObject(nature=UI_VIEW) is not used anywhere in their codebase.
>
> Conversely, those that consider that its all just "domain objects" should
> ignore @ViewModel, and instead use @DomainObject(nature=UI_VIEW). These
> folks might want to use a metamodel validator to ensure that @ViewModel is
> not used anywhere in their codebase.
>
> The @DomainObject(nature=JDO_ENTITY) is for regular Isis managed/persisted
> entities, while @DomainObject(nature=EXTERNAL_ENTITY) is for entities that
> are managed by some external system. Internally Isis installs a
> ViewModelFacet for these so that it knows how to manage their ongoing
> identity (in essence corresponding to the external system's URI for that
> entity), but that's an implementation detail.
>
> @ViewModelLayout and @DomainObjectLayout are basically identical.
>
> The above proposal does NOT include the introduction of @DomainEntity.
>
> ~~~
> Opinions? I'm kinda hoping this will get us to some sort of consensus ...
>
> Thanks
> Dan
>
> [1] http://isis.markmail.org/thread/ng22jsmxeq55ewny
> [2] https://issues.apache.org/jira/browse/ISIS-970
> [3]
> https://github.com/apache/isis/blob/a5b728f0606fa12c254ca1a0ecd49b88b816d6df/example/application/simpleapp/dom/pom.xml#L136
>
>
>> On 3 January 2015 at 11:23, David Tildesley <da...@yahoo.co.nz> wrote:
>>
>> Hi Oscar,
>> Seems to me it's the same thing:
>> Let me add some clarity to that DDD example you shared:
>> Port ---> Domain Model <---Adapter
>> is just a different set of terms for the same layers:
>> User Interface --> Problem Domain <--- System Interface
>> Chaining applications together in an integration you get Adapter "A" of
>> AppA calling Port "B" of AppB and so on - which I am guessing is what you
>> meant by "Inter Domain".
>> Clearly ViewModel fits into "Port" quite nicely. In fact it's the only
>> place it belongs.
>> But "Intra Domain"? Does ISIS in some way prevent a domain object calling
>> another domain object's operation directly? Anyway I suspect that's a
>> separate discussion.
>> The bottom line is that we can't stop people bleeding domain model
>> behaviour out into viewmodels, however what we can do is to make it as
>> clear and unambiguous as possible by avoiding/reducing overloading of
>> terms/concepts and suggesting the correct approach to building an
>> application.
>> My single piece of advice to folk: If you want to avoid a disaster then
>> make sure you model your problem domain in a "just enough" consensus
>> modelling exercise before your team goes anywhere near "View Models" or any
>> other part of the UI layer. ISIS offers nothing new that would change this
>> advice.
>> However "View Models" could be the scaffolding that you end up hanging
>> yourself and your team on if you don't understand that they are not part of
>> your domain model.
>> I guess I should shut up now as I am just repeating myself.
>> In summary: Big Tick for the addition of: "@DomainObject (External)" so
>> that we don't have to misuse "@ViewModel"
>> Regards,David.
>>
>>
>> On Saturday, 3 January 2015 10:24 PM, GESCONSULTOR <
>> o.bou@gesconsultor.com> wrote:
>>
>>
>> Hi David!
>>
>> What it's clear is that properties/collections can be useful not only for
>> domain layer objects, so the @Domain prefix should not be added.
>>
>> Regarding the Application Layer, I agree that sometimes it can be a clear
>> indication of an anemic domain. But properly implemented and used, it's
>> well accepted on the DDD community as a way to create a layer over domain
>> entities for orchestrating them. They're useful for representing Domain
>> Entities the way is most useful for the end-user as perhaps the Domain
>> Entities have been designed from another perpective different from that
>> concrete use case.
>>
>> There are some examples on the latest book, "Implementing DDD" by Caughn
>> Vernon.
>>
>> That use case is really similar to the most common use in Apache ISIS,
>> with the advantage that the UI is automatically generated from it
>>
>> Anyway I don't advocate for using ViewModels only for the Application
>> Layer, but in all case where "views" can be useful, including intra-domain
>> or inter-domain use cases (for example, for modeling the integration
>> patterns described on the "Implementing DDD" book such as Ports and
>> Adapters.
>>
>> as an example sure you will find interesting this sole implementation made
>> by Vernon, and how they could be implementing by Apache Isis[1].
>>
>> So yes, as you said we must be careful with anemic domains :))
>>
>> Regards,
>>
>> Oscar
>>
>> [1]
>> https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_collaboration/src/main/java/com/saasovation/collaboration
>>
>>
>>
>>
>>
>>
>>
>>>> El 1/1/2015, a las 20:45, David Tildesley <da...@yahoo.co.nz>
>>> escribió:
>>>
>>> Hi Oscar,
>>>
>>> I think we may be looking at the "tail wagging the dog" in this part of
>> the thread. I.e. the reason why Jeroen has found ViewModels for some of the
>> scenarios he outlined (e.g. "External Entity service" integration) so
>> useful was because there was no alternative available to him. This is where
>> Option 1 tidies things up from a conceptual layer point of view, as
>> discussed earlier in the post, but doesn't in any way prevent you from
>> doing what you suggest below if that is what you believe is correct i.e.
>> there would nothing forcing you to use "@ DomainObject (External)" - you
>> could instead carry on using "@ViewModel" within your domain layer if that
>> is what you think is correct. For those of us that believe this is
>> conceptually wrong, Option 1 keeps us happy because now we have "@
>> DomainObject (External)" available to us and furthermore, it allows
>> "@DomainObject (External)" to evolve independently of "@ViewModel" sometime
>> in the future.
>>>
>>> i.e. Option 1 removes the layer overloading as Dan already points out.
>>>
>>> On a further note, I don't like to use the concept "Application Layer" -
>> this layer was invented by those that ran into difficulty when forced to
>> use EJB 1 & 2 and unfortunately persisted even when the POJO movement
>> started (maybe because it was easier to migrate from the EJB 1 & 2 legacy).
>> I.e the presence of an "Application Layer" concept is a very strong
>> indicator of the presence of "Anemic Domain Model" anti-pattern [1] and
>> this is pointed out by Martin Fowler. Assuming a rich domain model then,
>> what may be thought of as the "Application Layer" is really just part of
>> the UI layer.
>>>
>>> [1] bliki: AnemicDomainModel
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> bliki: AnemicDomainModel
>>> If you use an object-oriented domain model, and you don't put behavior
>> in your objects, you're missing out on most of the benefits of that pattern.
>>> View on www.martinfowler.com
>>> Preview by Yahoo
>>>
>>>
>>>
>>> Regards,
>>> David.
>>>
>>>> On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou <
>>> o.bou@gesconsultor.com> wrote:
>>>
>>>
>>> Hi folks!!
>>>
>>> Happy New Year to all those following the Gregorian Calendar !!!
>>>
>>>
>>> As David mentions, we can think about ViewModels to be like "views".
>>>
>>> In that case, as Jeroen has commented, those "views" can be useful both
>> at the Domain layer and the Application layer.
>>> So we cannot assume that View Models are going to be useful only for the
>> Application layer, but also for the Domain layer.
>>> And not only they are "views" from this system's domain objects. As he
>> points out, Views can also be used to represent external systems entities.
>>>
>>> As Isis managed Properties/Collections can belong to any class of this
>> Bounded Context / Domain or External Systems Domains objects (being a
>> DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the
>> ApplicationLayer, a ViewModel representing entities managed by External
>> Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
>>>
>>>
>>> Oscar
>>>
>>>
>>>
>>>
>>>
>>>> El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <
>> Jeremy.D.Branham@sprint.com> escribió:
>>>>
>>>> At least it wasn’t DOA =]
>>>>
>>>> That helps me understand the evolution of Isis better, and It makes
>> sense the PD would never depend on the UI.
>>>>
>>>> So having separate annotations [@ViewModel and @DomainEntity] would
>> help maintain the distinction between UI and PD.
>>>> Where a single annotation [@DomainObject, @Model, or whatever else]
>> would blur the lines of responsibility.
>>>> Do I understand this correctly?
>>>>
>>>> Jeremy D. Branham
>>>> Tel: **DOTNET
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Tildesley [mailto:davotnz@yahoo.co.nz]
>>>> Sent: Wednesday, December 31, 2014 4:36 PM
>>>> To: dev@isis.apache.org; users@isis.apache.org
>>>> Subject: Re: ISIS-970 ... (new annotations) please review if you get a
>> chance...
>>>>
>>>> Sorry - too many new years eve beers - I typed DOI when I meant DI
>> (fuddled with IoC in my brain).
>>>>
>>>> On Thursday, 1 January 2015 11:04 AM, David Tildesley <
>> davotnz@yahoo.co.nz> 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]" <
>> Jeremy.D.Branham@sprint.com> 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:jeroen@stromboli.it]
>>>> 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 <
>> o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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ć <vnisevic@gmail.com
>> <ma...@gmail.com>> 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 <
>> dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>>:
>>>>
>>>>
>>>> On 30 December 2014 at 23:44, David Tildesley <davotnz@yahoo.co.nz
>> <ma...@yahoo.co.nz>> 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 <
>> dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
>>>>
>>>>
>>>> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
>> o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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
>> <http://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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> 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.
>>>
>>>
>>> Ó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://es.linkedin.com/in/oscarbou
>>>
>>> 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.
>>
>>
>>
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Hi Dan!
Thanks for this proposal.
Just some thoughts. i don't see compatible an option called "UI_VIEW" in a "domain" object.
Perhaps just "VIEW"?
If that's the case, what would differentiate it from a @ViewModel?
That said, it would keep "JDO_ENTITY", "EXTERNAL_ENTITY" (I love that concept :).
Regarding the "VIEW" option, if implementation is nearly the same as @ViewModel the only reason to keep it would be the consensus. So it ok for me.
If that wouldn't be introduced, the only options available would "JDO_ENTITY" and "EXTERNAL_ENTITY" given as a clear indication that the annotation could be named @DomainEntity ... :))
What a pity!!!
> El 3/1/2015, a las 12:59, Dan Haywood <da...@haywood-associates.co.uk> escribió:
>
> Folks,
>
> Thank you all so much for your contributions to this thread and also one I
> created on users@isis.a.o [1], discussing simplified a new set of
> annotations, as suggested in ISIS-970 [2].
>
> I've decided to continue the discussion on this thread as it's hosted most
> of the conversation to date. If you reply then please include both users@
> and dev@ so both users and contributors are kept in the loop.
>
> ~~~~~
> It seems to me that there's no clear consensus as to what set of
> annotations we should go with; any decision will be seen as not ideal by at
> least some users. The most debate has been about whether to retain
> @ViewModel, or whether or not to merge it into @DomainObject.
>
> Oscar, David, Ahmed, Vladimir, Jeremy and Mike all (I think) expressed a
> preference for retaining @ViewModel. Jeroen, Martin, Kevin and I all
> preferred removing @ViewModel and merging it into @DomainObject (though
> some of those opinions were made prior to the spirited debate that
> followed, so I don't know if anyone in this second list has revised their
> opinion).
>
> If @ViewModel is retained, then there was a subsidiary idea as to whether
> to replace @DomainObject with @DomainEntity (so it would be @ViewModel and
> @DomainEntity). One or two have been in favour of that idea, but it's not
> had overwhelming endorsement.
>
> Ged offered the opinion that a view model is more like a domain event. No
> one else replied to that idea. For myself, I don't think that's correct,
> but it got me thinking. Rather, domain events are what we emit through the
> (current) @ActionInteraction/@PropertyInteraction/@CollectionInteraction
> annotations. In ISIS-970 I proposed replacing @ActionInteraction with
> @Action(interaction=...) etc. Ged's mention of domain events makes me
> think it should instead be @Action(domainEvent=...). I've updated the
> JIRA ticket accordingly.
>
> I also made a proposal about adding "Domain" as a prefix to @Property,
> @Collection, @Action... but no-one seems particularly in favour of that.
>
> ~~~
> Before I go onto my own proposal for resolving this debate, let me just
> remind everyone that in Isis it's possible to write metamodel validators.
> We use these to check for no orphaned methods such as disableXxx(); I'm
> sure many will have encountered this. But it's also possible to write and
> register your own metamodel validators via isis.properties.
>
> Also, for Isis 1.8.0 we'll be releasing an Isis Maven plugin that allows
> the metamodel validation to be performed as part of the build, rather than
> rely on running up the app or its integration tests. There's an example of
> this in the simpleapp example [3] (and thus, will be part of the 1.8.0
> archetype).
>
> I mention this because it opens up the concept of "dialects" of the Isis
> programming model, enforceable through the build pipeline. Out-of-the-box
> Isis can provide support for all dialects, but individual projects can
> constrain these by registering appropriate metamodel validators as they see
> fit.
>
> ~~~
> So, my proposal is as follows:
>
> for the UI/app layer, retain/introduce:
> * @ViewModel
> * @ViewModelLayout
>
> for the domain layer:
> * @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | UI_VIEW)
> * @DomainObjectLayout
>
> for both:
> * @Property(domainEvent=..., ) and @PropertyLayout
> * @Collection(domainEvent=..., ) and @CollectionLayout
> * @Action(domainEvent=..., ) and @ActionLayout
> * @Parameter and @ParameterLayout
>
> Those that want to draw explicit attention to UI/app layer view models
> should use @ViewModel, and should ignore @DomainObject(nature=UI_VIEW).
> These folks might want to use a metamodel validator to ensure that
> @DomainObject(nature=UI_VIEW) is not used anywhere in their codebase.
>
> Conversely, those that consider that its all just "domain objects" should
> ignore @ViewModel, and instead use @DomainObject(nature=UI_VIEW). These
> folks might want to use a metamodel validator to ensure that @ViewModel is
> not used anywhere in their codebase.
>
> The @DomainObject(nature=JDO_ENTITY) is for regular Isis managed/persisted
> entities, while @DomainObject(nature=EXTERNAL_ENTITY) is for entities that
> are managed by some external system. Internally Isis installs a
> ViewModelFacet for these so that it knows how to manage their ongoing
> identity (in essence corresponding to the external system's URI for that
> entity), but that's an implementation detail.
>
> @ViewModelLayout and @DomainObjectLayout are basically identical.
>
> The above proposal does NOT include the introduction of @DomainEntity.
>
> ~~~
> Opinions? I'm kinda hoping this will get us to some sort of consensus ...
>
> Thanks
> Dan
>
> [1] http://isis.markmail.org/thread/ng22jsmxeq55ewny
> [2] https://issues.apache.org/jira/browse/ISIS-970
> [3]
> https://github.com/apache/isis/blob/a5b728f0606fa12c254ca1a0ecd49b88b816d6df/example/application/simpleapp/dom/pom.xml#L136
>
>
>> On 3 January 2015 at 11:23, David Tildesley <da...@yahoo.co.nz> wrote:
>>
>> Hi Oscar,
>> Seems to me it's the same thing:
>> Let me add some clarity to that DDD example you shared:
>> Port ---> Domain Model <---Adapter
>> is just a different set of terms for the same layers:
>> User Interface --> Problem Domain <--- System Interface
>> Chaining applications together in an integration you get Adapter "A" of
>> AppA calling Port "B" of AppB and so on - which I am guessing is what you
>> meant by "Inter Domain".
>> Clearly ViewModel fits into "Port" quite nicely. In fact it's the only
>> place it belongs.
>> But "Intra Domain"? Does ISIS in some way prevent a domain object calling
>> another domain object's operation directly? Anyway I suspect that's a
>> separate discussion.
>> The bottom line is that we can't stop people bleeding domain model
>> behaviour out into viewmodels, however what we can do is to make it as
>> clear and unambiguous as possible by avoiding/reducing overloading of
>> terms/concepts and suggesting the correct approach to building an
>> application.
>> My single piece of advice to folk: If you want to avoid a disaster then
>> make sure you model your problem domain in a "just enough" consensus
>> modelling exercise before your team goes anywhere near "View Models" or any
>> other part of the UI layer. ISIS offers nothing new that would change this
>> advice.
>> However "View Models" could be the scaffolding that you end up hanging
>> yourself and your team on if you don't understand that they are not part of
>> your domain model.
>> I guess I should shut up now as I am just repeating myself.
>> In summary: Big Tick for the addition of: "@DomainObject (External)" so
>> that we don't have to misuse "@ViewModel"
>> Regards,David.
>>
>>
>> On Saturday, 3 January 2015 10:24 PM, GESCONSULTOR <
>> o.bou@gesconsultor.com> wrote:
>>
>>
>> Hi David!
>>
>> What it's clear is that properties/collections can be useful not only for
>> domain layer objects, so the @Domain prefix should not be added.
>>
>> Regarding the Application Layer, I agree that sometimes it can be a clear
>> indication of an anemic domain. But properly implemented and used, it's
>> well accepted on the DDD community as a way to create a layer over domain
>> entities for orchestrating them. They're useful for representing Domain
>> Entities the way is most useful for the end-user as perhaps the Domain
>> Entities have been designed from another perpective different from that
>> concrete use case.
>>
>> There are some examples on the latest book, "Implementing DDD" by Caughn
>> Vernon.
>>
>> That use case is really similar to the most common use in Apache ISIS,
>> with the advantage that the UI is automatically generated from it
>>
>> Anyway I don't advocate for using ViewModels only for the Application
>> Layer, but in all case where "views" can be useful, including intra-domain
>> or inter-domain use cases (for example, for modeling the integration
>> patterns described on the "Implementing DDD" book such as Ports and
>> Adapters.
>>
>> as an example sure you will find interesting this sole implementation made
>> by Vernon, and how they could be implementing by Apache Isis[1].
>>
>> So yes, as you said we must be careful with anemic domains :))
>>
>> Regards,
>>
>> Oscar
>>
>> [1]
>> https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_collaboration/src/main/java/com/saasovation/collaboration
>>
>>
>>
>>
>>
>>
>>
>>>> El 1/1/2015, a las 20:45, David Tildesley <da...@yahoo.co.nz>
>>> escribió:
>>>
>>> Hi Oscar,
>>>
>>> I think we may be looking at the "tail wagging the dog" in this part of
>> the thread. I.e. the reason why Jeroen has found ViewModels for some of the
>> scenarios he outlined (e.g. "External Entity service" integration) so
>> useful was because there was no alternative available to him. This is where
>> Option 1 tidies things up from a conceptual layer point of view, as
>> discussed earlier in the post, but doesn't in any way prevent you from
>> doing what you suggest below if that is what you believe is correct i.e.
>> there would nothing forcing you to use "@ DomainObject (External)" - you
>> could instead carry on using "@ViewModel" within your domain layer if that
>> is what you think is correct. For those of us that believe this is
>> conceptually wrong, Option 1 keeps us happy because now we have "@
>> DomainObject (External)" available to us and furthermore, it allows
>> "@DomainObject (External)" to evolve independently of "@ViewModel" sometime
>> in the future.
>>>
>>> i.e. Option 1 removes the layer overloading as Dan already points out.
>>>
>>> On a further note, I don't like to use the concept "Application Layer" -
>> this layer was invented by those that ran into difficulty when forced to
>> use EJB 1 & 2 and unfortunately persisted even when the POJO movement
>> started (maybe because it was easier to migrate from the EJB 1 & 2 legacy).
>> I.e the presence of an "Application Layer" concept is a very strong
>> indicator of the presence of "Anemic Domain Model" anti-pattern [1] and
>> this is pointed out by Martin Fowler. Assuming a rich domain model then,
>> what may be thought of as the "Application Layer" is really just part of
>> the UI layer.
>>>
>>> [1] bliki: AnemicDomainModel
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> bliki: AnemicDomainModel
>>> If you use an object-oriented domain model, and you don't put behavior
>> in your objects, you're missing out on most of the benefits of that pattern.
>>> View on www.martinfowler.com
>>> Preview by Yahoo
>>>
>>>
>>>
>>> Regards,
>>> David.
>>>
>>>> On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou <
>>> o.bou@gesconsultor.com> wrote:
>>>
>>>
>>> Hi folks!!
>>>
>>> Happy New Year to all those following the Gregorian Calendar !!!
>>>
>>>
>>> As David mentions, we can think about ViewModels to be like "views".
>>>
>>> In that case, as Jeroen has commented, those "views" can be useful both
>> at the Domain layer and the Application layer.
>>> So we cannot assume that View Models are going to be useful only for the
>> Application layer, but also for the Domain layer.
>>> And not only they are "views" from this system's domain objects. As he
>> points out, Views can also be used to represent external systems entities.
>>>
>>> As Isis managed Properties/Collections can belong to any class of this
>> Bounded Context / Domain or External Systems Domains objects (being a
>> DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the
>> ApplicationLayer, a ViewModel representing entities managed by External
>> Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
>>>
>>>
>>> Oscar
>>>
>>>
>>>
>>>
>>>
>>>> El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <
>> Jeremy.D.Branham@sprint.com> escribió:
>>>>
>>>> At least it wasn’t DOA =]
>>>>
>>>> That helps me understand the evolution of Isis better, and It makes
>> sense the PD would never depend on the UI.
>>>>
>>>> So having separate annotations [@ViewModel and @DomainEntity] would
>> help maintain the distinction between UI and PD.
>>>> Where a single annotation [@DomainObject, @Model, or whatever else]
>> would blur the lines of responsibility.
>>>> Do I understand this correctly?
>>>>
>>>> Jeremy D. Branham
>>>> Tel: **DOTNET
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: David Tildesley [mailto:davotnz@yahoo.co.nz]
>>>> Sent: Wednesday, December 31, 2014 4:36 PM
>>>> To: dev@isis.apache.org; users@isis.apache.org
>>>> Subject: Re: ISIS-970 ... (new annotations) please review if you get a
>> chance...
>>>>
>>>> Sorry - too many new years eve beers - I typed DOI when I meant DI
>> (fuddled with IoC in my brain).
>>>>
>>>> On Thursday, 1 January 2015 11:04 AM, David Tildesley <
>> davotnz@yahoo.co.nz> 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]" <
>> Jeremy.D.Branham@sprint.com> 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:jeroen@stromboli.it]
>>>> 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 <
>> o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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ć <vnisevic@gmail.com
>> <ma...@gmail.com>> 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 <
>> dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>>:
>>>>
>>>>
>>>> On 30 December 2014 at 23:44, David Tildesley <davotnz@yahoo.co.nz
>> <ma...@yahoo.co.nz>> 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 <
>> dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
>>>>
>>>>
>>>> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
>> o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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
>> <http://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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> 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.
>>>
>>>
>>> Ó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://es.linkedin.com/in/oscarbou
>>>
>>> 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.
>>
>>
>>
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Folks,
Thank you all so much for your contributions to this thread and also one I
created on users@isis.a.o [1], discussing simplified a new set of
annotations, as suggested in ISIS-970 [2].
I've decided to continue the discussion on this thread as it's hosted most
of the conversation to date. If you reply then please include both users@
and dev@ so both users and contributors are kept in the loop.
~~~~~
It seems to me that there's no clear consensus as to what set of
annotations we should go with; any decision will be seen as not ideal by at
least some users. The most debate has been about whether to retain
@ViewModel, or whether or not to merge it into @DomainObject.
Oscar, David, Ahmed, Vladimir, Jeremy and Mike all (I think) expressed a
preference for retaining @ViewModel. Jeroen, Martin, Kevin and I all
preferred removing @ViewModel and merging it into @DomainObject (though
some of those opinions were made prior to the spirited debate that
followed, so I don't know if anyone in this second list has revised their
opinion).
If @ViewModel is retained, then there was a subsidiary idea as to whether
to replace @DomainObject with @DomainEntity (so it would be @ViewModel and
@DomainEntity). One or two have been in favour of that idea, but it's not
had overwhelming endorsement.
Ged offered the opinion that a view model is more like a domain event. No
one else replied to that idea. For myself, I don't think that's correct,
but it got me thinking. Rather, domain events are what we emit through the
(current) @ActionInteraction/@PropertyInteraction/@CollectionInteraction
annotations. In ISIS-970 I proposed replacing @ActionInteraction with
@Action(interaction=...) etc. Ged's mention of domain events makes me
think it should instead be @Action(domainEvent=...). I've updated the
JIRA ticket accordingly.
I also made a proposal about adding "Domain" as a prefix to @Property,
@Collection, @Action... but no-one seems particularly in favour of that.
~~~
Before I go onto my own proposal for resolving this debate, let me just
remind everyone that in Isis it's possible to write metamodel validators.
We use these to check for no orphaned methods such as disableXxx(); I'm
sure many will have encountered this. But it's also possible to write and
register your own metamodel validators via isis.properties.
Also, for Isis 1.8.0 we'll be releasing an Isis Maven plugin that allows
the metamodel validation to be performed as part of the build, rather than
rely on running up the app or its integration tests. There's an example of
this in the simpleapp example [3] (and thus, will be part of the 1.8.0
archetype).
I mention this because it opens up the concept of "dialects" of the Isis
programming model, enforceable through the build pipeline. Out-of-the-box
Isis can provide support for all dialects, but individual projects can
constrain these by registering appropriate metamodel validators as they see
fit.
~~~
So, my proposal is as follows:
for the UI/app layer, retain/introduce:
* @ViewModel
* @ViewModelLayout
for the domain layer:
* @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | UI_VIEW)
* @DomainObjectLayout
for both:
* @Property(domainEvent=..., ) and @PropertyLayout
* @Collection(domainEvent=..., ) and @CollectionLayout
* @Action(domainEvent=..., ) and @ActionLayout
* @Parameter and @ParameterLayout
Those that want to draw explicit attention to UI/app layer view models
should use @ViewModel, and should ignore @DomainObject(nature=UI_VIEW).
These folks might want to use a metamodel validator to ensure that
@DomainObject(nature=UI_VIEW) is not used anywhere in their codebase.
Conversely, those that consider that its all just "domain objects" should
ignore @ViewModel, and instead use @DomainObject(nature=UI_VIEW). These
folks might want to use a metamodel validator to ensure that @ViewModel is
not used anywhere in their codebase.
The @DomainObject(nature=JDO_ENTITY) is for regular Isis managed/persisted
entities, while @DomainObject(nature=EXTERNAL_ENTITY) is for entities that
are managed by some external system. Internally Isis installs a
ViewModelFacet for these so that it knows how to manage their ongoing
identity (in essence corresponding to the external system's URI for that
entity), but that's an implementation detail.
@ViewModelLayout and @DomainObjectLayout are basically identical.
The above proposal does NOT include the introduction of @DomainEntity.
~~~
Opinions? I'm kinda hoping this will get us to some sort of consensus ...
Thanks
Dan
[1] http://isis.markmail.org/thread/ng22jsmxeq55ewny
[2] https://issues.apache.org/jira/browse/ISIS-970
[3]
https://github.com/apache/isis/blob/a5b728f0606fa12c254ca1a0ecd49b88b816d6df/example/application/simpleapp/dom/pom.xml#L136
On 3 January 2015 at 11:23, David Tildesley <da...@yahoo.co.nz> wrote:
> Hi Oscar,
> Seems to me it's the same thing:
> Let me add some clarity to that DDD example you shared:
> Port ---> Domain Model <---Adapter
> is just a different set of terms for the same layers:
> User Interface --> Problem Domain <--- System Interface
> Chaining applications together in an integration you get Adapter "A" of
> AppA calling Port "B" of AppB and so on - which I am guessing is what you
> meant by "Inter Domain".
> Clearly ViewModel fits into "Port" quite nicely. In fact it's the only
> place it belongs.
> But "Intra Domain"? Does ISIS in some way prevent a domain object calling
> another domain object's operation directly? Anyway I suspect that's a
> separate discussion.
> The bottom line is that we can't stop people bleeding domain model
> behaviour out into viewmodels, however what we can do is to make it as
> clear and unambiguous as possible by avoiding/reducing overloading of
> terms/concepts and suggesting the correct approach to building an
> application.
> My single piece of advice to folk: If you want to avoid a disaster then
> make sure you model your problem domain in a "just enough" consensus
> modelling exercise before your team goes anywhere near "View Models" or any
> other part of the UI layer. ISIS offers nothing new that would change this
> advice.
> However "View Models" could be the scaffolding that you end up hanging
> yourself and your team on if you don't understand that they are not part of
> your domain model.
> I guess I should shut up now as I am just repeating myself.
> In summary: Big Tick for the addition of: "@DomainObject (External)" so
> that we don't have to misuse "@ViewModel"
> Regards,David.
>
>
> On Saturday, 3 January 2015 10:24 PM, GESCONSULTOR <
> o.bou@gesconsultor.com> wrote:
>
>
> Hi David!
>
> What it's clear is that properties/collections can be useful not only for
> domain layer objects, so the @Domain prefix should not be added.
>
> Regarding the Application Layer, I agree that sometimes it can be a clear
> indication of an anemic domain. But properly implemented and used, it's
> well accepted on the DDD community as a way to create a layer over domain
> entities for orchestrating them. They're useful for representing Domain
> Entities the way is most useful for the end-user as perhaps the Domain
> Entities have been designed from another perpective different from that
> concrete use case.
>
> There are some examples on the latest book, "Implementing DDD" by Caughn
> Vernon.
>
> That use case is really similar to the most common use in Apache ISIS,
> with the advantage that the UI is automatically generated from it
>
> Anyway I don't advocate for using ViewModels only for the Application
> Layer, but in all case where "views" can be useful, including intra-domain
> or inter-domain use cases (for example, for modeling the integration
> patterns described on the "Implementing DDD" book such as Ports and
> Adapters.
>
> as an example sure you will find interesting this sole implementation made
> by Vernon, and how they could be implementing by Apache Isis[1].
>
> So yes, as you said we must be careful with anemic domains :))
>
> Regards,
>
> Oscar
>
> [1]
> https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_collaboration/src/main/java/com/saasovation/collaboration
>
>
>
>
>
>
>
> > El 1/1/2015, a las 20:45, David Tildesley <da...@yahoo.co.nz>
> escribió:
> >
> > Hi Oscar,
> >
> > I think we may be looking at the "tail wagging the dog" in this part of
> the thread. I.e. the reason why Jeroen has found ViewModels for some of the
> scenarios he outlined (e.g. "External Entity service" integration) so
> useful was because there was no alternative available to him. This is where
> Option 1 tidies things up from a conceptual layer point of view, as
> discussed earlier in the post, but doesn't in any way prevent you from
> doing what you suggest below if that is what you believe is correct i.e.
> there would nothing forcing you to use "@ DomainObject (External)" - you
> could instead carry on using "@ViewModel" within your domain layer if that
> is what you think is correct. For those of us that believe this is
> conceptually wrong, Option 1 keeps us happy because now we have "@
> DomainObject (External)" available to us and furthermore, it allows
> "@DomainObject (External)" to evolve independently of "@ViewModel" sometime
> in the future.
> >
> > i.e. Option 1 removes the layer overloading as Dan already points out.
> >
> > On a further note, I don't like to use the concept "Application Layer" -
> this layer was invented by those that ran into difficulty when forced to
> use EJB 1 & 2 and unfortunately persisted even when the POJO movement
> started (maybe because it was easier to migrate from the EJB 1 & 2 legacy).
> I.e the presence of an "Application Layer" concept is a very strong
> indicator of the presence of "Anemic Domain Model" anti-pattern [1] and
> this is pointed out by Martin Fowler. Assuming a rich domain model then,
> what may be thought of as the "Application Layer" is really just part of
> the UI layer.
> >
> > [1] bliki: AnemicDomainModel
> >
> >
> >
> >
> >
> >
> >
> >
> > bliki: AnemicDomainModel
> > If you use an object-oriented domain model, and you don't put behavior
> in your objects, you're missing out on most of the benefits of that pattern.
> > View on www.martinfowler.com
> > Preview by Yahoo
> >
> >
> >
> > Regards,
> > David.
> >
> > On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou <
> o.bou@gesconsultor.com> wrote:
> >
> >
> > Hi folks!!
> >
> > Happy New Year to all those following the Gregorian Calendar !!!
> >
> >
> > As David mentions, we can think about ViewModels to be like "views".
> >
> > In that case, as Jeroen has commented, those "views" can be useful both
> at the Domain layer and the Application layer.
> > So we cannot assume that View Models are going to be useful only for the
> Application layer, but also for the Domain layer.
> > And not only they are "views" from this system's domain objects. As he
> points out, Views can also be used to represent external systems entities.
> >
> > As Isis managed Properties/Collections can belong to any class of this
> Bounded Context / Domain or External Systems Domains objects (being a
> DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the
> ApplicationLayer, a ViewModel representing entities managed by External
> Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
> >
> >
> > Oscar
> >
> >
> >
> >
> >
> >> El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <
> Jeremy.D.Branham@sprint.com> escribió:
> >>
> >> At least it wasn’t DOA =]
> >>
> >> That helps me understand the evolution of Isis better, and It makes
> sense the PD would never depend on the UI.
> >>
> >> So having separate annotations [@ViewModel and @DomainEntity] would
> help maintain the distinction between UI and PD.
> >> Where a single annotation [@DomainObject, @Model, or whatever else]
> would blur the lines of responsibility.
> >> Do I understand this correctly?
> >>
> >> Jeremy D. Branham
> >> Tel: **DOTNET
> >>
> >>
> >> -----Original Message-----
> >> From: David Tildesley [mailto:davotnz@yahoo.co.nz]
> >> Sent: Wednesday, December 31, 2014 4:36 PM
> >> To: dev@isis.apache.org; users@isis.apache.org
> >> Subject: Re: ISIS-970 ... (new annotations) please review if you get a
> chance...
> >>
> >> Sorry - too many new years eve beers - I typed DOI when I meant DI
> (fuddled with IoC in my brain).
> >>
> >> On Thursday, 1 January 2015 11:04 AM, David Tildesley <
> davotnz@yahoo.co.nz> 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]" <
> Jeremy.D.Branham@sprint.com> 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:jeroen@stromboli.it]
> >> 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 <
> o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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ć <vnisevic@gmail.com
> <ma...@gmail.com>> 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 <
> dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>>:
> >>
> >>
> >> On 30 December 2014 at 23:44, David Tildesley <davotnz@yahoo.co.nz
> <ma...@yahoo.co.nz>> 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 <
> dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
> >>
> >>
> >> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
> o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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
> <http://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.
> >>
> >>
> >>
> >>
> >>
> >>
> >> ________________________________
> >>
> >> 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.
> >
> >
> > Ó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://es.linkedin.com/in/oscarbou
> >
> > 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.
> >
> >
> >
> >
> >
> >
> >
>
>
>
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Folks,
Thank you all so much for your contributions to this thread and also one I
created on users@isis.a.o [1], discussing simplified a new set of
annotations, as suggested in ISIS-970 [2].
I've decided to continue the discussion on this thread as it's hosted most
of the conversation to date. If you reply then please include both users@
and dev@ so both users and contributors are kept in the loop.
~~~~~
It seems to me that there's no clear consensus as to what set of
annotations we should go with; any decision will be seen as not ideal by at
least some users. The most debate has been about whether to retain
@ViewModel, or whether or not to merge it into @DomainObject.
Oscar, David, Ahmed, Vladimir, Jeremy and Mike all (I think) expressed a
preference for retaining @ViewModel. Jeroen, Martin, Kevin and I all
preferred removing @ViewModel and merging it into @DomainObject (though
some of those opinions were made prior to the spirited debate that
followed, so I don't know if anyone in this second list has revised their
opinion).
If @ViewModel is retained, then there was a subsidiary idea as to whether
to replace @DomainObject with @DomainEntity (so it would be @ViewModel and
@DomainEntity). One or two have been in favour of that idea, but it's not
had overwhelming endorsement.
Ged offered the opinion that a view model is more like a domain event. No
one else replied to that idea. For myself, I don't think that's correct,
but it got me thinking. Rather, domain events are what we emit through the
(current) @ActionInteraction/@PropertyInteraction/@CollectionInteraction
annotations. In ISIS-970 I proposed replacing @ActionInteraction with
@Action(interaction=...) etc. Ged's mention of domain events makes me
think it should instead be @Action(domainEvent=...). I've updated the
JIRA ticket accordingly.
I also made a proposal about adding "Domain" as a prefix to @Property,
@Collection, @Action... but no-one seems particularly in favour of that.
~~~
Before I go onto my own proposal for resolving this debate, let me just
remind everyone that in Isis it's possible to write metamodel validators.
We use these to check for no orphaned methods such as disableXxx(); I'm
sure many will have encountered this. But it's also possible to write and
register your own metamodel validators via isis.properties.
Also, for Isis 1.8.0 we'll be releasing an Isis Maven plugin that allows
the metamodel validation to be performed as part of the build, rather than
rely on running up the app or its integration tests. There's an example of
this in the simpleapp example [3] (and thus, will be part of the 1.8.0
archetype).
I mention this because it opens up the concept of "dialects" of the Isis
programming model, enforceable through the build pipeline. Out-of-the-box
Isis can provide support for all dialects, but individual projects can
constrain these by registering appropriate metamodel validators as they see
fit.
~~~
So, my proposal is as follows:
for the UI/app layer, retain/introduce:
* @ViewModel
* @ViewModelLayout
for the domain layer:
* @DomainObject(nature=JDO_ENTITY | EXTERNAL_ENTITY | UI_VIEW)
* @DomainObjectLayout
for both:
* @Property(domainEvent=..., ) and @PropertyLayout
* @Collection(domainEvent=..., ) and @CollectionLayout
* @Action(domainEvent=..., ) and @ActionLayout
* @Parameter and @ParameterLayout
Those that want to draw explicit attention to UI/app layer view models
should use @ViewModel, and should ignore @DomainObject(nature=UI_VIEW).
These folks might want to use a metamodel validator to ensure that
@DomainObject(nature=UI_VIEW) is not used anywhere in their codebase.
Conversely, those that consider that its all just "domain objects" should
ignore @ViewModel, and instead use @DomainObject(nature=UI_VIEW). These
folks might want to use a metamodel validator to ensure that @ViewModel is
not used anywhere in their codebase.
The @DomainObject(nature=JDO_ENTITY) is for regular Isis managed/persisted
entities, while @DomainObject(nature=EXTERNAL_ENTITY) is for entities that
are managed by some external system. Internally Isis installs a
ViewModelFacet for these so that it knows how to manage their ongoing
identity (in essence corresponding to the external system's URI for that
entity), but that's an implementation detail.
@ViewModelLayout and @DomainObjectLayout are basically identical.
The above proposal does NOT include the introduction of @DomainEntity.
~~~
Opinions? I'm kinda hoping this will get us to some sort of consensus ...
Thanks
Dan
[1] http://isis.markmail.org/thread/ng22jsmxeq55ewny
[2] https://issues.apache.org/jira/browse/ISIS-970
[3]
https://github.com/apache/isis/blob/a5b728f0606fa12c254ca1a0ecd49b88b816d6df/example/application/simpleapp/dom/pom.xml#L136
On 3 January 2015 at 11:23, David Tildesley <da...@yahoo.co.nz> wrote:
> Hi Oscar,
> Seems to me it's the same thing:
> Let me add some clarity to that DDD example you shared:
> Port ---> Domain Model <---Adapter
> is just a different set of terms for the same layers:
> User Interface --> Problem Domain <--- System Interface
> Chaining applications together in an integration you get Adapter "A" of
> AppA calling Port "B" of AppB and so on - which I am guessing is what you
> meant by "Inter Domain".
> Clearly ViewModel fits into "Port" quite nicely. In fact it's the only
> place it belongs.
> But "Intra Domain"? Does ISIS in some way prevent a domain object calling
> another domain object's operation directly? Anyway I suspect that's a
> separate discussion.
> The bottom line is that we can't stop people bleeding domain model
> behaviour out into viewmodels, however what we can do is to make it as
> clear and unambiguous as possible by avoiding/reducing overloading of
> terms/concepts and suggesting the correct approach to building an
> application.
> My single piece of advice to folk: If you want to avoid a disaster then
> make sure you model your problem domain in a "just enough" consensus
> modelling exercise before your team goes anywhere near "View Models" or any
> other part of the UI layer. ISIS offers nothing new that would change this
> advice.
> However "View Models" could be the scaffolding that you end up hanging
> yourself and your team on if you don't understand that they are not part of
> your domain model.
> I guess I should shut up now as I am just repeating myself.
> In summary: Big Tick for the addition of: "@DomainObject (External)" so
> that we don't have to misuse "@ViewModel"
> Regards,David.
>
>
> On Saturday, 3 January 2015 10:24 PM, GESCONSULTOR <
> o.bou@gesconsultor.com> wrote:
>
>
> Hi David!
>
> What it's clear is that properties/collections can be useful not only for
> domain layer objects, so the @Domain prefix should not be added.
>
> Regarding the Application Layer, I agree that sometimes it can be a clear
> indication of an anemic domain. But properly implemented and used, it's
> well accepted on the DDD community as a way to create a layer over domain
> entities for orchestrating them. They're useful for representing Domain
> Entities the way is most useful for the end-user as perhaps the Domain
> Entities have been designed from another perpective different from that
> concrete use case.
>
> There are some examples on the latest book, "Implementing DDD" by Caughn
> Vernon.
>
> That use case is really similar to the most common use in Apache ISIS,
> with the advantage that the UI is automatically generated from it
>
> Anyway I don't advocate for using ViewModels only for the Application
> Layer, but in all case where "views" can be useful, including intra-domain
> or inter-domain use cases (for example, for modeling the integration
> patterns described on the "Implementing DDD" book such as Ports and
> Adapters.
>
> as an example sure you will find interesting this sole implementation made
> by Vernon, and how they could be implementing by Apache Isis[1].
>
> So yes, as you said we must be careful with anemic domains :))
>
> Regards,
>
> Oscar
>
> [1]
> https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_collaboration/src/main/java/com/saasovation/collaboration
>
>
>
>
>
>
>
> > El 1/1/2015, a las 20:45, David Tildesley <da...@yahoo.co.nz>
> escribió:
> >
> > Hi Oscar,
> >
> > I think we may be looking at the "tail wagging the dog" in this part of
> the thread. I.e. the reason why Jeroen has found ViewModels for some of the
> scenarios he outlined (e.g. "External Entity service" integration) so
> useful was because there was no alternative available to him. This is where
> Option 1 tidies things up from a conceptual layer point of view, as
> discussed earlier in the post, but doesn't in any way prevent you from
> doing what you suggest below if that is what you believe is correct i.e.
> there would nothing forcing you to use "@ DomainObject (External)" - you
> could instead carry on using "@ViewModel" within your domain layer if that
> is what you think is correct. For those of us that believe this is
> conceptually wrong, Option 1 keeps us happy because now we have "@
> DomainObject (External)" available to us and furthermore, it allows
> "@DomainObject (External)" to evolve independently of "@ViewModel" sometime
> in the future.
> >
> > i.e. Option 1 removes the layer overloading as Dan already points out.
> >
> > On a further note, I don't like to use the concept "Application Layer" -
> this layer was invented by those that ran into difficulty when forced to
> use EJB 1 & 2 and unfortunately persisted even when the POJO movement
> started (maybe because it was easier to migrate from the EJB 1 & 2 legacy).
> I.e the presence of an "Application Layer" concept is a very strong
> indicator of the presence of "Anemic Domain Model" anti-pattern [1] and
> this is pointed out by Martin Fowler. Assuming a rich domain model then,
> what may be thought of as the "Application Layer" is really just part of
> the UI layer.
> >
> > [1] bliki: AnemicDomainModel
> >
> >
> >
> >
> >
> >
> >
> >
> > bliki: AnemicDomainModel
> > If you use an object-oriented domain model, and you don't put behavior
> in your objects, you're missing out on most of the benefits of that pattern.
> > View on www.martinfowler.com
> > Preview by Yahoo
> >
> >
> >
> > Regards,
> > David.
> >
> > On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou <
> o.bou@gesconsultor.com> wrote:
> >
> >
> > Hi folks!!
> >
> > Happy New Year to all those following the Gregorian Calendar !!!
> >
> >
> > As David mentions, we can think about ViewModels to be like "views".
> >
> > In that case, as Jeroen has commented, those "views" can be useful both
> at the Domain layer and the Application layer.
> > So we cannot assume that View Models are going to be useful only for the
> Application layer, but also for the Domain layer.
> > And not only they are "views" from this system's domain objects. As he
> points out, Views can also be used to represent external systems entities.
> >
> > As Isis managed Properties/Collections can belong to any class of this
> Bounded Context / Domain or External Systems Domains objects (being a
> DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the
> ApplicationLayer, a ViewModel representing entities managed by External
> Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
> >
> >
> > Oscar
> >
> >
> >
> >
> >
> >> El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <
> Jeremy.D.Branham@sprint.com> escribió:
> >>
> >> At least it wasn’t DOA =]
> >>
> >> That helps me understand the evolution of Isis better, and It makes
> sense the PD would never depend on the UI.
> >>
> >> So having separate annotations [@ViewModel and @DomainEntity] would
> help maintain the distinction between UI and PD.
> >> Where a single annotation [@DomainObject, @Model, or whatever else]
> would blur the lines of responsibility.
> >> Do I understand this correctly?
> >>
> >> Jeremy D. Branham
> >> Tel: **DOTNET
> >>
> >>
> >> -----Original Message-----
> >> From: David Tildesley [mailto:davotnz@yahoo.co.nz]
> >> Sent: Wednesday, December 31, 2014 4:36 PM
> >> To: dev@isis.apache.org; users@isis.apache.org
> >> Subject: Re: ISIS-970 ... (new annotations) please review if you get a
> chance...
> >>
> >> Sorry - too many new years eve beers - I typed DOI when I meant DI
> (fuddled with IoC in my brain).
> >>
> >> On Thursday, 1 January 2015 11:04 AM, David Tildesley <
> davotnz@yahoo.co.nz> 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]" <
> Jeremy.D.Branham@sprint.com> 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:jeroen@stromboli.it]
> >> 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 <
> o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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ć <vnisevic@gmail.com
> <ma...@gmail.com>> 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 <
> dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>>:
> >>
> >>
> >> On 30 December 2014 at 23:44, David Tildesley <davotnz@yahoo.co.nz
> <ma...@yahoo.co.nz>> 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 <
> dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
> >>
> >>
> >> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
> o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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
> <http://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.
> >>
> >>
> >>
> >>
> >>
> >>
> >> ________________________________
> >>
> >> 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.
> >
> >
> > Ó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://es.linkedin.com/in/oscarbou
> >
> > 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.
> >
> >
> >
> >
> >
> >
> >
>
>
>
Re: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
Hi Oscar,
Seems to me it's the same thing:
Let me add some clarity to that DDD example you shared:
Port ---> Domain Model <---Adapter
is just a different set of terms for the same layers:
User Interface --> Problem Domain <--- System Interface
Chaining applications together in an integration you get Adapter "A" of AppA calling Port "B" of AppB and so on - which I am guessing is what you meant by "Inter Domain".
Clearly ViewModel fits into "Port" quite nicely. In fact it's the only place it belongs.
But "Intra Domain"? Does ISIS in some way prevent a domain object calling another domain object's operation directly? Anyway I suspect that's a separate discussion.
The bottom line is that we can't stop people bleeding domain model behaviour out into viewmodels, however what we can do is to make it as clear and unambiguous as possible by avoiding/reducing overloading of terms/concepts and suggesting the correct approach to building an application.
My single piece of advice to folk: If you want to avoid a disaster then make sure you model your problem domain in a "just enough" consensus modelling exercise before your team goes anywhere near "View Models" or any other part of the UI layer. ISIS offers nothing new that would change this advice.
However "View Models" could be the scaffolding that you end up hanging yourself and your team on if you don't understand that they are not part of your domain model.
I guess I should shut up now as I am just repeating myself.
In summary: Big Tick for the addition of: "@DomainObject (External)" so that we don't have to misuse "@ViewModel"
Regards,David.
On Saturday, 3 January 2015 10:24 PM, GESCONSULTOR <o....@gesconsultor.com> wrote:
Hi David!
What it's clear is that properties/collections can be useful not only for domain layer objects, so the @Domain prefix should not be added.
Regarding the Application Layer, I agree that sometimes it can be a clear indication of an anemic domain. But properly implemented and used, it's well accepted on the DDD community as a way to create a layer over domain entities for orchestrating them. They're useful for representing Domain Entities the way is most useful for the end-user as perhaps the Domain Entities have been designed from another perpective different from that concrete use case.
There are some examples on the latest book, "Implementing DDD" by Caughn Vernon.
That use case is really similar to the most common use in Apache ISIS, with the advantage that the UI is automatically generated from it
Anyway I don't advocate for using ViewModels only for the Application Layer, but in all case where "views" can be useful, including intra-domain or inter-domain use cases (for example, for modeling the integration patterns described on the "Implementing DDD" book such as Ports and Adapters.
as an example sure you will find interesting this sole implementation made by Vernon, and how they could be implementing by Apache Isis[1].
So yes, as you said we must be careful with anemic domains :))
Regards,
Oscar
[1] https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_collaboration/src/main/java/com/saasovation/collaboration
> El 1/1/2015, a las 20:45, David Tildesley <da...@yahoo.co.nz> escribió:
>
> Hi Oscar,
>
> I think we may be looking at the "tail wagging the dog" in this part of the thread. I.e. the reason why Jeroen has found ViewModels for some of the scenarios he outlined (e.g. "External Entity service" integration) so useful was because there was no alternative available to him. This is where Option 1 tidies things up from a conceptual layer point of view, as discussed earlier in the post, but doesn't in any way prevent you from doing what you suggest below if that is what you believe is correct i.e. there would nothing forcing you to use "@ DomainObject (External)" - you could instead carry on using "@ViewModel" within your domain layer if that is what you think is correct. For those of us that believe this is conceptually wrong, Option 1 keeps us happy because now we have "@ DomainObject (External)" available to us and furthermore, it allows "@DomainObject (External)" to evolve independently of "@ViewModel" sometime in the future.
>
> i.e. Option 1 removes the layer overloading as Dan already points out.
>
> On a further note, I don't like to use the concept "Application Layer" - this layer was invented by those that ran into difficulty when forced to use EJB 1 & 2 and unfortunately persisted even when the POJO movement started (maybe because it was easier to migrate from the EJB 1 & 2 legacy). I.e the presence of an "Application Layer" concept is a very strong indicator of the presence of "Anemic Domain Model" anti-pattern [1] and this is pointed out by Martin Fowler. Assuming a rich domain model then, what may be thought of as the "Application Layer" is really just part of the UI layer.
>
> [1] bliki: AnemicDomainModel
>
>
>
>
>
>
>
>
> bliki: AnemicDomainModel
> If you use an object-oriented domain model, and you don't put behavior in your objects, you're missing out on most of the benefits of that pattern.
> View on www.martinfowler.com
> Preview by Yahoo
>
>
>
> Regards,
> David.
>
> On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
>
>
> Hi folks!!
>
> Happy New Year to all those following the Gregorian Calendar !!!
>
>
> As David mentions, we can think about ViewModels to be like "views".
>
> In that case, as Jeroen has commented, those "views" can be useful both at the Domain layer and the Application layer.
> So we cannot assume that View Models are going to be useful only for the Application layer, but also for the Domain layer.
> And not only they are "views" from this system's domain objects. As he points out, Views can also be used to represent external systems entities.
>
> As Isis managed Properties/Collections can belong to any class of this Bounded Context / Domain or External Systems Domains objects (being a DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the ApplicationLayer, a ViewModel representing entities managed by External Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
>
>
> Oscar
>
>
>
>
>
>> El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <Je...@sprint.com> escribió:
>>
>> At least it wasn’t DOA =]
>>
>> That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
>>
>> So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
>> Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
>> Do I understand this correctly?
>>
>> Jeremy D. Branham
>> Tel: **DOTNET
>>
>>
>> -----Original Message-----
>> From: David Tildesley [mailto:davotnz@yahoo.co.nz]
>> Sent: Wednesday, December 31, 2014 4:36 PM
>> To: dev@isis.apache.org; users@isis.apache.org
>> Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
>>
>> Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
>>
>> On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
>> 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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
>>
>>
>> On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
>>
>>
>> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
>>
>>
>>
>>
>>
>>
>> ________________________________
>>
>> 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.
>
>
> Ó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://es.linkedin.com/in/oscarbou
>
> 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.
>
>
>
>
>
>
>
Re: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
Hi Oscar,
Seems to me it's the same thing:
Let me add some clarity to that DDD example you shared:
Port ---> Domain Model <---Adapter
is just a different set of terms for the same layers:
User Interface --> Problem Domain <--- System Interface
Chaining applications together in an integration you get Adapter "A" of AppA calling Port "B" of AppB and so on - which I am guessing is what you meant by "Inter Domain".
Clearly ViewModel fits into "Port" quite nicely. In fact it's the only place it belongs.
But "Intra Domain"? Does ISIS in some way prevent a domain object calling another domain object's operation directly? Anyway I suspect that's a separate discussion.
The bottom line is that we can't stop people bleeding domain model behaviour out into viewmodels, however what we can do is to make it as clear and unambiguous as possible by avoiding/reducing overloading of terms/concepts and suggesting the correct approach to building an application.
My single piece of advice to folk: If you want to avoid a disaster then make sure you model your problem domain in a "just enough" consensus modelling exercise before your team goes anywhere near "View Models" or any other part of the UI layer. ISIS offers nothing new that would change this advice.
However "View Models" could be the scaffolding that you end up hanging yourself and your team on if you don't understand that they are not part of your domain model.
I guess I should shut up now as I am just repeating myself.
In summary: Big Tick for the addition of: "@DomainObject (External)" so that we don't have to misuse "@ViewModel"
Regards,David.
On Saturday, 3 January 2015 10:24 PM, GESCONSULTOR <o....@gesconsultor.com> wrote:
Hi David!
What it's clear is that properties/collections can be useful not only for domain layer objects, so the @Domain prefix should not be added.
Regarding the Application Layer, I agree that sometimes it can be a clear indication of an anemic domain. But properly implemented and used, it's well accepted on the DDD community as a way to create a layer over domain entities for orchestrating them. They're useful for representing Domain Entities the way is most useful for the end-user as perhaps the Domain Entities have been designed from another perpective different from that concrete use case.
There are some examples on the latest book, "Implementing DDD" by Caughn Vernon.
That use case is really similar to the most common use in Apache ISIS, with the advantage that the UI is automatically generated from it
Anyway I don't advocate for using ViewModels only for the Application Layer, but in all case where "views" can be useful, including intra-domain or inter-domain use cases (for example, for modeling the integration patterns described on the "Implementing DDD" book such as Ports and Adapters.
as an example sure you will find interesting this sole implementation made by Vernon, and how they could be implementing by Apache Isis[1].
So yes, as you said we must be careful with anemic domains :))
Regards,
Oscar
[1] https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_collaboration/src/main/java/com/saasovation/collaboration
> El 1/1/2015, a las 20:45, David Tildesley <da...@yahoo.co.nz> escribió:
>
> Hi Oscar,
>
> I think we may be looking at the "tail wagging the dog" in this part of the thread. I.e. the reason why Jeroen has found ViewModels for some of the scenarios he outlined (e.g. "External Entity service" integration) so useful was because there was no alternative available to him. This is where Option 1 tidies things up from a conceptual layer point of view, as discussed earlier in the post, but doesn't in any way prevent you from doing what you suggest below if that is what you believe is correct i.e. there would nothing forcing you to use "@ DomainObject (External)" - you could instead carry on using "@ViewModel" within your domain layer if that is what you think is correct. For those of us that believe this is conceptually wrong, Option 1 keeps us happy because now we have "@ DomainObject (External)" available to us and furthermore, it allows "@DomainObject (External)" to evolve independently of "@ViewModel" sometime in the future.
>
> i.e. Option 1 removes the layer overloading as Dan already points out.
>
> On a further note, I don't like to use the concept "Application Layer" - this layer was invented by those that ran into difficulty when forced to use EJB 1 & 2 and unfortunately persisted even when the POJO movement started (maybe because it was easier to migrate from the EJB 1 & 2 legacy). I.e the presence of an "Application Layer" concept is a very strong indicator of the presence of "Anemic Domain Model" anti-pattern [1] and this is pointed out by Martin Fowler. Assuming a rich domain model then, what may be thought of as the "Application Layer" is really just part of the UI layer.
>
> [1] bliki: AnemicDomainModel
>
>
>
>
>
>
>
>
> bliki: AnemicDomainModel
> If you use an object-oriented domain model, and you don't put behavior in your objects, you're missing out on most of the benefits of that pattern.
> View on www.martinfowler.com
> Preview by Yahoo
>
>
>
> Regards,
> David.
>
> On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
>
>
> Hi folks!!
>
> Happy New Year to all those following the Gregorian Calendar !!!
>
>
> As David mentions, we can think about ViewModels to be like "views".
>
> In that case, as Jeroen has commented, those "views" can be useful both at the Domain layer and the Application layer.
> So we cannot assume that View Models are going to be useful only for the Application layer, but also for the Domain layer.
> And not only they are "views" from this system's domain objects. As he points out, Views can also be used to represent external systems entities.
>
> As Isis managed Properties/Collections can belong to any class of this Bounded Context / Domain or External Systems Domains objects (being a DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the ApplicationLayer, a ViewModel representing entities managed by External Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
>
>
> Oscar
>
>
>
>
>
>> El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <Je...@sprint.com> escribió:
>>
>> At least it wasn’t DOA =]
>>
>> That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
>>
>> So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
>> Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
>> Do I understand this correctly?
>>
>> Jeremy D. Branham
>> Tel: **DOTNET
>>
>>
>> -----Original Message-----
>> From: David Tildesley [mailto:davotnz@yahoo.co.nz]
>> Sent: Wednesday, December 31, 2014 4:36 PM
>> To: dev@isis.apache.org; users@isis.apache.org
>> Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
>>
>> Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
>>
>> On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
>> 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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
>>
>>
>> On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
>>
>>
>> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
>>
>>
>>
>>
>>
>>
>> ________________________________
>>
>> 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.
>
>
> Ó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://es.linkedin.com/in/oscarbou
>
> 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.
>
>
>
>
>
>
>
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Hi David!
What it's clear is that properties/collections can be useful not only for domain layer objects, so the @Domain prefix should not be added.
Regarding the Application Layer, I agree that sometimes it can be a clear indication of an anemic domain. But properly implemented and used, it's well accepted on the DDD community as a way to create a layer over domain entities for orchestrating them. They're useful for representing Domain Entities the way is most useful for the end-user as perhaps the Domain Entities have been designed from another perpective different from that concrete use case.
There are some examples on the latest book, "Implementing DDD" by Caughn Vernon.
That use case is really similar to the most common use in Apache ISIS, with the advantage that the UI is automatically generated from it
Anyway I don't advocate for using ViewModels only for the Application Layer, but in all case where "views" can be useful, including intra-domain or inter-domain use cases (for example, for modeling the integration patterns described on the "Implementing DDD" book such as Ports and Adapters.
as an example sure you will find interesting this sole implementation made by Vernon, and how they could be implementing by Apache Isis[1].
So yes, as you said we must be careful with anemic domains :))
Regards,
Oscar
[1] https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_collaboration/src/main/java/com/saasovation/collaboration
> El 1/1/2015, a las 20:45, David Tildesley <da...@yahoo.co.nz> escribió:
>
> Hi Oscar,
>
> I think we may be looking at the "tail wagging the dog" in this part of the thread. I.e. the reason why Jeroen has found ViewModels for some of the scenarios he outlined (e.g. "External Entity service" integration) so useful was because there was no alternative available to him. This is where Option 1 tidies things up from a conceptual layer point of view, as discussed earlier in the post, but doesn't in any way prevent you from doing what you suggest below if that is what you believe is correct i.e. there would nothing forcing you to use "@ DomainObject (External)" - you could instead carry on using "@ViewModel" within your domain layer if that is what you think is correct. For those of us that believe this is conceptually wrong, Option 1 keeps us happy because now we have "@ DomainObject (External)" available to us and furthermore, it allows "@DomainObject (External)" to evolve independently of "@ViewModel" sometime in the future.
>
> i.e. Option 1 removes the layer overloading as Dan already points out.
>
> On a further note, I don't like to use the concept "Application Layer" - this layer was invented by those that ran into difficulty when forced to use EJB 1 & 2 and unfortunately persisted even when the POJO movement started (maybe because it was easier to migrate from the EJB 1 & 2 legacy). I.e the presence of an "Application Layer" concept is a very strong indicator of the presence of "Anemic Domain Model" anti-pattern [1] and this is pointed out by Martin Fowler. Assuming a rich domain model then, what may be thought of as the "Application Layer" is really just part of the UI layer.
>
> [1] bliki: AnemicDomainModel
>
>
>
>
>
>
>
>
> bliki: AnemicDomainModel
> If you use an object-oriented domain model, and you don't put behavior in your objects, you're missing out on most of the benefits of that pattern.
> View on www.martinfowler.com
> Preview by Yahoo
>
>
>
> Regards,
> David.
>
> On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
>
>
> Hi folks!!
>
> Happy New Year to all those following the Gregorian Calendar !!!
>
>
> As David mentions, we can think about ViewModels to be like "views".
>
> In that case, as Jeroen has commented, those "views" can be useful both at the Domain layer and the Application layer.
> So we cannot assume that View Models are going to be useful only for the Application layer, but also for the Domain layer.
> And not only they are "views" from this system's domain objects. As he points out, Views can also be used to represent external systems entities.
>
> As Isis managed Properties/Collections can belong to any class of this Bounded Context / Domain or External Systems Domains objects (being a DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the ApplicationLayer, a ViewModel representing entities managed by External Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
>
>
> Oscar
>
>
>
>
>
>> El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <Je...@sprint.com> escribió:
>>
>> At least it wasn’t DOA =]
>>
>> That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
>>
>> So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
>> Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
>> Do I understand this correctly?
>>
>> Jeremy D. Branham
>> Tel: **DOTNET
>>
>>
>> -----Original Message-----
>> From: David Tildesley [mailto:davotnz@yahoo.co.nz]
>> Sent: Wednesday, December 31, 2014 4:36 PM
>> To: dev@isis.apache.org; users@isis.apache.org
>> Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
>>
>> Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
>>
>> On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
>> 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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
>>
>>
>> On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
>>
>>
>> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
>>
>>
>>
>>
>>
>>
>> ________________________________
>>
>> 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.
>
>
> Ó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://es.linkedin.com/in/oscarbou
>
> 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.
>
>
>
>
>
>
>
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by GESCONSULTOR <o....@gesconsultor.com>.
Hi David!
What it's clear is that properties/collections can be useful not only for domain layer objects, so the @Domain prefix should not be added.
Regarding the Application Layer, I agree that sometimes it can be a clear indication of an anemic domain. But properly implemented and used, it's well accepted on the DDD community as a way to create a layer over domain entities for orchestrating them. They're useful for representing Domain Entities the way is most useful for the end-user as perhaps the Domain Entities have been designed from another perpective different from that concrete use case.
There are some examples on the latest book, "Implementing DDD" by Caughn Vernon.
That use case is really similar to the most common use in Apache ISIS, with the advantage that the UI is automatically generated from it
Anyway I don't advocate for using ViewModels only for the Application Layer, but in all case where "views" can be useful, including intra-domain or inter-domain use cases (for example, for modeling the integration patterns described on the "Implementing DDD" book such as Ports and Adapters.
as an example sure you will find interesting this sole implementation made by Vernon, and how they could be implementing by Apache Isis[1].
So yes, as you said we must be careful with anemic domains :))
Regards,
Oscar
[1] https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_collaboration/src/main/java/com/saasovation/collaboration
> El 1/1/2015, a las 20:45, David Tildesley <da...@yahoo.co.nz> escribió:
>
> Hi Oscar,
>
> I think we may be looking at the "tail wagging the dog" in this part of the thread. I.e. the reason why Jeroen has found ViewModels for some of the scenarios he outlined (e.g. "External Entity service" integration) so useful was because there was no alternative available to him. This is where Option 1 tidies things up from a conceptual layer point of view, as discussed earlier in the post, but doesn't in any way prevent you from doing what you suggest below if that is what you believe is correct i.e. there would nothing forcing you to use "@ DomainObject (External)" - you could instead carry on using "@ViewModel" within your domain layer if that is what you think is correct. For those of us that believe this is conceptually wrong, Option 1 keeps us happy because now we have "@ DomainObject (External)" available to us and furthermore, it allows "@DomainObject (External)" to evolve independently of "@ViewModel" sometime in the future.
>
> i.e. Option 1 removes the layer overloading as Dan already points out.
>
> On a further note, I don't like to use the concept "Application Layer" - this layer was invented by those that ran into difficulty when forced to use EJB 1 & 2 and unfortunately persisted even when the POJO movement started (maybe because it was easier to migrate from the EJB 1 & 2 legacy). I.e the presence of an "Application Layer" concept is a very strong indicator of the presence of "Anemic Domain Model" anti-pattern [1] and this is pointed out by Martin Fowler. Assuming a rich domain model then, what may be thought of as the "Application Layer" is really just part of the UI layer.
>
> [1] bliki: AnemicDomainModel
>
>
>
>
>
>
>
>
> bliki: AnemicDomainModel
> If you use an object-oriented domain model, and you don't put behavior in your objects, you're missing out on most of the benefits of that pattern.
> View on www.martinfowler.com
> Preview by Yahoo
>
>
>
> Regards,
> David.
>
> On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
>
>
> Hi folks!!
>
> Happy New Year to all those following the Gregorian Calendar !!!
>
>
> As David mentions, we can think about ViewModels to be like "views".
>
> In that case, as Jeroen has commented, those "views" can be useful both at the Domain layer and the Application layer.
> So we cannot assume that View Models are going to be useful only for the Application layer, but also for the Domain layer.
> And not only they are "views" from this system's domain objects. As he points out, Views can also be used to represent external systems entities.
>
> As Isis managed Properties/Collections can belong to any class of this Bounded Context / Domain or External Systems Domains objects (being a DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the ApplicationLayer, a ViewModel representing entities managed by External Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
>
>
> Oscar
>
>
>
>
>
>> El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <Je...@sprint.com> escribió:
>>
>> At least it wasn’t DOA =]
>>
>> That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
>>
>> So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
>> Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
>> Do I understand this correctly?
>>
>> Jeremy D. Branham
>> Tel: **DOTNET
>>
>>
>> -----Original Message-----
>> From: David Tildesley [mailto:davotnz@yahoo.co.nz]
>> Sent: Wednesday, December 31, 2014 4:36 PM
>> To: dev@isis.apache.org; users@isis.apache.org
>> Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
>>
>> Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
>>
>> On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
>> 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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
>>
>>
>> On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
>>
>>
>> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
>>
>>
>>
>>
>>
>>
>> ________________________________
>>
>> 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.
>
>
> Ó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://es.linkedin.com/in/oscarbou
>
> 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.
>
>
>
>
>
>
>
Re: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
Hi Oscar,
I think we may be looking at the "tail wagging the dog" in this part of the thread. I.e. the reason why Jeroen has found ViewModels for some of the scenarios he outlined (e.g. "External Entity service" integration) so useful was because there was no alternative available to him. This is where Option 1 tidies things up from a conceptual layer point of view, as discussed earlier in the post, but doesn't in any way prevent you from doing what you suggest below if that is what you believe is correct i.e. there would nothing forcing you to use "@ DomainObject (External)" - you could instead carry on using "@ViewModel" within your domain layer if that is what you think is correct. For those of us that believe this is conceptually wrong, Option 1 keeps us happy because now we have "@ DomainObject (External)" available to us and furthermore, it allows "@DomainObject (External)" to evolve independently of "@ViewModel" sometime in the future.
i.e. Option 1 removes the layer overloading as Dan already points out.
On a further note, I don't like to use the concept "Application Layer" - this layer was invented by those that ran into difficulty when forced to use EJB 1 & 2 and unfortunately persisted even when the POJO movement started (maybe because it was easier to migrate from the EJB 1 & 2 legacy). I.e the presence of an "Application Layer" concept is a very strong indicator of the presence of "Anemic Domain Model" anti-pattern [1] and this is pointed out by Martin Fowler. Assuming a rich domain model then, what may be thought of as the "Application Layer" is really just part of the UI layer.
[1] bliki: AnemicDomainModel
| |
| | | | | | | |
| bliki: AnemicDomainModelIf you use an object-oriented domain model, and you don't put behavior in your objects, you're missing out on most of the benefits of that pattern. |
| |
| View on www.martinfowler.com | Preview by Yahoo |
| |
| |
Regards,David.
On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
Hi folks!!
Happy New Year to all those following the Gregorian Calendar !!!
As David mentions, we can think about ViewModels to be like "views".
In that case, as Jeroen has commented, those "views" can be useful both at the Domain layer and the Application layer. So we cannot assume that View Models are going to be useful only for the Application layer, but also for the Domain layer.And not only they are "views" from this system's domain objects. As he points out, Views can also be used to represent external systems entities.
As Isis managed Properties/Collections can belong to any class of this Bounded Context / Domain or External Systems Domains objects (being a DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the ApplicationLayer, a ViewModel representing entities managed by External Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
Oscar
El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <Je...@sprint.com> escribió:
At least it wasn’t DOA =]
That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
Do I understand this correctly?
Jeremy D. Branham
Tel: **DOTNET
-----Original Message-----
From: David Tildesley [mailto:davotnz@yahoo.co.nz]
Sent: Wednesday, December 31, 2014 4:36 PM
To: dev@isis.apache.org; users@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
________________________________
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.
Ó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://es.linkedin.com/in/oscarbou
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.
Re: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
Hi Oscar,
I think we may be looking at the "tail wagging the dog" in this part of the thread. I.e. the reason why Jeroen has found ViewModels for some of the scenarios he outlined (e.g. "External Entity service" integration) so useful was because there was no alternative available to him. This is where Option 1 tidies things up from a conceptual layer point of view, as discussed earlier in the post, but doesn't in any way prevent you from doing what you suggest below if that is what you believe is correct i.e. there would nothing forcing you to use "@ DomainObject (External)" - you could instead carry on using "@ViewModel" within your domain layer if that is what you think is correct. For those of us that believe this is conceptually wrong, Option 1 keeps us happy because now we have "@ DomainObject (External)" available to us and furthermore, it allows "@DomainObject (External)" to evolve independently of "@ViewModel" sometime in the future.
i.e. Option 1 removes the layer overloading as Dan already points out.
On a further note, I don't like to use the concept "Application Layer" - this layer was invented by those that ran into difficulty when forced to use EJB 1 & 2 and unfortunately persisted even when the POJO movement started (maybe because it was easier to migrate from the EJB 1 & 2 legacy). I.e the presence of an "Application Layer" concept is a very strong indicator of the presence of "Anemic Domain Model" anti-pattern [1] and this is pointed out by Martin Fowler. Assuming a rich domain model then, what may be thought of as the "Application Layer" is really just part of the UI layer.
[1] bliki: AnemicDomainModel
| |
| | | | | | | |
| bliki: AnemicDomainModelIf you use an object-oriented domain model, and you don't put behavior in your objects, you're missing out on most of the benefits of that pattern. |
| |
| View on www.martinfowler.com | Preview by Yahoo |
| |
| |
Regards,David.
On Friday, 2 January 2015 12:40 AM, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
Hi folks!!
Happy New Year to all those following the Gregorian Calendar !!!
As David mentions, we can think about ViewModels to be like "views".
In that case, as Jeroen has commented, those "views" can be useful both at the Domain layer and the Application layer. So we cannot assume that View Models are going to be useful only for the Application layer, but also for the Domain layer.And not only they are "views" from this system's domain objects. As he points out, Views can also be used to represent external systems entities.
As Isis managed Properties/Collections can belong to any class of this Bounded Context / Domain or External Systems Domains objects (being a DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the ApplicationLayer, a ViewModel representing entities managed by External Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
Oscar
El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <Je...@sprint.com> escribió:
At least it wasn’t DOA =]
That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
Do I understand this correctly?
Jeremy D. Branham
Tel: **DOTNET
-----Original Message-----
From: David Tildesley [mailto:davotnz@yahoo.co.nz]
Sent: Wednesday, December 31, 2014 4:36 PM
To: dev@isis.apache.org; users@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
________________________________
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.
Ó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://es.linkedin.com/in/oscarbou
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.
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Hi folks!!
Happy New Year to all those following the Gregorian Calendar !!!
As David mentions, we can think about ViewModels to be like "views".
In that case, as Jeroen has commented, those "views" can be useful both at the Domain layer and the Application layer.
So we cannot assume that View Models are going to be useful only for the Application layer, but also for the Domain layer.
And not only they are "views" from this system's domain objects. As he points out, Views can also be used to represent external systems entities.
As Isis managed Properties/Collections can belong to any class of this Bounded Context / Domain or External Systems Domains objects (being a DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the ApplicationLayer, a ViewModel representing entities managed by External Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
Oscar
> El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <Je...@sprint.com> escribió:
>
> At least it wasn’t DOA =]
>
> That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
>
> So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
> Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
> Do I understand this correctly?
>
> Jeremy D. Branham
> Tel: **DOTNET
>
>
> -----Original Message-----
> From: David Tildesley [mailto:davotnz@yahoo.co.nz]
> Sent: Wednesday, December 31, 2014 4:36 PM
> To: dev@isis.apache.org; users@isis.apache.org
> Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
>
> Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
>
> On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
> 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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
>
>
> On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
>
>
> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
>
>
>
>
>
>
> ________________________________
>
> 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.
Ó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.
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Hi folks!!
Happy New Year to all those following the Gregorian Calendar !!!
As David mentions, we can think about ViewModels to be like "views".
In that case, as Jeroen has commented, those "views" can be useful both at the Domain layer and the Application layer.
So we cannot assume that View Models are going to be useful only for the Application layer, but also for the Domain layer.
And not only they are "views" from this system's domain objects. As he points out, Views can also be used to represent external systems entities.
As Isis managed Properties/Collections can belong to any class of this Bounded Context / Domain or External Systems Domains objects (being a DomainEntity, a ViewModel used on the Domain Layer, a ViewModel used on the ApplicationLayer, a ViewModel representing entities managed by External Systems) they shouldn't be prefixed with a layer-specific term, IMHO.
Oscar
> El 31/12/2014, a las 23:40, Branham, Jeremy [HR] <Je...@sprint.com> escribió:
>
> At least it wasn’t DOA =]
>
> That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
>
> So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
> Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
> Do I understand this correctly?
>
> Jeremy D. Branham
> Tel: **DOTNET
>
>
> -----Original Message-----
> From: David Tildesley [mailto:davotnz@yahoo.co.nz]
> Sent: Wednesday, December 31, 2014 4:36 PM
> To: dev@isis.apache.org; users@isis.apache.org
> Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
>
> Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
>
> On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
> 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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
>
>
> On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
>
>
> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
>
>
>
>
>
>
> ________________________________
>
> 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.
Ó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.
RE: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by "Branham, Jeremy [HR]" <Je...@sprint.com>.
At least it wasn’t DOA =]
That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
Do I understand this correctly?
Jeremy D. Branham
Tel: **DOTNET
-----Original Message-----
From: David Tildesley [mailto:davotnz@yahoo.co.nz]
Sent: Wednesday, December 31, 2014 4:36 PM
To: dev@isis.apache.org; users@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
________________________________
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.
RE: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by "Branham, Jeremy [HR]" <Je...@sprint.com>.
At least it wasn’t DOA =]
That helps me understand the evolution of Isis better, and It makes sense the PD would never depend on the UI.
So having separate annotations [@ViewModel and @DomainEntity] would help maintain the distinction between UI and PD.
Where a single annotation [@DomainObject, @Model, or whatever else] would blur the lines of responsibility.
Do I understand this correctly?
Jeremy D. Branham
Tel: **DOTNET
-----Original Message-----
From: David Tildesley [mailto:davotnz@yahoo.co.nz]
Sent: Wednesday, December 31, 2014 4:36 PM
To: dev@isis.apache.org; users@isis.apache.org
Subject: Re: ISIS-970 ... (new annotations) please review if you get a chance...
Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 < dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou < o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
________________________________
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.
Re: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 <
dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
Re: ISIS-970 ... (new annotations) please review if you get a chance...
Posted by Ged Byrne <ge...@gmail.com>.
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 <da...@yahoo.co.nz> 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]" <
> Jeremy.D.Branham@sprint.com> 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:jeroen@stromboli.it]
> 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 <
> o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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ć <vnisevic@gmail.com<mailto:
> vnisevic@gmail.com>> 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 <dan@haywood-associates.co.uk<
> mailto:dan@haywood-associates.co.uk>>:
>
>
> On 30 December 2014 at 23:44, David Tildesley <davotnz@yahoo.co.nz<mailto:
> davotnz@yahoo.co.nz>> 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 <
> dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
>
>
> On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
> o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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.
>
>
>
Re: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
Sorry - too many new years eve beers - I typed DOI when I meant DI (fuddled with IoC in my brain).
On Thursday, 1 January 2015 11:04 AM, David Tildesley <da...@yahoo.co.nz> 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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 <
dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
Re: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 <
dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
Re: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by David Tildesley <da...@yahoo.co.nz>.
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]" <Je...@sprint.com> 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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 <
dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
RE: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by "Branham, Jeremy [HR]" <Je...@sprint.com>.
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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 <
dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.
RE: ISIS-970 ... (new annotations) please review if you get a
chance...
Posted by "Branham, Jeremy [HR]" <Je...@sprint.com>.
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:jeroen@stromboli.it]
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 <o....@gesconsultor.com>> 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ć <vn...@gmail.com>> 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 <da...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley <da...@yahoo.co.nz>> 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 <
dan@haywood-associates.co.uk<ma...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
o.bou@gesconsultor.com<ma...@gesconsultor.com>> 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<http://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.