[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15157167#comment-15157167 ] Jeroen van der Wal commented on ISIS-1303: -- When I pitch Apache Isis I always use phrases like "single layer application development", "layerless application development" or simply "no layers". > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, > ApacheGestalt.jpg, Offset-curves-of-sinus-curve.svg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down barriers between IT and business > Of these, I think that hexagonal architecture looks the best fit; it is well > regarded as a concept among the "cognoscenti", but there are surprisingly no > open source frameworks out there (at least in the Java space) that position > themselves as being the natural choice. > Therefore, I think a name - and appropriate short tag line - based around > this idea of hexagonal architecture should be considered. >
[jira] [Commented] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15157133#comment-15157133 ] Cesar Lugo commented on ISIS-1303: -- I believe Richard Pawson just provided an amazing contribution and a very clear example of a mental exercise, in my opinion. Yes, trying to sell benefits is not only hard to differentiate, but impossible when you don´t know each individual prospect, because benefits needs to be quantified. That´s why many marketing experts lead you towards valuable attributes or valuable properties that are memorable, quite straightforward and unique, quite similar to what Richard states. Whit that in mind, could´t EXAGON or AMP be enhanced with an appropriate tag line and comply with that? Could anyone else out there claim they can augments or amplify your domain in 6 very specific and very valuable dimensions? Just a thought. Cesar. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, > ApacheGestalt.jpg, Offset-curves-of-sinus-curve.svg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI
