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 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 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<mailto: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.com<mailto: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.uk<mailto:d...@haywood-associates.co.uk>>:
On 30 December 2014 at 23:44, David Tildesley
<davo...@yahoo.co.nz<mailto: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.uk<mailto:d...@haywood-associates.co.uk>> wrote:
On 29 December 2014 at 13:23, GESCONSULTOR - Óscar Bou <
o....@gesconsultor.com<mailto: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 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.
