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 <d...@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

Reply via email to