Questions

[Alexandru Vladut <al...@gmail.com>]

Hi,

I am currently working on a personal project where I try to apply the
principles of DDD. I am reading Dan's book "Domain Driven Design using
Naked Objects", trying to adapt the examples to the Isis Framework. During
my work I found some problems that I need to be clarified:
1. The Value-Object pattern seems not to work as in the documentation. It
says that you need only to annotate your class with @Value and to implement
the interface ValueSemanticsProvider. But it worked only if I annotated the
field with @javax.jdo.annotations.Persistent and the getter with
@org.apache.isis.applib.annotation.NotPersisted. I didn't find any example,
neither in the SimpleObject nor in ToDoApp. Did I do anything wrong or can
I find an example anywhere?

2. The aggregates seem not to work (from what I read, it is supported only
for NoSQL). I read also on the site that it istn't fully supported and its
use is currently discouraged. What does it mean? Is rather recommended to
use the Value Types or there is another alternative?

3. I would like to know, also, if it is possible to completely eliminate
the JDO for storage. Firstly I want to use a fully in-memory storage,
without any database (does the DomainObjectContainer support anything like
that?) and afterwards something else.

Thank you,
Alex

Re: Questions

[Alexandru Vladut <al...@gmail.com>]

Thank you for your prompt answer.I will apply your hints :)

2014-12-09 19:22 GMT+02:00 GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
:

> Hi, Alex.
>
>
> 2. The aggregates seem not to work (from what I read, it is supported only
> for NoSQL). I read also on the site that it istn't fully supported and its
> use is currently discouraged. What does it mean? Is rather recommended to
> use the Value Types or there is another alternative?
>
>
> Again, this arises from using JDO.  Aggregates were necessary as a "hint"
> for our old home-grown objectstores, eg NoSQL and XML, to tell it to
> persist referenced objects in-line.  Now we use JDO as our ORM, it means
> there's nothing else in the framework that requires this semantic.
>
> The closest alternative is to use JDO embedded objects [1].  Haven't used
> this myself, but I think Oscar has, and think it should work.
>
>
>
>
> We're not using embedded objects, but instead 1-1 relationships, that
> works really good.
>
> If they're persisted or not in a different table is not a matter of DDD
> (it's a "persistence" matter).
>
> But the main characteristic of them is that they should be inmutable,
> which you can easily
> achieve by using [1].
>
> That same Value Object (for example, an Address) could be referenced by
> multiple Entities (being mapped in fact as a 1-n relationship).
>
>
>
> http://isis.apache.org/more-advanced-topics/how-to-02-080-How-to-specify-that-none-of-an-object's-members-can-be-modified-or-invoked.html
>
>
> So my recommendation for now is that you stick with use JDO, but configure
> it (in the JDBC URLs in persistor.properties) to use an in-memory database
> (eg HSQLDB as in the archetypes, or H2).
>
>
>
> I fully agree with Dan. I've never tried it, but the theoretical advantage
> of JDO over JPA is that it's better for NoSQL databases.
>
>
> HTH,
>
> Oscar
>
>
>
> El 9/12/2014, a las 16:56, Dan Haywood <da...@haywood-associates.co.uk>
> escribió:
>
>
> On 9 December 2014 at 15:32, Alexandru Vladut <al...@gmail.com>
> wrote:
>
> Hi,
>
> I am currently working on a personal project where I try to apply the
> principles of DDD. I am reading Dan's book "Domain Driven Design using
> Naked Objects", trying to adapt the examples to the Isis Framework. During
> my work I found some problems that I need to be clarified:
>
>
> Welcome to the mailing list, Alex.
>
>
>
> 1. The Value-Object pattern seems not to work as in the documentation. It
> says that you need only to annotate your class with @Value and to implement
> the interface ValueSemanticsProvider. But it worked only if I annotated the
> field with @javax.jdo.annotations.Persistent and the getter with
> @org.apache.isis.applib.annotation.NotPersisted. I didn't find any example,
> neither in the SimpleObject nor in ToDoApp. Did I do anything wrong or can
> I find an example anywhere?
>
>
> No, you've not done anything wrong... right now we aren't supporting the
> @Value semantics.  The primary reason for this is because of our use of
> JDO/DataNucleus; there is no equivalent general purpose mechanism (other
> than to persist values as serializable byte[] arrays, not exactly
> satisfactory).
>
> This is something that I'd like to look at again; not having @Value means
> violating DRY, eg using strings and then having to specify the same
> semantics the would-be value type is used as a property or a parameter.
> But right now pragmatism wins out!
>
>
>
> 2. The aggregates seem not to work (from what I read, it is supported only
> for NoSQL). I read also on the site that it istn't fully supported and its
> use is currently discouraged. What does it mean? Is rather recommended to
> use the Value Types or there is another alternative?
>
>
> Again, this arises from using JDO.  Aggregates were necessary as a "hint"
> for our old home-grown objectstores, eg NoSQL and XML, to tell it to
> persist referenced objects in-line.  Now we use JDO as our ORM, it means
> there's nothing else in the framework that requires this semantic.
>
> The closest alternative is to use JDO embedded objects [1].  Haven't used
> this myself, but I think Oscar has, and think it should work.
>
>
>
> 3. I would like to know, also, if it is possible to completely eliminate
> the JDO for storage. Firstly I want to use a fully in-memory storage,
> without any database (does the DomainObjectContainer support anything like
> that?) and afterwards something else.
>
>
> Right now the objectstore API is pluggable, so you can change to an
> in-memory implementation by changing the "isis.persistor" key in
> isis.properties file to "in-memory".
>
> HOWEVER, doing that will break (or at least disable) some aspects of the
> framework, most notably dirty object tracking (eg as used for auditing
> capability) and also maintenance of bidirectional relationships.
>
> Accordingly, we are almost certain to remove this pluggable API in the
> future (in Isis 2.0 next year), so that we can continue to slim down the
> Isis framework's responsibilities and focus on domain metamodels and their
> representation.  We might re-introduce a pluggable API in the future, but
> only as a means to supporting other full-fledged persistence solutions (eg
> EclipseLink or Hibernate) that support lazy loading/dirty object tracking
> etc.
>
> So my recommendation for now is that you stick with use JDO, but configure
> it (in the JDBC URLs in persistor.properties) to use an in-memory database
> (eg HSQLDB as in the archetypes, or H2).
>
> HTH
> Dan
>
>
>
> Thank you,
> Alex
>
>
>
> [1] http://www.datanucleus.org/products/datanucleus/jdo/orm/embedded.html
>
>
>
> Ó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: Questions

[GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>]

Hi, Alex.


>> 2. The aggregates seem not to work (from what I read, it is supported only
>> for NoSQL). I read also on the site that it istn't fully supported and its
>> use is currently discouraged. What does it mean? Is rather recommended to
>> use the Value Types or there is another alternative?
>> 
>> 
> Again, this arises from using JDO.  Aggregates were necessary as a "hint"
> for our old home-grown objectstores, eg NoSQL and XML, to tell it to
> persist referenced objects in-line.  Now we use JDO as our ORM, it means
> there's nothing else in the framework that requires this semantic.
> 
> The closest alternative is to use JDO embedded objects [1].  Haven't used
> this myself, but I think Oscar has, and think it should work.



We're not using embedded objects, but instead 1-1 relationships, that works really good.

If they're persisted or not in a different table is not a matter of DDD (it's a "persistence" matter).

