I should add to this because someone will point out the seemingly obvious: Why not call the generated restful objects API?
The RO API that is generated reflects the domain behaviour. Generally when providing a service to a service consumer(s) you are doing a lot of aggregation of fine-grained domain behaviour to coarse-grained service behaviour on a "large" non-OO information model. And so you would naturally gravitate to the same method as described in my post below and end up with "UI" "objects" that do the coarse-grained aggregation of behaviour and data but also implement ISIS services so that "their" (coarse-grained) RO API get's presented for the service consumer(s). btw, in our use cases, with processing the files and staging tables, using the RO API was pointless because the service "consumers" are in the same application and java to java is far more efficient and you get atomic transaction behaviour as part of the bargain. David. ________________________________ From: David Tildesley <[email protected]> To: "[email protected]" <[email protected]> Sent: Sunday, 30 June 2013 8:32 AM Subject: Re: Microsoft CRM as a reference architecture (part 2) Hi Oscar, Dan, We've successfully used Quartz and Apache Camel in an application using ISIS. I had a conversation on this list with Dan a few months back about calling the ISIS domain from what is effectively a "non-human oriented" UI layer. We separated out the "UI layer objects" from the domain layer objects via packaging. I would like to see a more enforced separation - I'm not sure how to go about it though. The aim is to maintain separation of concerns and thereby protect the rich domain as per this app layer pattern: UI --> Rich Domain <--SI As Richard Pawson said in his replies to comments in that same blog: "Use-case driven analysis leads to poor object modelling in my experience. My position on this is that use-cases should be used to validate the object model, not to identify it." With a system oriented UI (could be invoked in any number of ways: soap web service, JMS message, ...) as with a human UI, the trick is not to allow bleeding of domain business logic in to the UI and ensure that the domain never depends on the UI. This way, you can bolt on any number of UI's to the same domain layer. While what we have done (using packaging) works, maybe there could be a better (ISIS) way of enforcing separation of concerns? Also it would be very nice to be able to independently package up the domain layer, SI in separate jar for reuse in different application contexts. (by doing this you are removing all doubt about where the layer concerns are) btw, in our UI we are processing files (using Camel) triggered by a schedule event (quartz) and also (another use case) processing staging tables, calling domain business objects behaviour as required. David. ________________________________ Oscar wrote: >Really nice the wayback machine. I remember read about it quite time ago, but >never used it... and works like a charm! >I didn't pretended to open a debate about the role of Workflows on DDD or >NakedObjects. >It was just an example of an infrastructure service provided by MS CRM that >could be also a higher-level "Infrastructure Service" available on Isis. >My intention was to open a debate about the possibility that "higher-level" >building blocks were also part of Isis, >such as a collection of "infrastructure level services" (like Dan's Email >Service, the Event Service recently > commited by Dan, the publish-subscribe service, a Geographic Mapping Service > - available on different , >the Workflow service, a generic interface to a SMS Service with >implementations based on different providers - >such as Twilio, or Apache Camel - useful in multiple uses cases -, etc.). ...
