Re: ISIS-970 ... (new annotations) please review if you get a chance...
. 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] jeremy.d.bran...@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:davo...@yahoo.co.nz] Sent: Wednesday, December 31, 2014 4:36 PM To: d...@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 davo...@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
Re: ISIS-970 ... (new annotations) please review if you get a chance...
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] jeremy.d.bran...@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:davo...@yahoo.co.nz] Sent: Wednesday, December 31, 2014 4:36 PM To: d...@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 davo...@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
Re: ISIS-970 ... (new annotations) please review if you get a chance...
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] jeremy.d.bran...@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:davo...@yahoo.co.nz] Sent: Wednesday, December 31, 2014 4:36 PM To: d...@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 davo...@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
RE: ISIS-970 ... (new annotations) please review if you get a chance...
This is a good compromise IMHO. Jeremy D. Branham Tel: **DOTNET -Original Message- From: Dan Haywood [mailto:d...@haywood-associates.co.uk] Sent: Saturday, January 03, 2015 7:27 AM To: users Cc: d...@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 jer...@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...
Good consensus for me also :) El 3/1/2015, a las 18:48, Branham, Jeremy [HR] jeremy.d.bran...@sprint.com escribió: This is a good compromise IMHO. Jeremy D. Branham Tel: **DOTNET -Original Message- From: Dan Haywood [mailto:d...@haywood-associates.co.uk] Sent: Saturday, January 03, 2015 7:27 AM To: users Cc: d...@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 jer...@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...
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] jeremy.d.bran...@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:davo...@yahoo.co.nz] Sent: Wednesday, December 31, 2014 4:36 PM To: d...@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 davo...@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
Re: ISIS-970 ... (new annotations) please review if you get a chance...
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.bran...@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:davo...@yahoo.co.nz] Sent: Wednesday, December 31, 2014 4:36 PM To: d...@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 davo...@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
Re: ISIS-970 ... (new annotations) please review if you get a chance...
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 davo...@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.bran...@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:jer...@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
Re: ISIS-970 ... (new annotations) please review if you get a chance...
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 jer...@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...
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:jer...@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.commailto: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ć vnise...@gmail.commailto:vnise...@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 d...@haywood-associates.co.ukmailto:d...@haywood-associates.co.uk: On 30 December 2014 at 23:44, David Tildesley davo...@yahoo.co.nzmailto:davo...@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 d...@haywood-associates.co.ukmailto:d...@haywood-associates.co.uk wrote: On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou o@gesconsultor.commailto:o@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
RE: ISIS-970 ... (new annotations) please review if you get a chance...
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:davo...@yahoo.co.nz] Sent: Wednesday, December 31, 2014 4:36 PM To: d...@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 davo...@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.bran...@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:jer...@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
