On 16 June 2014 12:14, David Tildesley <[email protected]> wrote: > > I agree that the domain layer must protect itself and not depend on any UI > layer to do that protection. However is it necessary to go to that extent > within the domain layer itself? > > I see this in terms of trust boundaries. In a highly modularized domain (using "module" in the DDD sense) it could be that - even though those modules are deployed together - each entity would want to ensure that it's preconditions/invariants are maintained.
Where Isis leaks a bit is that the wrapped objects the domain model have three different ways to indicate that a precondition/invariant has been violated: by throwing a hidden exception or a disabled exception or an invalid exception. But I see those merely as "hints"; fundamentally these are all subclasses of a common subclass (InteractionException). What Oscar and his team report is that having no trust boundaries - ie always wrapping - has yielded benefits. This might be in part to do with team structure and process, or it might be to do with the particulars of their domain. If it has worked for them, then fair enough I say. But what we probably do need to do is to provide better guidance as to the pros and cons of the feature; and threads like this help figure out what that should be :-) > However, on the same theme - there is currently a reliance on the > generated viewer to implement domain object annotated business logic > "guards" for setters in particular. Anything from the UI layer that is not > part of the generated viewer that calls the domain layer directly (e.g a > view object), effectively bypass these guards and I think this is not > right. Your suggestion would solve that problem. > > This might be a reasonable half-way house for many: that view model objects (in the "application" layer) should always wrap calls to the domain model (in the domain layer). But again this is just a reflection of trust boundaries - an application layer is even less likely to be trusted by the domain layer than some other domain object. > So maybe there is a way of introducing this automated wrapper without at > the same time turning ISIS into EJB 1.x/2.x? If that is possible then you > have my vote. > > This may be moot, because technically, I'm not sure it is possible to do automatically. The issue is that JDO/DN does not provide a suitable callback for lazily-loaded objects to get wrapped. (But I've sent an email to Andy Jefferson to see if I'm wrong about any of that). > I think the main threat to the (fully contained business logic) rich > domain layer is actually the misuse of the view object - particularly when > combined with the issue that the framework makes it necessary to use the > view object in lieu of a non-dm-persisted domain object. Don't get me > wrong - I see the view object as essential for (in particular) a web > viewer in order to build an user friendly UI. > > I agree with you... misuse of view models can lead to anaemic domain models. Thx Dan > Kind Regards, > David. > > > > > > On Saturday, 14 June 2014 9:56 PM, GESCONSULTOR - Óscar Bou < > [email protected]> wrote: > > > Just one more thing for the roadmap. > > We also mentioned on IsisCon (but also I can remember Dan mentioned > something similar on the mailing list as his intention for version 2) that > domain objects (domain entity instances) could be "wrapped by default", > acting as a "container" of the business logic and ensuring it was preserved > by default when invoked from other domain objects. > > That would imply that, for example, a call to: > > domainObject.someAction(x, y, z); > > Would always validate the parameters, choices, etc. and all other > associated business logic. > > And that a call to: > > domainObject.setXXX(x); > > would always preserve the business rules implemented on the modifyXXX, > validateXXX, clearXXX methods, for example. > > > It has many advantages, for example for testing. It really avoids > "programming errors" originated by invoking in the domain actions or > setters without taking into account validations or business logic inside > the modifyXXX methods, for example. > > In our case, nearly all our actions are setter invocations are made > through: > > this.wrap(domainObject).setXXX, this.wrap(domainObject).actionXXX > > or, if they're hidden or disabled, > > this.wrapSkipRules(domainObject).setXXX, > this.wrapSkipRules(domainObject).actionXXX > > > That strategy of "always wrapping" helps REALLY A LOT while debugging. > > > Sincerelly, this was one of our expectations when we arrived to Isis. And > we don't know of any other platform that always tries to preserve all > business logic. > > > Thay would imply that Isis would act as a "true" hexagonal architecture > when the UI just is another port-adapter, with exactly the same behavior as > any other invokation from any other port-adapter, and what it's most > exclusive of any platform, doing the same with intra-domain invocations. > > Any thoughts? > > > Thanks, > > Oscar > > > > > > > > El 10/06/2014, a las 21:28, Kevin Meyer - KMZ <[email protected]> escribió: > > Quick immediate reply: > > ~~~~~ > Some of the ideas that follow build upon each other, some are independent > of each other. I won't attempt to outline an exact timetable, but you can > see that some of this work could be performed in parallel. For example, > improved Shiro support (4) could be done at the same time as simplifying > the framework (1). > > 1. Simplifying the framework > > * Isis will run only as a server-side webapp. This implies that the DnD > viewer will be retired. This will also enable Isis' bootstrapping to be > simplified and rationalized. > > > By the way: A DnD viewer can be later re-implemented, if so desired. > > * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus > ObjectStore implementation then made part of core. The other ObjectStore > implementations will be retired. This step in particular should enable > considerable simplification > > > As described, this is a temporary state, with a future plan to later > abstract out a new Objectstore API to support other objectstore > frameworks. See below. > > * Isis will adopt the Shiro authentication classes rather than define its > own. This will also allow authentication to be moved into the core. > > > I have no comment :) > > 3. Alternative Persistence providers > > Having in (1) made Isis dependent on an ORM (for lazy loading and dirty > object tracking) and on DataNucleus in particular, the next step in the > roadmap is to re-introduce pluggability so that developers can use other > ORM implementations; particularly for the JPA API. Being an Apache product > means that we cannot dependent on certain licenses, but we certainly > provide alternative implemenation based on either Apache OpenJPA, or on > EclipseLink (the old TopLink product). > > We might also look to provide an implementation for the market leader, > namely Hibernate. However, because Hibernate is LGPL, this implementation > would need to live outside of Apache Isis' formal codebase, eg in the > apache-extras.org site or perhaps just likely on github. > > > 4. Improved support for Shiro > > We've noticed a number of users wanting to use our Shiro integration, with > Shiro configured to use a JDBC Realm. It ought to be relatively simple to > build Isis entities that map onto the Shiro concepts (users, roles, > permissions). In this way Isis could provide a self-contained security > subsystem for managing users "out-of-the-box". > > We anticipate delivering this as an optional module that could be included > as necessary. > > An extension of this is to deliver a standalone application built with Isis > for administrating the users/roles/permissions for any application > configured to use the Shiro JDBC realm (not just an Isis application). > > > The discussions I've had and heard regarding other application > development suites lead me to believe that this would be an extremely > useful add-on! I'd almost like to request that this be the first thing > worked on, before any of the fundamental changes listed above. > > But that's just my wish. > > (I'd like to demo that Isis can also support RBAC, out-of-the-box). > > > > 5. Other Reusable modules > > In the applib there are a number of services; some depend on parts of the > Isis runtime; some do not. Some have their own entities, some do not: > > - CommandContext (applib implementation) > - BackgroundService (core-runtime implementation) > - BackgroundCommandService (JDO implementation, with entities) > - AuditingService3 (JDO implementation, with entities) > > - PublishingService (JDO implementation, with entities) > > - ApplicationSettingsServiceRW (JDO implementation, with entities) > - UserSettingsServiceRW (JDO implementation, with entities) > > - ClockService (applib implementation) > - QueryResultsCache (applib implementation) > - Scratchpad (applib implementation) > > - MementoService (core-runtime implementation) > - BookmarkService (core-metamodel implementation) > - XmlSnapshotService (core-runtime) > - EventBus (core-runtime implementation) > - ClassDiscoveryService (applib implementation, > +optional org.reflections dependency) > - WrapperFactory (core-wrapper) > - DeveloperUtilitiesService (core-metamodel implementation) > > Extended the idea of the Shiro security module (4, above), we think it > makes sense to modularize these other services; probably in five or so > modules in line with the grouping shown above. That way developers could > bring in a dependency to the services that they require, and ignore the > others. > > > 6. Profile Store > > The profile store is a component of the framework that is not supported by > either the Wicket or Restful Objects viewers, but whose functionality is > broadly superceded by the UserSettingsService. > > > When the UI becomes user-configurable (re-arranged, pallete change, > etc) this should be demo'd. > > Where are user preferences (e.g. UI language, timezone, etc) currently > stored? Do we have demo code? > > In line with simplification (1) we'll retire this component. > > > 7. Restful APIs > > The Restful Objects viewer implements the Restful Objects spec [2] and > provides a full REST Hypermedia API to the Isis metamodel and runtime. > > > 8. Wicket Viewer > > We intend to continue developing the Wicket viewer. One part of its > development will be to re-implement its components to use Wicket-Bootstrap > [5]; this will make it easier for its look-n-feel to be customised. > > We will also probably rename it. "Wicket" is merely the implementation > technology; its name should represent what it's role is. Possible names > are the "default viewer", or the "standard viewer" (preferences? > alternatives?) > > > Thinking about it further, I would probably prefer to keep "Wicket" in the > name somewhere, as the viewer *is* dependent on Wicket, and those > who wish to extend (I want to add some additional view components), > need to know Wicket. But I guess that other names may also be more > appropriate.. > > > > 11. Better documentation, better website. > > Probably every open source project would wish for better documentation and > examples; we are no different, and we intend to keep improving the docs and > providing examples of usage. > > On the homepage one idea is to make Isis' value proposition more obvious. > We intend to distinguish our audience, though; what a business person > wants to know about is different from what a techie wants. So we will > provide different material for each to consume. > > For a bit of interest/originality, Maurizio has offered to develop some > goanimate [6] cartoon videos; he has used these with some success in his > own software development company. Right now I am working on some scripts > to be developed; one 2-minute business-focused one, and a number (3 or 4) > of 2-minute technicaly focussed ones. > > Also, I am aware that much of the materials were written by me and all of > the screencasts have my voice on them. But there should be other voices > present on the website; Isis isn't a one-man show and visitors to the > website shouldn't get that impression. > > > I agree and will try and step in more, here. > > 13. Conferences, articles, podcasts > > Jeroen and I are intending to submitting a couple of sessions to ApacheCon > EU in Hungary [7], and in general try to do a few more sessions. > > I have also promised an 500-word blog post for Zeroturnaround to advertise > our JRebel integration. > > And, it'd also be good to do some podcasts sessions; I am sure they are > several looking for new people to talk with. > > > I'll be in touch later for ideas for ApacheCon EU and other opportunities. > > Don't forget about opportunities to show off Isis in "rapid app" dev > competitions. Jeroen, you mentioned one in the Netherlands?? > Perhaps Isis can become the disruptive change from a surprising > direction! > > > ~~~ > OK, I think that's it. > > As I say, for those who were in Milan, please amplify/expand/correct. For > everyone else, your comments/thoughts are welcome. > > Cheers > Dan > Apache Isis PMC Chair > > > > :) > > Unless otherwise indicated, I agree with the proposals.. ;) > > Regards, > Kevin > > > > > Ó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. > > > > > > > >
