You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2013/08/12 12:02:07 UTC
[ANNOUNCE] New committer - Oscar Bou
I'm delighted to announce that Oscar Bou has been voted in as a committer
on Isis, and also to as a member of the Isis PMC. The first gives Oscar
the right to commit changes directly to Isis' codebase, the second gives
him the right to be involved in future votes.
If you've been following the users and dev lists over the last few months,
you can't fail to have seen Oscar's energetic involvement. Oscar came
across Isis while building a similar framework in-house, and has since
worked with his team to port much of their application - still in
development - over to Isis. In so doing, Oscar has provided invaluable
early testing and feedback for new features being implemented.
Oscar has ticked the boxes in terms of being a committer: using the mailing
lists appropriately, raising JIRA tickets, provided patches to address
specific issues, providing help to others in the community. But he's gone
beyond that in raising a number of insightful - sometimes challenging -
questions regarding Isis' design/responsibilities as a framework, and shown
that he's keen to address these issues and thus improve Isis as a product.
I'm looking forward to working with Oscar in the future; another great
addition to Isis' committers.
~~~
As a bit of tidying up, we have also voted for Jeroen van der Wal, and
Maurizio Taverna, to be members of the Isis PMC. In fact, in many/most
Apache projects, all committers are also PMC members, so it was something
of an anomaly that we originally voted Jeroen and Maurizio as just
committers.
Cheers
Dan Haywood
Apache Isis PMC Chair
Re: [ANNOUNCE] New committer - Oscar Bou
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Thanks, David.
> I think there needs to be a continued and strong focus on the generated UI(s) which is frankly the sweet spot for NO/ISIS that is unmatched in any other system.
I fully agree with you.
If we view the app from the classical three tier architecture viewpoint in terms of [1], we traditionally had really good frameworks from "deriving" the "data tier" from the "business tier" (our Isis domain) by using ORM frameworks. The database for the "data tier" was automatically generated from the annotations or from the xml file specifications.
Apache Isis has innovated by allowing the same methods (domain classes annotations and, with the new @MemberGroupLayout and layout.json files, from file specifications) to be available for viewers generating the User Interface, together with all relevant business rules, avoiding "scaffolding" and other traditional techniques (such as configuring widget properties on UI designers) that usually ended on putting business logic on the UI. So it's a really, really big improvement.
As the object-store should be considered as another adapter as in this Rails example [2] (sorry; I've not found a Java based one on a quick search) I consider that domain objects should be sent through the port (for persisting on the adapter) in a valid state. Hence my previous posts regarding validation before persisting.
But the real innovation for me is the way Apache Isis has achieved it: through a meta-model (instead of simple reflection that couldn't understand the semantics of all business rules - hideXXX, validateXXX, etc.) that is available at runtime to be used by all "adapters" (such as the current viewers) interacting with the domain.
I would also introduce here the relevance for that purpose of the RESTFUL Objects specification [3] (I think the link needs to update the specification version currently supported). On the InfoQ article introducing Restful Objects implementation with Isis ([4]), there was a debate about the usefulness of an API that fully publishes all your domain (which is the main argument of detractors). As Dan mentioned there, there is a type of applications that can really benefit from it (enterprise applications for internal use).
But there is another use case that I would consider as really innovative. I think that the RestfulObjects specification is the first well-defined technology-independent API for writing adapters on an Hexagonal architecture pattern. It allows to interact with the domain, and make "generic adapter implementations" that are fully acknowledged of the relevant business rules implemented on the domain. Those "adapters" will be directed towards end-customers that will be internal (requiring knowledge about all the domain, so transparently accesing all the Restful Objects spec) or external (thus requiring a "view" i.e. a subset of the domain).
I fully agree with you that the UI must be a strong focus of Isis. In fact, due to the relevance of the UI on application adoption, I proposed last week public API classes for integrating Apache Isis sessions, transaction management, etc. on custom-defined UIs, for those use cases or those development stages where the domain has been implemented and a better user experience is needed for some domain entities, etc. It's our case in some subdomains, where we must edit a lot of matrices as in [5] in a visual way among other things.
> JDO is good - not sure why we would want to swap to JPA which only supports relational databases.
I didn't knew a word about JDO, and I'm starting to discover it. We haven't fully tested it on production systems, but seems really mature and used among others by the Google App Engine. In fact, the support for inheritance hierarchies and mapped superclasses is better than in JPA, IMHO.
But if we want more people become attracted to Apache Isis, most of them will have experience with JPA (that can be easily ported to JDO; the effort required is really low) and it's really probable that they want to migrate existing projects (at production or initial stages of development) with domain classes annotated with JPA.
The last case was ours. It really intimidated us at the beginning, and was the main stopper for migrating to Isis. As JDO was a an unknown technology, we felt fear. Finally, I can write here that it was a really low effort, as JDO supports ALL JPA annotations, plus some more. So finally it mainly consisted on "find-and-replace" work. Right now, the only remaining uncertainty is how it will work on a production environment, but that's mainly due to that we have no previous experience with it.
Those "fears" and the hope to ease the migration path to Isis for existing projects were the drivers for supporting JPA with DataNucleus on a first milestone, and Hibernate on a second milestone (not currently relevant for us, as we've just migrated to JDO. But perhaps relevant for other dev teams thinking about adopting Isis for new or existing projects).
So JDO is really a great addition (giving support for NoSQL databases, for example) where, once supported, JPA does not introduce "technical benefits", but can bring a bigger user-base (also lowering the risks of adopting Isis).
Hope this has clarified my viewpoints.
Regards,
Oscar
[1] http://en.wikipedia.org/wiki/Multitier_architecture
[2] http://engineering.nulogy.com/posts/hexagonal-architecture-for-rails-developers/
[3] http://isis.apache.org/components/viewers/restfulobjects/about.html
[4] http://www.infoq.com/articles/Intro_Restful_Objects
[5] https://www.google.com/search?q=risk+matrix+example&um=1&ie=UTF-8&hl=es&tbm=isch&source=og&sa=N&tab=wi&ei=AvoJUpfIBofZPPCRgOgM&biw=1280&bih=606&sei=BPoJUq_LF4ec0QXC-YAY
El 13/08/2013, a las 00:39, David Tildesley <da...@yahoo.co.nz> escribió:
> Good stuff Oscar.
>
> A few comments:
>
> I think there needs to be a continued and strong focus on the generated UI(s) which is frankly the sweet spot for NO/ISIS that is unmatched in any other system. DDD is easily achieved without NO/ISIS. For us ISIS is going to live or die based on what we can achieve with the generated UI.
>
> JDO is good - not sure why we would want to swap to JPA which only supports relational databases.
>
> Regards,
> David.
>
>
>
>
> ________________________________
> From: GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
> To: users@isis.apache.org
> Cc: dev <de...@isis.apache.org>
> Sent: Tuesday, 13 August 2013 2:12 AM
> Subject: Re: [ANNOUNCE] New committer - Oscar Bou
>
>
>
> First of all, excuse for this quite long email, but I'm really grateful for being accepted as a committer to Apache Isis, and I would like to express the reasons behind this commitment in the hope it helps other list subscribers to move to Apache Isis, and also to contrast my thoughts.
>
> Our first driver towards moving to Apache Isis was not its automatic UI generation through its viewer technology (which could be seen as its main advantage by some developers). We already had a working app and our own User Interface.
> It was due to the support of a shared vision about the capability to translate the business rules implemented in the domain to all related technologies working with it, including (but not only) the User Interface. It should help a lot in the support of the Hexagonal architecture pattern ([1], [2]). The Apache Isis meta-model has allowed to directly support distinct viewers implemented with different technologies, including the support of a full specification of a REST interface to the core domain [3] (which can ease a lot of internal teams to implement further Hexagonal architecture adapters, such as custom interfaces in different technologies for external teams, in a fully automated and supported manner).
>
>
> I envision Apache Isis as the least risky approach to DDD in common business domains due to the following strengths:
>
> 1. It allows to "start focused" on the highest risk, the domain:
> - With Apache Isis you just have to concentrate on the domain and a custom User Interface and REST API are automatically generated and updated, allowing really fast inputs about the current domain implementation. Work on less-risky areas (such as the UI) can be easily postponed.
>
> 2. It allows to "start easy" when the expectations about the domain complexity are not high, or, at least, not as clear to decide to invest on a "full DDD approach":
> - Implementing a "basic domain" can be nearly as easy as on Microsoft Access by using the current Archetype, the Eclipse templates and the available Viewers (as the Apache Wicket viewer for automating the webapp implementation).
> - As new business rules are discovered, they can be incorporated to the Apache Isis domain, and are automatically propagated to (used by) the viewers.
> - Unlike scaffolding technologies, the user interface and other architectural adapters behave "dynamically" and adapt "intelligently" to the current domain implementation by means of the Apache Isis meta-model, which eases a lot the domain improvements, application maintenance and technology upgrades.
>
> 3. It eases to start, explore and evolve the domain with full domain testability, through the new support for Behavior-Driven Development:
> - The business expert and the developer can work together on defining features and business scenarios that can be implemented and tested with Apache Isis.
> - And as the user interface, the BDD behavior, the fixtures, etc. are supported by Isis, it allows really rapid iteration cycles focusing on the domain, so the project risk is rapidly detected and minimized by the experts and developers.
>
>
> As in all software projects, there is space for improvement, and it could be among others in the following areas:
>
> * Improved "domain business rules support". It must be the core strength of Apache Isis (where the viewer and other related technologies are a "derivative work"). And it could include:
> - domain objects that behave by default conforming to all business rules defined (i.e., "wrapped by default", a controversial point, I'm sure),
> - direct JSR-349 supporting facets, etc.
>
> * Support for migrating existing projects to Apache Isis. There is a high and fast growth vector for the community by being adopted by currently existing applications. But for that, official APIs should be provided for:
> - "Custom viewers support": easing the interaction with custom-made pre-existing User Interfaces (through the REST API, but also through Java APIs). It should include fully-supported API classes or interfaces for Apache Isis session handling, transaction management, etc.
> - JPA support: most Java applications use at the persistent layer the JPA API or the custom Hibernate API. The initial support for JPA could be based on DataNucleus, allowing to migrate all persistent domain classes and logic inside them. Directly supporting other persistence ORM platforms is a bigger effort that could be postponed in my opinion.
>
> * More project examples available.
> - We traditionally had the ToDo example on the archetype, the "claims" example of the Naked Objects book, the excellent "Transport Planner" application, and few more examples (perhaps a web page is needed for referencing together all available examples?).
> - The "Estatio" project has been a milestone for Apache Isis, and we are constantly exploring it. There are quite "hidden gems" inside it about Apache Isis implementation, but also about "generic" domain implementation (as the Interfaces "decorating" the entities, the domain layer superclasses, the BDD cases, etc.). So many thanks for publishing it (and convincing the customer's management team :-).
> - We are currently working "against the clock" in our project, but it would be really interesting if anybody in the community could lead the implementation of a well-known DDD example, where we could contribute. It would be great if the "Implementing DDD" example project could be implemented using latest Apache Isis capabilities (with the consent of the author, Vaughn Vernon). It could help to validate current DDD support in Apache Isis, and to discover areas of improvement (such as classes for directly supporting the implementation of tactical patterns, but also for projects partitioned on different Bounded Contexts). Vaughn Vernon has made the effort of participating on the consensus and putting together some of the most agreed DDD implementation best-practices. Some of them can be implemented as-is on Apache Isis, some others must be adapted, and some others can be discarded or replaced by other implementation strategies that benefit from current
> Apache Isis capabilities and/or supporting technologies. I'm sure its an exercise that can help to improve the Apache Isis framework, and the use and acknowledgement of Apache Isis by the DDD community.
>
>
> Well, excuse me again for this long email and hope this helps to those evaluating Apache Isis.
>
> Yours sincerely,
>
> Oscar Bou
>
>
>
>
> [1] http://isis.apache.org/learning-more/hexagonal-architecture.html
>
> [2] http://alistair.cockburn.us/Hexagonal+architecture
>
> [3] http://isis.apache.org/components/viewers/restfulobjects/about.html
>
>
>
>
> El 12/08/2013, a las 12:02, Dan Haywood <da...@haywood-associates.co.uk> escribió:
>
>> I'm delighted to announce that Oscar Bou has been voted in as a committer
>> on Isis, and also to as a member of the Isis PMC. The first gives Oscar
>> the right to commit changes directly to Isis' codebase, the second gives
>> him the right to be involved in future votes.
>>
>> If you've been following the users and dev lists over the last few months,
>> you can't fail to have seen Oscar's energetic involvement. Oscar came
>> across Isis while building a similar framework in-house, and has since
>> worked with his team to port much of their application - still in
>> development - over to Isis. In so doing, Oscar has provided invaluable
>> early testing and feedback for new features being implemented.
>>
>> Oscar has ticked the boxes in terms of being a committer: using the mailing
>> lists appropriately, raising JIRA tickets, provided patches to address
>> specific issues, providing help to others in the community. But he's gone
>> beyond that in raising a number of insightful - sometimes challenging -
>> questions regarding Isis' design/responsibilities as a framework, and shown
>> that he's keen to address these issues and thus improve Isis as a product.
>>
>> I'm looking forward to working with Oscar in the future; another great
>> addition to Isis' committers.
>>
>> ~~~
>> As a bit of tidying up, we have also voted for Jeroen van der Wal, and
>> Maurizio Taverna, to be members of the Isis PMC. In fact, in many/most
>> Apache projects, all committers are also PMC members, so it was something
>> of an anomaly that we originally voted Jeroen and Maurizio as just
>> committers.
>>
>> Cheers
>> Dan Haywood
>> Apache Isis PMC Chair
Re: [ANNOUNCE] New committer - Oscar Bou
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Thanks, David.
> I think there needs to be a continued and strong focus on the generated UI(s) which is frankly the sweet spot for NO/ISIS that is unmatched in any other system.
I fully agree with you.
If we view the app from the classical three tier architecture viewpoint in terms of [1], we traditionally had really good frameworks from "deriving" the "data tier" from the "business tier" (our Isis domain) by using ORM frameworks. The database for the "data tier" was automatically generated from the annotations or from the xml file specifications.
Apache Isis has innovated by allowing the same methods (domain classes annotations and, with the new @MemberGroupLayout and layout.json files, from file specifications) to be available for viewers generating the User Interface, together with all relevant business rules, avoiding "scaffolding" and other traditional techniques (such as configuring widget properties on UI designers) that usually ended on putting business logic on the UI. So it's a really, really big improvement.
As the object-store should be considered as another adapter as in this Rails example [2] (sorry; I've not found a Java based one on a quick search) I consider that domain objects should be sent through the port (for persisting on the adapter) in a valid state. Hence my previous posts regarding validation before persisting.
But the real innovation for me is the way Apache Isis has achieved it: through a meta-model (instead of simple reflection that couldn't understand the semantics of all business rules - hideXXX, validateXXX, etc.) that is available at runtime to be used by all "adapters" (such as the current viewers) interacting with the domain.
I would also introduce here the relevance for that purpose of the RESTFUL Objects specification [3] (I think the link needs to update the specification version currently supported). On the InfoQ article introducing Restful Objects implementation with Isis ([4]), there was a debate about the usefulness of an API that fully publishes all your domain (which is the main argument of detractors). As Dan mentioned there, there is a type of applications that can really benefit from it (enterprise applications for internal use).
But there is another use case that I would consider as really innovative. I think that the RestfulObjects specification is the first well-defined technology-independent API for writing adapters on an Hexagonal architecture pattern. It allows to interact with the domain, and make "generic adapter implementations" that are fully acknowledged of the relevant business rules implemented on the domain. Those "adapters" will be directed towards end-customers that will be internal (requiring knowledge about all the domain, so transparently accesing all the Restful Objects spec) or external (thus requiring a "view" i.e. a subset of the domain).
I fully agree with you that the UI must be a strong focus of Isis. In fact, due to the relevance of the UI on application adoption, I proposed last week public API classes for integrating Apache Isis sessions, transaction management, etc. on custom-defined UIs, for those use cases or those development stages where the domain has been implemented and a better user experience is needed for some domain entities, etc. It's our case in some subdomains, where we must edit a lot of matrices as in [5] in a visual way among other things.
> JDO is good - not sure why we would want to swap to JPA which only supports relational databases.
I didn't knew a word about JDO, and I'm starting to discover it. We haven't fully tested it on production systems, but seems really mature and used among others by the Google App Engine. In fact, the support for inheritance hierarchies and mapped superclasses is better than in JPA, IMHO.
But if we want more people become attracted to Apache Isis, most of them will have experience with JPA (that can be easily ported to JDO; the effort required is really low) and it's really probable that they want to migrate existing projects (at production or initial stages of development) with domain classes annotated with JPA.
The last case was ours. It really intimidated us at the beginning, and was the main stopper for migrating to Isis. As JDO was a an unknown technology, we felt fear. Finally, I can write here that it was a really low effort, as JDO supports ALL JPA annotations, plus some more. So finally it mainly consisted on "find-and-replace" work. Right now, the only remaining uncertainty is how it will work on a production environment, but that's mainly due to that we have no previous experience with it.
Those "fears" and the hope to ease the migration path to Isis for existing projects were the drivers for supporting JPA with DataNucleus on a first milestone, and Hibernate on a second milestone (not currently relevant for us, as we've just migrated to JDO. But perhaps relevant for other dev teams thinking about adopting Isis for new or existing projects).
So JDO is really a great addition (giving support for NoSQL databases, for example) where, once supported, JPA does not introduce "technical benefits", but can bring a bigger user-base (also lowering the risks of adopting Isis).
Hope this has clarified my viewpoints.
Regards,
Oscar
[1] http://en.wikipedia.org/wiki/Multitier_architecture
[2] http://engineering.nulogy.com/posts/hexagonal-architecture-for-rails-developers/
[3] http://isis.apache.org/components/viewers/restfulobjects/about.html
[4] http://www.infoq.com/articles/Intro_Restful_Objects
[5] https://www.google.com/search?q=risk+matrix+example&um=1&ie=UTF-8&hl=es&tbm=isch&source=og&sa=N&tab=wi&ei=AvoJUpfIBofZPPCRgOgM&biw=1280&bih=606&sei=BPoJUq_LF4ec0QXC-YAY
El 13/08/2013, a las 00:39, David Tildesley <da...@yahoo.co.nz> escribió:
> Good stuff Oscar.
>
> A few comments:
>
> I think there needs to be a continued and strong focus on the generated UI(s) which is frankly the sweet spot for NO/ISIS that is unmatched in any other system. DDD is easily achieved without NO/ISIS. For us ISIS is going to live or die based on what we can achieve with the generated UI.
>
> JDO is good - not sure why we would want to swap to JPA which only supports relational databases.
>
> Regards,
> David.
>
>
>
>
> ________________________________
> From: GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
> To: users@isis.apache.org
> Cc: dev <de...@isis.apache.org>
> Sent: Tuesday, 13 August 2013 2:12 AM
> Subject: Re: [ANNOUNCE] New committer - Oscar Bou
>
>
>
> First of all, excuse for this quite long email, but I'm really grateful for being accepted as a committer to Apache Isis, and I would like to express the reasons behind this commitment in the hope it helps other list subscribers to move to Apache Isis, and also to contrast my thoughts.
>
> Our first driver towards moving to Apache Isis was not its automatic UI generation through its viewer technology (which could be seen as its main advantage by some developers). We already had a working app and our own User Interface.
> It was due to the support of a shared vision about the capability to translate the business rules implemented in the domain to all related technologies working with it, including (but not only) the User Interface. It should help a lot in the support of the Hexagonal architecture pattern ([1], [2]). The Apache Isis meta-model has allowed to directly support distinct viewers implemented with different technologies, including the support of a full specification of a REST interface to the core domain [3] (which can ease a lot of internal teams to implement further Hexagonal architecture adapters, such as custom interfaces in different technologies for external teams, in a fully automated and supported manner).
>
>
> I envision Apache Isis as the least risky approach to DDD in common business domains due to the following strengths:
>
> 1. It allows to "start focused" on the highest risk, the domain:
> - With Apache Isis you just have to concentrate on the domain and a custom User Interface and REST API are automatically generated and updated, allowing really fast inputs about the current domain implementation. Work on less-risky areas (such as the UI) can be easily postponed.
>
> 2. It allows to "start easy" when the expectations about the domain complexity are not high, or, at least, not as clear to decide to invest on a "full DDD approach":
> - Implementing a "basic domain" can be nearly as easy as on Microsoft Access by using the current Archetype, the Eclipse templates and the available Viewers (as the Apache Wicket viewer for automating the webapp implementation).
> - As new business rules are discovered, they can be incorporated to the Apache Isis domain, and are automatically propagated to (used by) the viewers.
> - Unlike scaffolding technologies, the user interface and other architectural adapters behave "dynamically" and adapt "intelligently" to the current domain implementation by means of the Apache Isis meta-model, which eases a lot the domain improvements, application maintenance and technology upgrades.
>
> 3. It eases to start, explore and evolve the domain with full domain testability, through the new support for Behavior-Driven Development:
> - The business expert and the developer can work together on defining features and business scenarios that can be implemented and tested with Apache Isis.
> - And as the user interface, the BDD behavior, the fixtures, etc. are supported by Isis, it allows really rapid iteration cycles focusing on the domain, so the project risk is rapidly detected and minimized by the experts and developers.
>
>
> As in all software projects, there is space for improvement, and it could be among others in the following areas:
>
> * Improved "domain business rules support". It must be the core strength of Apache Isis (where the viewer and other related technologies are a "derivative work"). And it could include:
> - domain objects that behave by default conforming to all business rules defined (i.e., "wrapped by default", a controversial point, I'm sure),
> - direct JSR-349 supporting facets, etc.
>
> * Support for migrating existing projects to Apache Isis. There is a high and fast growth vector for the community by being adopted by currently existing applications. But for that, official APIs should be provided for:
> - "Custom viewers support": easing the interaction with custom-made pre-existing User Interfaces (through the REST API, but also through Java APIs). It should include fully-supported API classes or interfaces for Apache Isis session handling, transaction management, etc.
> - JPA support: most Java applications use at the persistent layer the JPA API or the custom Hibernate API. The initial support for JPA could be based on DataNucleus, allowing to migrate all persistent domain classes and logic inside them. Directly supporting other persistence ORM platforms is a bigger effort that could be postponed in my opinion.
>
> * More project examples available.
> - We traditionally had the ToDo example on the archetype, the "claims" example of the Naked Objects book, the excellent "Transport Planner" application, and few more examples (perhaps a web page is needed for referencing together all available examples?).
> - The "Estatio" project has been a milestone for Apache Isis, and we are constantly exploring it. There are quite "hidden gems" inside it about Apache Isis implementation, but also about "generic" domain implementation (as the Interfaces "decorating" the entities, the domain layer superclasses, the BDD cases, etc.). So many thanks for publishing it (and convincing the customer's management team :-).
> - We are currently working "against the clock" in our project, but it would be really interesting if anybody in the community could lead the implementation of a well-known DDD example, where we could contribute. It would be great if the "Implementing DDD" example project could be implemented using latest Apache Isis capabilities (with the consent of the author, Vaughn Vernon). It could help to validate current DDD support in Apache Isis, and to discover areas of improvement (such as classes for directly supporting the implementation of tactical patterns, but also for projects partitioned on different Bounded Contexts). Vaughn Vernon has made the effort of participating on the consensus and putting together some of the most agreed DDD implementation best-practices. Some of them can be implemented as-is on Apache Isis, some others must be adapted, and some others can be discarded or replaced by other implementation strategies that benefit from current
> Apache Isis capabilities and/or supporting technologies. I'm sure its an exercise that can help to improve the Apache Isis framework, and the use and acknowledgement of Apache Isis by the DDD community.
>
>
> Well, excuse me again for this long email and hope this helps to those evaluating Apache Isis.
>
> Yours sincerely,
>
> Oscar Bou
>
>
>
>
> [1] http://isis.apache.org/learning-more/hexagonal-architecture.html
>
> [2] http://alistair.cockburn.us/Hexagonal+architecture
>
> [3] http://isis.apache.org/components/viewers/restfulobjects/about.html
>
>
>
>
> El 12/08/2013, a las 12:02, Dan Haywood <da...@haywood-associates.co.uk> escribió:
>
>> I'm delighted to announce that Oscar Bou has been voted in as a committer
>> on Isis, and also to as a member of the Isis PMC. The first gives Oscar
>> the right to commit changes directly to Isis' codebase, the second gives
>> him the right to be involved in future votes.
>>
>> If you've been following the users and dev lists over the last few months,
>> you can't fail to have seen Oscar's energetic involvement. Oscar came
>> across Isis while building a similar framework in-house, and has since
>> worked with his team to port much of their application - still in
>> development - over to Isis. In so doing, Oscar has provided invaluable
>> early testing and feedback for new features being implemented.
>>
>> Oscar has ticked the boxes in terms of being a committer: using the mailing
>> lists appropriately, raising JIRA tickets, provided patches to address
>> specific issues, providing help to others in the community. But he's gone
>> beyond that in raising a number of insightful - sometimes challenging -
>> questions regarding Isis' design/responsibilities as a framework, and shown
>> that he's keen to address these issues and thus improve Isis as a product.
>>
>> I'm looking forward to working with Oscar in the future; another great
>> addition to Isis' committers.
>>
>> ~~~
>> As a bit of tidying up, we have also voted for Jeroen van der Wal, and
>> Maurizio Taverna, to be members of the Isis PMC. In fact, in many/most
>> Apache projects, all committers are also PMC members, so it was something
>> of an anomaly that we originally voted Jeroen and Maurizio as just
>> committers.
>>
>> Cheers
>> Dan Haywood
>> Apache Isis PMC Chair
Re: [ANNOUNCE] New committer - Oscar Bou
Posted by David Tildesley <da...@yahoo.co.nz>.
Good stuff Oscar.
A few comments:
I think there needs to be a continued and strong focus on the generated UI(s) which is frankly the sweet spot for NO/ISIS that is unmatched in any other system. DDD is easily achieved without NO/ISIS. For us ISIS is going to live or die based on what we can achieve with the generated UI.
JDO is good - not sure why we would want to swap to JPA which only supports relational databases.
Regards,
David.
________________________________
From: GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
To: users@isis.apache.org
Cc: dev <de...@isis.apache.org>
Sent: Tuesday, 13 August 2013 2:12 AM
Subject: Re: [ANNOUNCE] New committer - Oscar Bou
First of all, excuse for this quite long email, but I'm really grateful for being accepted as a committer to Apache Isis, and I would like to express the reasons behind this commitment in the hope it helps other list subscribers to move to Apache Isis, and also to contrast my thoughts.
Our first driver towards moving to Apache Isis was not its automatic UI generation through its viewer technology (which could be seen as its main advantage by some developers). We already had a working app and our own User Interface.
It was due to the support of a shared vision about the capability to translate the business rules implemented in the domain to all related technologies working with it, including (but not only) the User Interface. It should help a lot in the support of the Hexagonal architecture pattern ([1], [2]). The Apache Isis meta-model has allowed to directly support distinct viewers implemented with different technologies, including the support of a full specification of a REST interface to the core domain [3] (which can ease a lot of internal teams to implement further Hexagonal architecture adapters, such as custom interfaces in different technologies for external teams, in a fully automated and supported manner).
I envision Apache Isis as the least risky approach to DDD in common business domains due to the following strengths:
1. It allows to "start focused" on the highest risk, the domain:
- With Apache Isis you just have to concentrate on the domain and a custom User Interface and REST API are automatically generated and updated, allowing really fast inputs about the current domain implementation. Work on less-risky areas (such as the UI) can be easily postponed.
2. It allows to "start easy" when the expectations about the domain complexity are not high, or, at least, not as clear to decide to invest on a "full DDD approach":
- Implementing a "basic domain" can be nearly as easy as on Microsoft Access by using the current Archetype, the Eclipse templates and the available Viewers (as the Apache Wicket viewer for automating the webapp implementation).
- As new business rules are discovered, they can be incorporated to the Apache Isis domain, and are automatically propagated to (used by) the viewers.
- Unlike scaffolding technologies, the user interface and other architectural adapters behave "dynamically" and adapt "intelligently" to the current domain implementation by means of the Apache Isis meta-model, which eases a lot the domain improvements, application maintenance and technology upgrades.
3. It eases to start, explore and evolve the domain with full domain testability, through the new support for Behavior-Driven Development:
- The business expert and the developer can work together on defining features and business scenarios that can be implemented and tested with Apache Isis.
- And as the user interface, the BDD behavior, the fixtures, etc. are supported by Isis, it allows really rapid iteration cycles focusing on the domain, so the project risk is rapidly detected and minimized by the experts and developers.
As in all software projects, there is space for improvement, and it could be among others in the following areas:
* Improved "domain business rules support". It must be the core strength of Apache Isis (where the viewer and other related technologies are a "derivative work"). And it could include:
- domain objects that behave by default conforming to all business rules defined (i.e., "wrapped by default", a controversial point, I'm sure),
- direct JSR-349 supporting facets, etc.
* Support for migrating existing projects to Apache Isis. There is a high and fast growth vector for the community by being adopted by currently existing applications. But for that, official APIs should be provided for:
- "Custom viewers support": easing the interaction with custom-made pre-existing User Interfaces (through the REST API, but also through Java APIs). It should include fully-supported API classes or interfaces for Apache Isis session handling, transaction management, etc.
- JPA support: most Java applications use at the persistent layer the JPA API or the custom Hibernate API. The initial support for JPA could be based on DataNucleus, allowing to migrate all persistent domain classes and logic inside them. Directly supporting other persistence ORM platforms is a bigger effort that could be postponed in my opinion.
* More project examples available.
- We traditionally had the ToDo example on the archetype, the "claims" example of the Naked Objects book, the excellent "Transport Planner" application, and few more examples (perhaps a web page is needed for referencing together all available examples?).
- The "Estatio" project has been a milestone for Apache Isis, and we are constantly exploring it. There are quite "hidden gems" inside it about Apache Isis implementation, but also about "generic" domain implementation (as the Interfaces "decorating" the entities, the domain layer superclasses, the BDD cases, etc.). So many thanks for publishing it (and convincing the customer's management team :-).
- We are currently working "against the clock" in our project, but it would be really interesting if anybody in the community could lead the implementation of a well-known DDD example, where we could contribute. It would be great if the "Implementing DDD" example project could be implemented using latest Apache Isis capabilities (with the consent of the author, Vaughn Vernon). It could help to validate current DDD support in Apache Isis, and to discover areas of improvement (such as classes for directly supporting the implementation of tactical patterns, but also for projects partitioned on different Bounded Contexts). Vaughn Vernon has made the effort of participating on the consensus and putting together some of the most agreed DDD implementation best-practices. Some of them can be implemented as-is on Apache Isis, some others must be adapted, and some others can be discarded or replaced by other implementation strategies that benefit from current
Apache Isis capabilities and/or supporting technologies. I'm sure its an exercise that can help to improve the Apache Isis framework, and the use and acknowledgement of Apache Isis by the DDD community.
Well, excuse me again for this long email and hope this helps to those evaluating Apache Isis.
Yours sincerely,
Oscar Bou
[1] http://isis.apache.org/learning-more/hexagonal-architecture.html
[2] http://alistair.cockburn.us/Hexagonal+architecture
[3] http://isis.apache.org/components/viewers/restfulobjects/about.html
El 12/08/2013, a las 12:02, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> I'm delighted to announce that Oscar Bou has been voted in as a committer
> on Isis, and also to as a member of the Isis PMC. The first gives Oscar
> the right to commit changes directly to Isis' codebase, the second gives
> him the right to be involved in future votes.
>
> If you've been following the users and dev lists over the last few months,
> you can't fail to have seen Oscar's energetic involvement. Oscar came
> across Isis while building a similar framework in-house, and has since
> worked with his team to port much of their application - still in
> development - over to Isis. In so doing, Oscar has provided invaluable
> early testing and feedback for new features being implemented.
>
> Oscar has ticked the boxes in terms of being a committer: using the mailing
> lists appropriately, raising JIRA tickets, provided patches to address
> specific issues, providing help to others in the community. But he's gone
> beyond that in raising a number of insightful - sometimes challenging -
> questions regarding Isis' design/responsibilities as a framework, and shown
> that he's keen to address these issues and thus improve Isis as a product.
>
> I'm looking forward to working with Oscar in the future; another great
> addition to Isis' committers.
>
> ~~~
> As a bit of tidying up, we have also voted for Jeroen van der Wal, and
> Maurizio Taverna, to be members of the Isis PMC. In fact, in many/most
> Apache projects, all committers are also PMC members, so it was something
> of an anomaly that we originally voted Jeroen and Maurizio as just
> committers.
>
> Cheers
> Dan Haywood
> Apache Isis PMC Chair
Re: [ANNOUNCE] New committer - Oscar Bou
Posted by David Tildesley <da...@yahoo.co.nz>.
Good stuff Oscar.
A few comments:
I think there needs to be a continued and strong focus on the generated UI(s) which is frankly the sweet spot for NO/ISIS that is unmatched in any other system. DDD is easily achieved without NO/ISIS. For us ISIS is going to live or die based on what we can achieve with the generated UI.
JDO is good - not sure why we would want to swap to JPA which only supports relational databases.
Regards,
David.
________________________________
From: GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
To: users@isis.apache.org
Cc: dev <de...@isis.apache.org>
Sent: Tuesday, 13 August 2013 2:12 AM
Subject: Re: [ANNOUNCE] New committer - Oscar Bou
First of all, excuse for this quite long email, but I'm really grateful for being accepted as a committer to Apache Isis, and I would like to express the reasons behind this commitment in the hope it helps other list subscribers to move to Apache Isis, and also to contrast my thoughts.
Our first driver towards moving to Apache Isis was not its automatic UI generation through its viewer technology (which could be seen as its main advantage by some developers). We already had a working app and our own User Interface.
It was due to the support of a shared vision about the capability to translate the business rules implemented in the domain to all related technologies working with it, including (but not only) the User Interface. It should help a lot in the support of the Hexagonal architecture pattern ([1], [2]). The Apache Isis meta-model has allowed to directly support distinct viewers implemented with different technologies, including the support of a full specification of a REST interface to the core domain [3] (which can ease a lot of internal teams to implement further Hexagonal architecture adapters, such as custom interfaces in different technologies for external teams, in a fully automated and supported manner).
I envision Apache Isis as the least risky approach to DDD in common business domains due to the following strengths:
1. It allows to "start focused" on the highest risk, the domain:
- With Apache Isis you just have to concentrate on the domain and a custom User Interface and REST API are automatically generated and updated, allowing really fast inputs about the current domain implementation. Work on less-risky areas (such as the UI) can be easily postponed.
2. It allows to "start easy" when the expectations about the domain complexity are not high, or, at least, not as clear to decide to invest on a "full DDD approach":
- Implementing a "basic domain" can be nearly as easy as on Microsoft Access by using the current Archetype, the Eclipse templates and the available Viewers (as the Apache Wicket viewer for automating the webapp implementation).
- As new business rules are discovered, they can be incorporated to the Apache Isis domain, and are automatically propagated to (used by) the viewers.
- Unlike scaffolding technologies, the user interface and other architectural adapters behave "dynamically" and adapt "intelligently" to the current domain implementation by means of the Apache Isis meta-model, which eases a lot the domain improvements, application maintenance and technology upgrades.
3. It eases to start, explore and evolve the domain with full domain testability, through the new support for Behavior-Driven Development:
- The business expert and the developer can work together on defining features and business scenarios that can be implemented and tested with Apache Isis.
- And as the user interface, the BDD behavior, the fixtures, etc. are supported by Isis, it allows really rapid iteration cycles focusing on the domain, so the project risk is rapidly detected and minimized by the experts and developers.
As in all software projects, there is space for improvement, and it could be among others in the following areas:
* Improved "domain business rules support". It must be the core strength of Apache Isis (where the viewer and other related technologies are a "derivative work"). And it could include:
- domain objects that behave by default conforming to all business rules defined (i.e., "wrapped by default", a controversial point, I'm sure),
- direct JSR-349 supporting facets, etc.
* Support for migrating existing projects to Apache Isis. There is a high and fast growth vector for the community by being adopted by currently existing applications. But for that, official APIs should be provided for:
- "Custom viewers support": easing the interaction with custom-made pre-existing User Interfaces (through the REST API, but also through Java APIs). It should include fully-supported API classes or interfaces for Apache Isis session handling, transaction management, etc.
- JPA support: most Java applications use at the persistent layer the JPA API or the custom Hibernate API. The initial support for JPA could be based on DataNucleus, allowing to migrate all persistent domain classes and logic inside them. Directly supporting other persistence ORM platforms is a bigger effort that could be postponed in my opinion.
* More project examples available.
- We traditionally had the ToDo example on the archetype, the "claims" example of the Naked Objects book, the excellent "Transport Planner" application, and few more examples (perhaps a web page is needed for referencing together all available examples?).
- The "Estatio" project has been a milestone for Apache Isis, and we are constantly exploring it. There are quite "hidden gems" inside it about Apache Isis implementation, but also about "generic" domain implementation (as the Interfaces "decorating" the entities, the domain layer superclasses, the BDD cases, etc.). So many thanks for publishing it (and convincing the customer's management team :-).
- We are currently working "against the clock" in our project, but it would be really interesting if anybody in the community could lead the implementation of a well-known DDD example, where we could contribute. It would be great if the "Implementing DDD" example project could be implemented using latest Apache Isis capabilities (with the consent of the author, Vaughn Vernon). It could help to validate current DDD support in Apache Isis, and to discover areas of improvement (such as classes for directly supporting the implementation of tactical patterns, but also for projects partitioned on different Bounded Contexts). Vaughn Vernon has made the effort of participating on the consensus and putting together some of the most agreed DDD implementation best-practices. Some of them can be implemented as-is on Apache Isis, some others must be adapted, and some others can be discarded or replaced by other implementation strategies that benefit from current
Apache Isis capabilities and/or supporting technologies. I'm sure its an exercise that can help to improve the Apache Isis framework, and the use and acknowledgement of Apache Isis by the DDD community.
Well, excuse me again for this long email and hope this helps to those evaluating Apache Isis.
Yours sincerely,
Oscar Bou
[1] http://isis.apache.org/learning-more/hexagonal-architecture.html
[2] http://alistair.cockburn.us/Hexagonal+architecture
[3] http://isis.apache.org/components/viewers/restfulobjects/about.html
El 12/08/2013, a las 12:02, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> I'm delighted to announce that Oscar Bou has been voted in as a committer
> on Isis, and also to as a member of the Isis PMC. The first gives Oscar
> the right to commit changes directly to Isis' codebase, the second gives
> him the right to be involved in future votes.
>
> If you've been following the users and dev lists over the last few months,
> you can't fail to have seen Oscar's energetic involvement. Oscar came
> across Isis while building a similar framework in-house, and has since
> worked with his team to port much of their application - still in
> development - over to Isis. In so doing, Oscar has provided invaluable
> early testing and feedback for new features being implemented.
>
> Oscar has ticked the boxes in terms of being a committer: using the mailing
> lists appropriately, raising JIRA tickets, provided patches to address
> specific issues, providing help to others in the community. But he's gone
> beyond that in raising a number of insightful - sometimes challenging -
> questions regarding Isis' design/responsibilities as a framework, and shown
> that he's keen to address these issues and thus improve Isis as a product.
>
> I'm looking forward to working with Oscar in the future; another great
> addition to Isis' committers.
>
> ~~~
> As a bit of tidying up, we have also voted for Jeroen van der Wal, and
> Maurizio Taverna, to be members of the Isis PMC. In fact, in many/most
> Apache projects, all committers are also PMC members, so it was something
> of an anomaly that we originally voted Jeroen and Maurizio as just
> committers.
>
> Cheers
> Dan Haywood
> Apache Isis PMC Chair
Re: [ANNOUNCE] New committer - Oscar Bou
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
First of all, excuse for this quite long email, but I'm really grateful for being accepted as a committer to Apache Isis, and I would like to express the reasons behind this commitment in the hope it helps other list subscribers to move to Apache Isis, and also to contrast my thoughts.
Our first driver towards moving to Apache Isis was not its automatic UI generation through its viewer technology (which could be seen as its main advantage by some developers). We already had a working app and our own User Interface.
It was due to the support of a shared vision about the capability to translate the business rules implemented in the domain to all related technologies working with it, including (but not only) the User Interface. It should help a lot in the support of the Hexagonal architecture pattern ([1], [2]). The Apache Isis meta-model has allowed to directly support distinct viewers implemented with different technologies, including the support of a full specification of a REST interface to the core domain [3] (which can ease a lot of internal teams to implement further Hexagonal architecture adapters, such as custom interfaces in different technologies for external teams, in a fully automated and supported manner).
I envision Apache Isis as the least risky approach to DDD in common business domains due to the following strengths:
1. It allows to "start focused" on the highest risk, the domain:
- With Apache Isis you just have to concentrate on the domain and a custom User Interface and REST API are automatically generated and updated, allowing really fast inputs about the current domain implementation. Work on less-risky areas (such as the UI) can be easily postponed.
2. It allows to "start easy" when the expectations about the domain complexity are not high, or, at least, not as clear to decide to invest on a "full DDD approach":
- Implementing a "basic domain" can be nearly as easy as on Microsoft Access by using the current Archetype, the Eclipse templates and the available Viewers (as the Apache Wicket viewer for automating the webapp implementation).
- As new business rules are discovered, they can be incorporated to the Apache Isis domain, and are automatically propagated to (used by) the viewers.
- Unlike scaffolding technologies, the user interface and other architectural adapters behave "dynamically" and adapt "intelligently" to the current domain implementation by means of the Apache Isis meta-model, which eases a lot the domain improvements, application maintenance and technology upgrades.
3. It eases to start, explore and evolve the domain with full domain testability, through the new support for Behavior-Driven Development:
- The business expert and the developer can work together on defining features and business scenarios that can be implemented and tested with Apache Isis.
- And as the user interface, the BDD behavior, the fixtures, etc. are supported by Isis, it allows really rapid iteration cycles focusing on the domain, so the project risk is rapidly detected and minimized by the experts and developers.
As in all software projects, there is space for improvement, and it could be among others in the following areas:
* Improved "domain business rules support". It must be the core strength of Apache Isis (where the viewer and other related technologies are a "derivative work"). And it could include:
- domain objects that behave by default conforming to all business rules defined (i.e., "wrapped by default", a controversial point, I'm sure),
- direct JSR-349 supporting facets, etc.
* Support for migrating existing projects to Apache Isis. There is a high and fast growth vector for the community by being adopted by currently existing applications. But for that, official APIs should be provided for:
- "Custom viewers support": easing the interaction with custom-made pre-existing User Interfaces (through the REST API, but also through Java APIs). It should include fully-supported API classes or interfaces for Apache Isis session handling, transaction management, etc.
- JPA support: most Java applications use at the persistent layer the JPA API or the custom Hibernate API. The initial support for JPA could be based on DataNucleus, allowing to migrate all persistent domain classes and logic inside them. Directly supporting other persistence ORM platforms is a bigger effort that could be postponed in my opinion.
* More project examples available.
- We traditionally had the ToDo example on the archetype, the "claims" example of the Naked Objects book, the excellent "Transport Planner" application, and few more examples (perhaps a web page is needed for referencing together all available examples?).
- The "Estatio" project has been a milestone for Apache Isis, and we are constantly exploring it. There are quite "hidden gems" inside it about Apache Isis implementation, but also about "generic" domain implementation (as the Interfaces "decorating" the entities, the domain layer superclasses, the BDD cases, etc.). So many thanks for publishing it (and convincing the customer's management team :-).
- We are currently working "against the clock" in our project, but it would be really interesting if anybody in the community could lead the implementation of a well-known DDD example, where we could contribute. It would be great if the "Implementing DDD" example project could be implemented using latest Apache Isis capabilities (with the consent of the author, Vaughn Vernon). It could help to validate current DDD support in Apache Isis, and to discover areas of improvement (such as classes for directly supporting the implementation of tactical patterns, but also for projects partitioned on different Bounded Contexts). Vaughn Vernon has made the effort of participating on the consensus and putting together some of the most agreed DDD implementation best-practices. Some of them can be implemented as-is on Apache Isis, some others must be adapted, and some others can be discarded or replaced by other implementation strategies that benefit from current Apache Isis capabilities and/or supporting technologies. I'm sure its an exercise that can help to improve the Apache Isis framework, and the use and acknowledgement of Apache Isis by the DDD community.
Well, excuse me again for this long email and hope this helps to those evaluating Apache Isis.
Yours sincerely,
Oscar Bou
[1] http://isis.apache.org/learning-more/hexagonal-architecture.html
[2] http://alistair.cockburn.us/Hexagonal+architecture
[3] http://isis.apache.org/components/viewers/restfulobjects/about.html
El 12/08/2013, a las 12:02, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> I'm delighted to announce that Oscar Bou has been voted in as a committer
> on Isis, and also to as a member of the Isis PMC. The first gives Oscar
> the right to commit changes directly to Isis' codebase, the second gives
> him the right to be involved in future votes.
>
> If you've been following the users and dev lists over the last few months,
> you can't fail to have seen Oscar's energetic involvement. Oscar came
> across Isis while building a similar framework in-house, and has since
> worked with his team to port much of their application - still in
> development - over to Isis. In so doing, Oscar has provided invaluable
> early testing and feedback for new features being implemented.
>
> Oscar has ticked the boxes in terms of being a committer: using the mailing
> lists appropriately, raising JIRA tickets, provided patches to address
> specific issues, providing help to others in the community. But he's gone
> beyond that in raising a number of insightful - sometimes challenging -
> questions regarding Isis' design/responsibilities as a framework, and shown
> that he's keen to address these issues and thus improve Isis as a product.
>
> I'm looking forward to working with Oscar in the future; another great
> addition to Isis' committers.
>
> ~~~
> As a bit of tidying up, we have also voted for Jeroen van der Wal, and
> Maurizio Taverna, to be members of the Isis PMC. In fact, in many/most
> Apache projects, all committers are also PMC members, so it was something
> of an anomaly that we originally voted Jeroen and Maurizio as just
> committers.
>
> Cheers
> Dan Haywood
> Apache Isis PMC Chair
Re: [ANNOUNCE] New committer - Oscar Bou
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
First of all, excuse for this quite long email, but I'm really grateful for being accepted as a committer to Apache Isis, and I would like to express the reasons behind this commitment in the hope it helps other list subscribers to move to Apache Isis, and also to contrast my thoughts.
Our first driver towards moving to Apache Isis was not its automatic UI generation through its viewer technology (which could be seen as its main advantage by some developers). We already had a working app and our own User Interface.
It was due to the support of a shared vision about the capability to translate the business rules implemented in the domain to all related technologies working with it, including (but not only) the User Interface. It should help a lot in the support of the Hexagonal architecture pattern ([1], [2]). The Apache Isis meta-model has allowed to directly support distinct viewers implemented with different technologies, including the support of a full specification of a REST interface to the core domain [3] (which can ease a lot of internal teams to implement further Hexagonal architecture adapters, such as custom interfaces in different technologies for external teams, in a fully automated and supported manner).
I envision Apache Isis as the least risky approach to DDD in common business domains due to the following strengths:
1. It allows to "start focused" on the highest risk, the domain:
- With Apache Isis you just have to concentrate on the domain and a custom User Interface and REST API are automatically generated and updated, allowing really fast inputs about the current domain implementation. Work on less-risky areas (such as the UI) can be easily postponed.
2. It allows to "start easy" when the expectations about the domain complexity are not high, or, at least, not as clear to decide to invest on a "full DDD approach":
- Implementing a "basic domain" can be nearly as easy as on Microsoft Access by using the current Archetype, the Eclipse templates and the available Viewers (as the Apache Wicket viewer for automating the webapp implementation).
- As new business rules are discovered, they can be incorporated to the Apache Isis domain, and are automatically propagated to (used by) the viewers.
- Unlike scaffolding technologies, the user interface and other architectural adapters behave "dynamically" and adapt "intelligently" to the current domain implementation by means of the Apache Isis meta-model, which eases a lot the domain improvements, application maintenance and technology upgrades.
3. It eases to start, explore and evolve the domain with full domain testability, through the new support for Behavior-Driven Development:
- The business expert and the developer can work together on defining features and business scenarios that can be implemented and tested with Apache Isis.
- And as the user interface, the BDD behavior, the fixtures, etc. are supported by Isis, it allows really rapid iteration cycles focusing on the domain, so the project risk is rapidly detected and minimized by the experts and developers.
As in all software projects, there is space for improvement, and it could be among others in the following areas:
* Improved "domain business rules support". It must be the core strength of Apache Isis (where the viewer and other related technologies are a "derivative work"). And it could include:
- domain objects that behave by default conforming to all business rules defined (i.e., "wrapped by default", a controversial point, I'm sure),
- direct JSR-349 supporting facets, etc.
* Support for migrating existing projects to Apache Isis. There is a high and fast growth vector for the community by being adopted by currently existing applications. But for that, official APIs should be provided for:
- "Custom viewers support": easing the interaction with custom-made pre-existing User Interfaces (through the REST API, but also through Java APIs). It should include fully-supported API classes or interfaces for Apache Isis session handling, transaction management, etc.
- JPA support: most Java applications use at the persistent layer the JPA API or the custom Hibernate API. The initial support for JPA could be based on DataNucleus, allowing to migrate all persistent domain classes and logic inside them. Directly supporting other persistence ORM platforms is a bigger effort that could be postponed in my opinion.
* More project examples available.
- We traditionally had the ToDo example on the archetype, the "claims" example of the Naked Objects book, the excellent "Transport Planner" application, and few more examples (perhaps a web page is needed for referencing together all available examples?).
- The "Estatio" project has been a milestone for Apache Isis, and we are constantly exploring it. There are quite "hidden gems" inside it about Apache Isis implementation, but also about "generic" domain implementation (as the Interfaces "decorating" the entities, the domain layer superclasses, the BDD cases, etc.). So many thanks for publishing it (and convincing the customer's management team :-).
- We are currently working "against the clock" in our project, but it would be really interesting if anybody in the community could lead the implementation of a well-known DDD example, where we could contribute. It would be great if the "Implementing DDD" example project could be implemented using latest Apache Isis capabilities (with the consent of the author, Vaughn Vernon). It could help to validate current DDD support in Apache Isis, and to discover areas of improvement (such as classes for directly supporting the implementation of tactical patterns, but also for projects partitioned on different Bounded Contexts). Vaughn Vernon has made the effort of participating on the consensus and putting together some of the most agreed DDD implementation best-practices. Some of them can be implemented as-is on Apache Isis, some others must be adapted, and some others can be discarded or replaced by other implementation strategies that benefit from current Apache Isis capabilities and/or supporting technologies. I'm sure its an exercise that can help to improve the Apache Isis framework, and the use and acknowledgement of Apache Isis by the DDD community.
Well, excuse me again for this long email and hope this helps to those evaluating Apache Isis.
Yours sincerely,
Oscar Bou
[1] http://isis.apache.org/learning-more/hexagonal-architecture.html
[2] http://alistair.cockburn.us/Hexagonal+architecture
[3] http://isis.apache.org/components/viewers/restfulobjects/about.html
El 12/08/2013, a las 12:02, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> I'm delighted to announce that Oscar Bou has been voted in as a committer
> on Isis, and also to as a member of the Isis PMC. The first gives Oscar
> the right to commit changes directly to Isis' codebase, the second gives
> him the right to be involved in future votes.
>
> If you've been following the users and dev lists over the last few months,
> you can't fail to have seen Oscar's energetic involvement. Oscar came
> across Isis while building a similar framework in-house, and has since
> worked with his team to port much of their application - still in
> development - over to Isis. In so doing, Oscar has provided invaluable
> early testing and feedback for new features being implemented.
>
> Oscar has ticked the boxes in terms of being a committer: using the mailing
> lists appropriately, raising JIRA tickets, provided patches to address
> specific issues, providing help to others in the community. But he's gone
> beyond that in raising a number of insightful - sometimes challenging -
> questions regarding Isis' design/responsibilities as a framework, and shown
> that he's keen to address these issues and thus improve Isis as a product.
>
> I'm looking forward to working with Oscar in the future; another great
> addition to Isis' committers.
>
> ~~~
> As a bit of tidying up, we have also voted for Jeroen van der Wal, and
> Maurizio Taverna, to be members of the Isis PMC. In fact, in many/most
> Apache projects, all committers are also PMC members, so it was something
> of an anomaly that we originally voted Jeroen and Maurizio as just
> committers.
>
> Cheers
> Dan Haywood
> Apache Isis PMC Chair