But the main characteristic of them is that they should be inmutable, which you can easily
achieve by using [1].

That same Value Object (for example, an Address) could be referenced by multiple Entities (being mapped in fact as a 1-n relationship).


http://isis.apache.org/more-advanced-topics/how-to-02-080-How-to-specify-that-none-of-an-object's-members-can-be-modified-or-invoked.html


> So my recommendation for now is that you stick with use JDO, but configure
> it (in the JDBC URLs in persistor.properties) to use an in-memory database
> (eg HSQLDB as in the archetypes, or H2).


I fully agree with Dan. I've never tried it, but the theoretical advantage of JDO over JPA is that it's better for NoSQL databases.


HTH,

Oscar



> El 9/12/2014, a las 16:56, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> 
> On 9 December 2014 at 15:32, Alexandru Vladut <al...@gmail.com>
> wrote:
> 
>> Hi,
>> 
>> I am currently working on a personal project where I try to apply the
>> principles of DDD. I am reading Dan's book "Domain Driven Design using
>> Naked Objects", trying to adapt the examples to the Isis Framework. During
>> my work I found some problems that I need to be clarified:
>> 
> 
> Welcome to the mailing list, Alex.
> 
> 
> 
>> 1. The Value-Object pattern seems not to work as in the documentation. It
>> says that you need only to annotate your class with @Value and to implement
>> the interface ValueSemanticsProvider. But it worked only if I annotated the
>> field with @javax.jdo.annotations.Persistent and the getter with
>> @org.apache.isis.applib.annotation.NotPersisted. I didn't find any example,
>> neither in the SimpleObject nor in ToDoApp. Did I do anything wrong or can
>> I find an example anywhere?
>> 
>> 
> No, you've not done anything wrong... right now we aren't supporting the
> @Value semantics.  The primary reason for this is because of our use of
> JDO/DataNucleus; there is no equivalent general purpose mechanism (other
> than to persist values as serializable byte[] arrays, not exactly
> satisfactory).
> 
> This is something that I'd like to look at again; not having @Value means
> violating DRY, eg using strings and then having to specify the same
> semantics the would-be value type is used as a property or a parameter.
> But right now pragmatism wins out!
> 
> 
> 
>> 2. The aggregates seem not to work (from what I read, it is supported only
>> for NoSQL). I read also on the site that it istn't fully supported and its
>> use is currently discouraged. What does it mean? Is rather recommended to
>> use the Value Types or there is another alternative?
>> 
>> 
> Again, this arises from using JDO.  Aggregates were necessary as a "hint"
> for our old home-grown objectstores, eg NoSQL and XML, to tell it to
> persist referenced objects in-line.  Now we use JDO as our ORM, it means
> there's nothing else in the framework that requires this semantic.
> 
> The closest alternative is to use JDO embedded objects [1].  Haven't used
> this myself, but I think Oscar has, and think it should work.
> 
> 
> 
>> 3. I would like to know, also, if it is possible to completely eliminate
>> the JDO for storage. Firstly I want to use a fully in-memory storage,
>> without any database (does the DomainObjectContainer support anything like
>> that?) and afterwards something else.
>> 
>> 
> Right now the objectstore API is pluggable, so you can change to an
> in-memory implementation by changing the "isis.persistor" key in
> isis.properties file to "in-memory".
> 
> HOWEVER, doing that will break (or at least disable) some aspects of the
> framework, most notably dirty object tracking (eg as used for auditing
> capability) and also maintenance of bidirectional relationships.
> 
> Accordingly, we are almost certain to remove this pluggable API in the
> future (in Isis 2.0 next year), so that we can continue to slim down the
> Isis framework's responsibilities and focus on domain metamodels and their
> representation.  We might re-introduce a pluggable API in the future, but
> only as a means to supporting other full-fledged persistence solutions (eg
> EclipseLink or Hibernate) that support lazy loading/dirty object tracking
> etc.
> 
> So my recommendation for now is that you stick with use JDO, but configure
> it (in the JDBC URLs in persistor.properties) to use an in-memory database
> (eg HSQLDB as in the archetypes, or H2).
> 
> HTH
> Dan
> 
> 
> 
>> Thank you,
>> Alex
>> 
> 
> 
> [1] http://www.datanucleus.org/products/datanucleus/jdo/orm/embedded.html


