On Fri, 26 Oct 2018 at 19:16, Rade, Joerg / Kuehne + Nagel / HAM GI-DP < joerg.r...@kuehne-nagel.com> wrote:
> > Among the raised topics were: > > Q1: > Hexagonal architecture is supposed to further separations of concerns. > Arn't annotations in the code (dealing with presentation and persistence) > a violation of this principle? > > A1: > Cardinality, layout, etc. need to be specified somewhere. > In java files is convenient. Fewer places to edit. > (I'll use a different slide the next time ;-) > > It's a question of where does the metadata to binding the various layers reside? With JPA/JDO, it's also possible to use XML metadata, so that eradicates those. With the Isis presentation annotations, the facet model is pluggable, so these could also be rewritten in XML if you wanted (though no-one ever does in practice). "Separation of concerns" is really about ensuring that stuff lives together that changes at the same time. If the UI layer has to be updated whenever the underlying domain layer changes, then really there's not much separation. Of course, the UI layer might also be redeveloped without changing the underlying domain model, but that's the role of the framework itself, not the application code (eg when we reworked to use Bootstrap in 1.8.0, that didn't impact anyone's code). There are two more important separation of concerns. One is application vs domain layer. I realised embarrassingly recently that actually the end-users's view of the applicatoin is the application layer, not the domain layer. Of course, in many cases there is no need to explicitly separate these layers - the behaviour required of an end user can be implemented on the domain layer (entities) directly. But where a translation is required, typically for things such as bulk operatoins (eg an invoice run) then the framework supports view models that can delegate down to underlying domain layer. The second separation of concerns is across modules. Here the framework's support for mixins and intra-process domain events allow decoupling of these interactions, but within the context of a single system transaction so there is no need for all those tedious compensating actions that one otherwise has to wrestle with. > Q2 (rather a suggestion): > Regarding configuration files (shiro.ini): Is it possible to use something > like XML that allows for autocompletion while editing in an IDE? > > A2: > Good idea, would ease tasks for people not familiar with the syntax. > OTOH: syntax is not too complicated and editing is not done often. > > Yeah, that's a tiny detail. > Q3: > Are html IDs in generated ui code fix? Can tools for UI test automation > assume the ID's are fix? > > A3: > Don't know. Such UI tests should be part of the FW. Better focus on > testing Domain Objects. > > They are. As you say, UI tests aren't needed though, better is integration tests. That said, I have thought that the framework could also code generate page objects to allow folks to write selenium tests if they so wished. > Q4: > How to implement a custom UI? > > A4: > Custom Wicket Widgets are possible.I suggested to use the RESTful > Interface. > > Yup. Also, eventually these two will converge. Seb Slutzky is steadily working on a Restful Angular app [1] that is generic but will eventually, I hope, provide a more graceful path to being customised, leveraging such things as polymer/web components. [1] https://github.com/sebastianslutzky/AngularViewerCLI Q5: > Isn't the name unfortunate? > > A5: > Yep. It's getting better by the time. > > sigh. > -j > -----Ursprüngliche Nachricht----- > Von: Andi Huber [mailto:ahu...@apache.org] > Gesendet: Mittwoch, 24. Oktober 2018 20:23 > An: users@isis.apache.org > Betreff: Re: AW: Diagrams on the Metamodel? > > Jörg, just to let you know, I enjoyed flipping through your slides. Thanks > for the link! > > Andi > > On 2018/10/19 17:07:50, "Rade, Joerg / Kuehne + Nagel / HAM GI-DP" > <joerg.r...@kuehne-nagel.com> wrote: > > Hi Dan, > > > > thanks - I've created a simplyfied version and included it in the slides > (pptx). > > They are available at https://github.com/joerg-rade/dddsample-isis. > > > > If you want to reuse some of the diagrams (in adocs as well), feel free. > > > > Best regards > > Jörg > > > [...] > > Kühne + Nagel (AG & Co.) KG > Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE > 812773878. > Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ), > Tom Ban, Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas > Minde, Lars Wedel, Matthias Weiner. > Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: > Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, > Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt. > Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi (Vors.), > Tom Ban, Dominic Edmonds, Thierry Held, Uwe Hött, Richard Huhn, Holger > Ketz, Jan-Hendrik Köstergarten, Jan Kunze. > > Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen > Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in > Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431 > HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten > unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf 2 > SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf 1,25 > Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je Schadenereignis, > mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite > als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu. >