Ó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: Questions

[Dan Haywood <da...@haywood-associates.co.uk>]

On 9 December 2014 at 15:32, Alexandru Vladut <al...@gmail.com>
wrote:

> Hi,
>
> I am currently working on a personal project where I try to apply the
> principles of DDD. I am reading Dan's book "Domain Driven Design using
> Naked Objects", trying to adapt the examples to the Isis Framework. During
> my work I found some problems that I need to be clarified:
>

Welcome to the mailing list, Alex.



> 1. The Value-Object pattern seems not to work as in the documentation. It
> says that you need only to annotate your class with @Value and to implement
> the interface ValueSemanticsProvider. But it worked only if I annotated the
> field with @javax.jdo.annotations.Persistent and the getter with
> @org.apache.isis.applib.annotation.NotPersisted. I didn't find any example,
> neither in the SimpleObject nor in ToDoApp. Did I do anything wrong or can
> I find an example anywhere?
>
>
No, you've not done anything wrong... right now we aren't supporting the
@Value semantics.  The primary reason for this is because of our use of
JDO/DataNucleus; there is no equivalent general purpose mechanism (other
than to persist values as serializable byte[] arrays, not exactly
satisfactory).

This is something that I'd like to look at again; not having @Value means
violating DRY, eg using strings and then having to specify the same
semantics the would-be value type is used as a property or a parameter.
But right now pragmatism wins out!



> 2. The aggregates seem not to work (from what I read, it is supported only
> for NoSQL). I read also on the site that it istn't fully supported and its
> use is currently discouraged. What does it mean? Is rather recommended to
> use the Value Types or there is another alternative?
>
>
Again, this arises from using JDO.  Aggregates were necessary as a "hint"
for our old home-grown objectstores, eg NoSQL and XML, to tell it to
persist referenced objects in-line.  Now we use JDO as our ORM, it means
there's nothing else in the framework that requires this semantic.

The closest alternative is to use JDO embedded objects [1].  Haven't used
this myself, but I think Oscar has, and think it should work.



> 3. I would like to know, also, if it is possible to completely eliminate
> the JDO for storage. Firstly I want to use a fully in-memory storage,
> without any database (does the DomainObjectContainer support anything like
> that?) and afterwards something else.
>
>
Right now the objectstore API is pluggable, so you can change to an
in-memory implementation by changing the "isis.persistor" key in
isis.properties file to "in-memory".

HOWEVER, doing that will break (or at least disable) some aspects of the
framework, most notably dirty object tracking (eg as used for auditing
capability) and also maintenance of bidirectional relationships.

Accordingly, we are almost certain to remove this pluggable API in the
future (in Isis 2.0 next year), so that we can continue to slim down the
Isis framework's responsibilities and focus on domain metamodels and their
representation.  We might re-introduce a pluggable API in the future, but
only as a means to supporting other full-fledged persistence solutions (eg
EclipseLink or Hibernate) that support lazy loading/dirty object tracking
etc.

So my recommendation for now is that you stick with use JDO, but configure
it (in the JDBC URLs in persistor.properties) to use an in-memory database
(eg HSQLDB as in the archetypes, or H2).

HTH
Dan



> Thank you,
> Alex
>


[1] http://www.datanucleus.org/products/datanucleus/jdo/orm/embedded.html