[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=16952634#comment-16952634 ] Alexander Dolgunin commented on ISIS-1303: -- Apache Rubedo (the final stage of the Great Work) [https://en.wikipedia.org/wiki/Rubedo] sounds better than *Rubato* to me > 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: Daniel Keir Haywood >Priority: Major > Fix For: 2.4.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. > Candidate names: > - hex
[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=16866305#comment-16866305
]
Jörg Rade commented on ISIS-1303:
-
Apache Lever - Give me the place to stand, and I shall move the
{color:#33}[earth|https://en.wikiquote.org/wiki/Earth]
{color}([https://en.wikiquote.org/wiki/Archimedes])
> 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
>Priority: Major
> Fix For: 2.4.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=16075212#comment-16075212 ] Kevin Meyer commented on ISIS-1303: --- Just to throw in another viewpoint. I think we should consider a proper noun name that does not mean anything particular. - No possibility of misunderstanding or misrepresenting something from another language (that is not any of our mother tongues) - Avoids "techie" names that just always seem to be cheesy to someone - Lets the catch phrase be anything, without somehow being forced to fit a "relevant" name - Can be chosen to avoid any IP conflicts Suggestions: Apache Andrew, Apache Bradley, Apache Charlie, Apache Delta, Apache Eve, ... (you get the idea). > 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 > Fix For: 1.20.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
[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=16057069#comment-16057069 ] Jörg Rade commented on ISIS-1303: - +1 Apache Alma > 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 > Fix For: 1.20.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. > Candidate names: > - hex (might hit trademark issues) > - hexagon > - hexagn (deliberately mis-spelled) > - hxg (omitting vowels, but could stand for hexagonal, extensible, generic) > - hx
[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=16046532#comment-16046532 ] Jan-Willem Gmelig Meyling commented on ISIS-1303: - +1 for Kikoro and Rubato. I think I prefer Rubato of the two (but defintely don't intend to make things even more complicated ;) ) > 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 > Fix For: 1.20.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. > Candidate names: > - hex (might hit
[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=16045866#comment-16045866 ] Dan Haywood commented on ISIS-1303: --- At IsisCon 2017, held in Amsterdam in June, we had some great discussions about who to pitch the framework to (as well as possible inhibitors). We agreed, I think, that the pitch is to IT Managers/CTOs, who understand the needs of the business, and either know enough about technology to make the call or (probably more likely) would rely on a trusted "technical" leiutenant to help make the call about whether to explore our framework. But we don't pitch to the techies directly. (There is a separate discussion about what to do to ensure that those technical leiutenants don't "veto" our framework for unimportant reasons... won't address here). Anyway, with respect to a pitch to a business aware IT Manager/CTO, we only want to talk to those who *"want to allow the business change"*, who see that *requires a feedback loop* (because one can't know a priori that every change is a good change), would understand our philosophy that *IT is not a cost centre but is a profit centre*, that IT systems should be sized as the *minimum needed to run your business* (software is expensive to own, so have as little as possible of it). If those ideas fall flat, then better to fail fast on that prospect and find someone else to talk to. But for those for whom the above ideas do resonate, then we have a target audience and can start the conversation. In general there seemed to be an appetite to change the name of the framework; apart from its (current) negative connotations, the name "Isis" doesn't actually mean very much, so not having an apposite name (and corresponding strapline) is a missed opportunity in terms of introducing the framework On that note, here were some additional names that came out: * _Apache Shortcut_ : rapid development. Possible negative connotations though? (hacky, bodge) * _Apache Loop_ : as in feedback loops. * _Apache Alma_ : "Alma" is Spanish for soul, it's also the rod in the middle of a string instrument that connects the bridge to the body, so that the instrument resonates. Nice and alliterative. *"The soul of your business"* * _Apache Kokoro_: picking up on the soul idea, "Kokoro" is Japanese that combines the (in the Western culture) concepts of soul and heart and mind. So again, the "soul of your business". * _Apache Soul_: same idea, also Soul Jazz. * _Apache Affknaai_ - tongue in cheek suggestion, given our history of "unfortunate names" ... a framework formerly known as apache isis The top candidates, with possible straplines, we ended up with are: * *Apache Kikoro*: _"the soul of your business"_ * *Apache Alma*: _"the soul of your business"_ * *Apache Rubato*: _"play your own tune"_ * *Apache Rubato*: _"play freely"_ * *Apache Tailor*: _"fit for business"_ FWIW I've listed these in my own preference order > 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 > Fix For: 1.20.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
[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=15314047#comment-15314047 ] Dan Haywood commented on ISIS-1303: --- Just to say, haven't forgotten about this ticket/initiative. If anyone wants to do the trademark searches for their favorite, and update the wiki page (https://cwiki.apache.org/confluence/display/ISIS/Name+ideas), that would be peachy. Meantime, I have one further suggestion, namely "Apache Tailor". Why? because we're about building bespoke/custom systems that fit the business (compare to an off-the-peg system where the business has to bend/be constrained by that package software). This is directly tackling the "build vs buy" argument, which is one of the most fundamental questions that needs to be answered. And "tailoring" is a metaphor that non-technical people can readily understand. > 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.15.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). >
[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
[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=15155664#comment-15155664 ] Richard Pawson commented on ISIS-1303: -- I'm not going to express any further preference about the name, but I would like to make a comment about the tag-lines: all the ones I've seen suggested here read, to me, like generic marketing 'burble'. They convey nothing about what Isis (currently) is. Might I propose this thought experiment: Imagine that you were doing a presentation of Isis, where you couldn't mention the name or the tag line, and where you were presenting alongside 10 other frameworks. (They don't have to be direct 'competitors' as such, just other significant software development frameworks that might be used by potential customers in some overlapping way). At the end of the 10 presentations, the audience is handed a slip of paper with the name of your product AND the tag-line. Would they be able to identify which of the 10 frameworks that applied to? In an ideal world, your name and/or tag line would convey the nature of the product without having seen it, but that is not always possible. If it's not possible then the next best thing is that once they have understood the product, they will remember the name and/or tag line, because the latter will clearly remind them of the product. I don't think any of the name / tag-line combinations proposed pass either test. As I said to Dan offline last week: I fully understand why you want to downplay or move away from both the naked objects pattern, and DDD, but I think you need to replace them with something equally concrete that defines your space. That definition is as much about what you would NOT do in future as what you would do. i.e. if one of the team said 'let's add feature x' - would you have a clear way to decide whether X was enhancing the strategic direction of diluting/confusing it (even though X might not be a bad idea in itself)? I know there are many people who tell you to 'sell benefits, not features', but the problem with that advice is precisely that you don't end up with anything differentiating. You cannot, I believe, find a succinct set of business benefits that are in any way unique: the same benefits will be claimed (with some legitimacy even) by multiple other products. So you have, to some extent, to sell features: but preferably ones that at least some people will see a benefit from. > 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. >
[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=15154486#comment-15154486 ] Oscar Bou commented on ISIS-1303: - Nice candidates. Following the "Apache Amp" contender, why not h4. Apache Dom being working at the Domain level the framework's core strength ? Slight variations could be: h4. Apache Dominion A bit "stronger" ? h4. Apache DomEx h5. For Domain Experts h4.Apache HexaDom Putting together both references to Hexagonal Architecture and Domain orientation. > 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)
[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=15154218#comment-15154218 ] Jörg Rade commented on ISIS-1303: - The Rodin Thinker is already used by http://sculptorgenerator.org/ Torsten Juergeleit (from sculptor) contributed https://libraries.io/github/vaulttec/isis-script My current favorites are: Amp, Ippon, Hajime, and Root. An Amp logo could look like [Offset-curves-of-sinus-curve.svg] in Isis or Apache colors. Using an alliteration name gives a push in sorting as well. > 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
[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=15154202#comment-15154202 ] Dan Haywood commented on ISIS-1303: --- Nice that the "Adept" idea is resonating. I agree it's a strong contender. Some good tag lines suggestions there. I also came up with: h1. Apache Adept h2. Amplify your skills or h1. Apache Adept h2. Make the most of your skills. or h1. Apache Adept h2. Business problems, human solutions Meanwhile, back on the "for problem solvers, not process followers" meme (which I also think is very strong), was thinking of "Apache Rodin" as a name (after Rodin's Thinker, obviously). h1. Apache Rodin h2. For problem solvers, not process followers > 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 > > > 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
[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=15152182#comment-15152182 ] Ged commented on ISIS-1303: --- Adept: "an individual identified as having attained a specific level of knowledge, skill, or aptitude." I like that. > 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 > > > 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. > Candidate names: > - hex (might hit trademark issues) > - hexagon > - hexagn (deliberately
[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=15152179#comment-15152179 ] Ged commented on ISIS-1303: --- * For Humans Solving Business Problems: Speedier, Faster and Further. --- my suggestion, paraphasing Engelbart. > 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 > > > 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. > Candidate names: > - hex (might hit trademark issues) > - hexagon > - hexagn (deliberately
[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=15151923#comment-15151923 ] Steve Cameron commented on ISIS-1303: - I think you have nailed it Dan. Should that be 'human aware' solutions? Apache Adept is a good name I think, it seems to encapsulate these concepts. > 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 > > > 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. > Candidate names: > - hex (might hit trademark
[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=15151894#comment-15151894 ] Dan Haywood commented on ISIS-1303: --- In terms of tag lines (which are our best opportunity to distinguish the framework from everything else out there): * business problems, maintainable solutions ... which I like because we're actually calling out what many might see as rather a dull topic - maintainability - as the core characteristic of the framework * business problems, humane solutions ... back to Ged's augmentation stuff * for problem solvers, not process followers ... which we've used as informally for years (Richard coined it); I like it because it refers to both the users of apps built with the framework, and also developers using the framework. It also has a pop at all those tools that provide a bunch of pretty wizards but don't ask the developer to do any thinking. > 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 > > > 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
[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=15149145#comment-15149145 ] Dan Haywood commented on ISIS-1303: --- Been mlling over some further name ideas, riffing on the idea of our being a framework for connoisseurs, not hipsters. So one idea is simply "Apache Connoisseur"... but it's difficult to spell and somewhat pretentious. Looking for synonyms, I found "adept", which I like quite a lot : "Apache Adept". That days something about both the framework and the short of developers for whom it is intended. It even alludes to the business users, our "problem solvers, not process followers" Changing tack slightly, was also thinking about the gearing metaphor, which led me to amplification... this "Apache Amp". I do quite like the way that sounds, too. Have added them all to the wiki page. > 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 > > > 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
[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=15139915#comment-15139915 ] Steve Cameron commented on ISIS-1303: - Inspired by the Jedu name idea I also suggest 'Jaco' after Jaco Pastorius. The name is short and punchy and starts with a J. As a by-line "An Inspired Base", an in-joke kind of. But I do see parrallels between the two, mainly a persistence in refinement of an approach, and the base/bass on which to build. > 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 > > > 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 -
[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=15136291#comment-15136291 ] Dan Haywood commented on ISIS-1303: --- I've updated the wiki page with these two further suggestions from David. [~kevin-m] you asked what would happen to all the existing Isis references? I would imagine that JIRA and our mailing list aliases can be updated easily enough; project renames happen reasonably often, and are under ASF control. My guess is that ASF could also set up a redirect from isis.apache.org to whateverwedecide.apache.org. Less certain about markmail, because it sits outside of ASF. Worst case, we continue to link to the current lists as achive. The biggest "cost" as I see it will be in updating the code and in the documentation, but the vast majority of that is on our website and under our control. > 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 > > > 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
[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=15136043#comment-15136043
]
David Tildesley commented on ISIS-1303:
---
Picking up on Dan's list of prompts, I thing DDAQ (Domain Driven Applications
Quickly) is a good candidate. It rolls off the tongue nicely ("Deedack"). A
quick google on DDAQ didn't reveal anything of concern.
In fact it looks very "available".
David.
> 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
>
>
> 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
>
[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=15135983#comment-15135983 ] Kevin Meyer commented on ISIS-1303: --- For some reason I can't quite pin down, I too like JEDU - kinda playful: Just Enough Java Development & U (you). Doesn't mean anything special (which is fine). (Just enough gets the job done? Anyone?) I also like Reflect and Reach... While I don't have a problem Hexagon, as such, I must say don't like the idea of changing the spelling (XAgon, etc), but only for the reason of verbal communication. When I tell someone about "Apache Isis", they know immediately what to search for (and how to spell it). XaGon? Exagon? xgone? One question I do have, though, is what happens to all the existing ISIS references? e.g. Do we keep the JIRA /ISIS key? Does this get renamed too? And the markmail mailing lists? What is the "cost" of a rename? Will the old links stay alive and be forwarded to the new location? (I'm thinking of Stack Overflow and other references on web) > 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 > > > 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 >
[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=15134478#comment-15134478 ] Cesar Lugo commented on ISIS-1303: -- If voting helps, my personal votes: Apache Ippon "Win. Now." Reason: Elegant, straight to the main point, sounds cool. Slogan / tagline derived from meaning avoids the need for explanations. Calls to action. Apache Reflect / Reflex "From Prototype to Business" or "Domain. Prototype. Business" Reason: Dan explained reflection over the business domain. Combined a little two of the slogans / taglines. Apache XA6on "Don´t be square" Reason: Emphasis on augmentation through the multiplier effect of the hexagonal architecture (Your App X 6 ). Slogan calls to think twice the way you do things now (vs other leading frameworks). 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 > > > 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
[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=15133825#comment-15133825 ] Dan Haywood commented on ISIS-1303: --- Further name ideas: on the concept of bridging IT and business - Apache Bridge ... simply said - Apache Brunel - victorian engineer responsible for many bridges (as well as railways, ships etc) - Apache Telford - another engineer, from the 18th century, designer of aforementioned Menai Bridge, mostly known for roads - Apache Reach - another term for bridge - Apache Span - ditto on concept of the DDD "ubiquitous language" term: - Apache Ubiq - an abbreviation on the gardening metaphor (the "Pragmatic Programmer" book from 2002 suggests that gardening is a better metaphor for systems building than is engineering) - Apache Vine - linking stuff (people, business, systems) together - Apache Lancelot - a famous landscape gardener in the UK, responsible for many of the most splendid country house gardens, was Lancelot "Capability" Brown On the judo theme suggested by Richard: - Apache Ippon - does indeed mean an immediate win (like a knockout in boxing) - Apache Hajime - means "begin" ... successful projects never end? - Apache Tatame - is the mat, not sure what the metaphor is there - Apache Jigoro - after Jigoro Kano, the inventor of judo who synthesized a number of earlier martial arts (principally aikido and ju-jitsu) - Apache Kyu - a student (cos we're all learning) - Apache Tori - the person performing the technique (the thrower) - Apache Yoshi - continue Other/random - Apache Headstrong - cos we're opinionated - Apache Edison - light bulb ideas (probably trademared though) - Apache Realise - to both have a deeper insight and also to have achieved something (foresee forgetting whether is spelt with an 's' or a 'z') - Apache Solve Other tag lines: - "realize your model" > 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 > > > 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
[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=15134935#comment-15134935 ] Cesar Lugo commented on ISIS-1303: -- Jedu, sounds cool, might be playful, starts with J(ava), sounds like Just Do, Java edu. edu starts with e (enterprise?) and ends with u (you). 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 > > > 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. > Candidate names: > - hex (might hit trademark issues) >
[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=15134896#comment-15134896 ] David Tildesley commented on ISIS-1303: --- Hi All, My suggestion: Apache Jedu "Jedu" is Czech for "Jet" which invokes the idea of "rapid", "speed". JEDU is "Just Enough Design Upfront" - sweet spot for Apache ISIS as a tool to aid consensus based domain modelling - which is JEDU in practice. David. > 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 > > > 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
[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=15134012#comment-15134012 ] Dan Haywood commented on ISIS-1303: --- I've summarised all the name ideas thus far on our wiki: https://cwiki.apache.org/confluence/display/ISIS/Name+ideas Do continue to add your thoughts onto this issue, and comment/extend the wiki page also. If you are especially keen on a particular name, it'd be great if you could start doing some of the checks (eg trademarks and documenting your findings. > 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 > > > 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
[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=15132261#comment-15132261 ] Jörg Rade commented on ISIS-1303: - Very interesting discussion - made me come up to: ProjectNames: * PureObjects * Distill * Acceleration * Allegro * Flux Slogans: * "No Fuss - Just Objects" (cineastic) * "$less buzz | more action" (nerdic) -j > 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: ApacheGestalt.jpg > > > 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. > Candidate names: > - hex (might
[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=15132189#comment-15132189 ] Richard Pawson commented on ISIS-1303: -- Given that Isis was a (mutually agreed and beneficial) split off from Naked Objects, I wouldn't normally offer and opinion on this, but Dan invited me to, so ... In understand the desire not to base the name on DDD or 'naked objects', because neither has gained much popular traction (much to my disappointment). Personally, I have never really seen the big deal about the Hexagonal architecture, and, even aside from that, I just don't like the name 'hex' at all - perhaps because of its rather sinister meaning, as in 'put a hex on something' (meaning put a curse on it). I think that dropping Isis in favour of Hex* would be an odd move! One thing that I hope we all still agree on is the central idea of objects - real objects, with rich behaviours. I have long argued, in my PhD thesis and elsewhere, that Naked Objects, and hence Isis also, are a better reflection of the OO ideal than anything that has been done since the early '70s. So how about a name that reflects the commitment to objects in some way. This could be the some reference or play on something that historical that was very significant in OO e.g.: Stimula (for Simula) Norway (origin of OO) Park (as in Xerox Parc) LargeTalk (I'm sure I don't need to explain that one) or some important technical idea in OO: Reflect (I quite like this idea, as reflecting over the model is a key idea), or Reflector or some acronym with OO in it e.g. ROOT (Real Object Oriented Technology) ROOF (Framework) Finally, and unrelated, I always like classical names e.g. Prometheus (stole the fire from heaven and give it to mere mortals) Narcissus (reflection again) or if you want to be really ironical: Procrustes (the innkeeper who insisted that customers should fit his bedstead either by stretching them on a rack, or sawing their legs off. The original 'opinionated framework'?) Richard Pawson > 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: ApacheGestalt.jpg > > > 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.
[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=15133166#comment-15133166 ] Ged commented on ISIS-1303: --- !ApacheFarthing.jpg! > 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, ApacheGestalt.jpg > > > 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. > Candidate names: > - hex (might hit trademark issues) > - hexagon > - hexagn (deliberately mis-spelled) > - hxg (omitting vowels, but could stand for hexagonal, extensible, generic) > - hx (too short?) > some made up
[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=15133414#comment-15133414 ] Steve Cameron commented on ISIS-1303: - I like this discussion, to choose a name I suggest to forget about the technical side (e.g hexagon) for a bit and think of something that has more 'mojo', find a name with good association, even a made-up name (e.g Microsoft, Facebook). I've previously suggested Apache Driver (Driven, Driverseat, Highway, Freeway) to Dan and Jeroen. Driver reflects the NO and DDD heritage (does the software drive the business or the business drive the software, well hopefully both). In terms of marketing, in general the goal is to provide people with what they want or think they want (i.e. get a rabbit costume), they are out shopping, have money to spend (figuratively speaking), your advertising has worked, now you just have to convince them that what you are offering represents the best value amongst competiting alternatives. Good sales-persons can be creative with the truth to achieve this, but I don't think that is the approach to take here! The buyers will have some technical nouse, but "closing the sale" is still necessary, you have to get a decision to action. Again, I've suggested offering 1 day training courses as one way to do this, as help to "try-before-you buy" (the videos that Dan does are good, but can be built upon further). Maybe Apache River (as in something that flows through a Valley), that might have been the original thought. > 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 > > > 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
[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=15131997#comment-15131997 ] Ged commented on ISIS-1303: --- Hi Dan, >From my experience selling AI internally is that it is seen as a developer tool. Which is why JHipster is seen as an alternative. JHipster was the winner on my latest project because developers prefer it. They can look at the templates and see what it is doing. They also feel that they can drop jHipster at any point and just use the code. AI appears magical, and developers distrust that. So I think there will be a lot of benefit in pushing AI in the wider context as a tool that promotes greater collaboration between business and IT that would be great. I also believe that this topic is far more important than just one framework. I'd strongly recommend the book "The Second Machine Age" by Erik Brynjolfsson and Andrew McAfee. Here;s a bit from the first chapter: "The final section—chapters 12 through 15—discusses what interventions will be appropriate and effective for this age. Our economic goals should be to maximize the bounty while mitigating the negative effects of the spread. We’ll offer our ideas about how to best accomplish these aims, both in the short term and in the more distant future, when progress really has brought us into a world so technologically advanced that it seems to be the stuff of science fiction. As we stress in our concluding chapter, the choices we make from now on will determine what kind of world that is. " http://secondmachineage.com/wp-content/uploads/2015/03/SecondMachineAge_Ch1.pdf I don't think this is a message for AI to carry alone, but I would suggest seeking out like minded projects so that AI is part of a greater whole that works towards a better future through better software. f The "motherhood and applie pie message" needs to be preached. There are still many who see it as unpaid labour and produce with a short shelf life, and they tend to be holding the purse. Regards, Ged > 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: ApacheGestalt.jpg > > > 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
[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=15132585#comment-15132585 ] Cesar Lugo commented on ISIS-1303: -- As per Dan´s comment: "One thing I realize I haven't thought about sufficiently is figuring out what sort of audience we are looking to immediately connect with - bluntly, techies or business folk". I think it´s the software architect, or in smaller project the development team lead, who makes such a decision, or the CEO in larger organizations, highly influenced by the software architects. Also, I have learned (the hard way) that in marketing, the more radical you want to be, the more marketing power (and money) you will need to switch people´s minds (also known as the purchase vision in Solution Selling methodology). Also, one of the guidelines of Solution Selling methodologies is something like this "If you are a wolf but people is looking for a rabbit, get a rabbit costume. Once inside, convince them that what they are looking for is a wolf (redefine the purchase vision)". Speed might be too common (quite true), but read the comments and quotes, most of us still look for it as the number 1 benefit. Another way to look at it is the way Gen pointed out above: Apache ISIS provides AUGMENTATION to our software. I think that a multiplier factor is something all of us are really looking for and highly appreciated: do more with less. Yesterday I was thinking about XAGon, making the G look like a number 6 (X for multiply, A ffor app, 6 times), which creates curiosity to learn about the hexagonal concept understood as an augmentation or multiplier core enabler (you promise something, then quickly and simply back it up, with one diagram). But today some more great ideas and names have raised, which look quite good too with quite strong arguments (nice!). It´s quite nice to see Richard Pawson involved, I like that cooperation spirit you guys keep. 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: ApacheGestalt.jpg > > > 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
[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=15132667#comment-15132667 ] Dan Haywood commented on ISIS-1303: --- Other new thoughts/metaphors: - gearing / ratios: Apache Isis (as is) allows fewer developers to do more because it amplifies their efforts. I couldn't think of any better metaphor image than the one Ged suggested yesterday, namely penny farthing cycle (big wheel to small wheel). So that's a potential vote for "farthing" as a name - bridges; we're building bridges between business and IT. Trying to think of nice and fairly well-known bridge names... the one that caught my eye was "Menai" (Menai Straits bridge - look it up on Wikipedia). I too like the augmentation concept, but couldn't think of anything particularly inspiring in that fold. Richard's name of "Reflect" strikes a chord with me too, though... I like it's both techie but also might intrigue someone wearing more of a business hat. > 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: ApacheGestalt.jpg > > > 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 > -
[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=15132789#comment-15132789 ] Oscar Bou commented on ISIS-1303: - Hi friends. Nice debate. I'm going to focus on the ones that might "buy" Isis. Until now, Apache Isis is best suited for business-oriented apps, not infra-like apps. And seems nearly all we have the need to implement really fast business apps with complex logic on it, being that the main reason we've chosen Apache Isis over competing frameworks/solutions. I fully agree with Cesar, that the name preferably might clearly identify our core strengths, as we're not particularly strong in marketing (but really ambitious in Apache Isis success :) That said, the following name has available domains: BIZ4IT I will think about more "business oriented" terms. Any help will be appreciated :) > 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: ApacheGestalt.jpg > > > 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
[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=15132806#comment-15132806 ] Richard Pawson commented on ISIS-1303: -- What about one of the dozens of terms from Judo - one that has some sort of elegant meaning. I don't know much about Judo, but by way of example: Ippon means something like 'a win in one move' I think. I assume that whatever you choose, it will still be Apache xxx, so you need to think about how that sounds. Apache Ippon works. > 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: ApacheGestalt.jpg > > > 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
[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=15131926#comment-15131926 ] Dan Haywood commented on ISIS-1303: --- So, Vladimir's comment suggests one possible strapline: "do the right thing". > 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: ApacheGestalt.jpg > > > 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. > Candidate names: > - hex (might hit trademark issues) > - hexagon > - hexagn (deliberately mis-spelled) > - hxg (omitting vowels, but could stand for hexagonal,
[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=15131983#comment-15131983 ] Martin Vogel commented on ISIS-1303: Taking up Dans idea of the "headroom", more slightly spatial terms come across my mind. What do you think about "Apache Sphere" or "Apache Realm" respective a mix of both ? It emphasizes the separation in terms of the business domain and also might be associated with "fast" things (like rockets) regarding the development cycle. > 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: ApacheGestalt.jpg > > > 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
[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=15130135#comment-15130135 ] Alejandro Duarte commented on ISIS-1303: Hi everyone, Great to hear about this. Anytime I try to explain what Apache Isis is (a Naked Objects implementation), I get jokes about helicopters and sexy stuff ;) This redirects attention and interest from the framework to other things. Some thoughts: * Regarding a new name: ** I would advice against using acronyms. The name communicates, it should reflect what the framework is about. Acronyms tell nothing to people who comes across them. ** In my opinion, _Hexagon_ sounds catchy. The spelling variations might be good options only if the change in spelling has meaning. * JHipster... I see what you did there ;) but it's probably better to follow Dan's advice and not to take those seriously :) * How about using _breaking down barriers between IT and business_ or _don't be square_ as slogan? * I kind of like the association between "hexagonal" and "honeycomb" but would rather use honeycomb as inspiration for logo or marketing related art. Anyway, just my 5 bits... Cheers. > 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 > > > 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
[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=15130195#comment-15130195
]
Jörg Rade commented on ISIS-1303:
-
Hi,
{code}We are like dwarfs sitting on the shoulders of giants{code} and
definitely Engelbart is one of them. It would be nice to have all those
influences summarized.
For marketing purposes I think the variants of Hexagonal come in handy, since
they refer to the very expressive overview diagram and some honeycomb logo
could dig into the readers brain.
-j
> 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
>
>
> 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 -
[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=15130120#comment-15130120 ] Ged commented on ISIS-1303: --- My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical different between JHipster and Apache Isis * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a form of user interaction that maximizes the overall effectiveness of the users in fulfilling their broader responsibilities.* This means giving the users more control, for example over the order in which capabilities are invoked in order to achieve a goal. We should also design systems that allow users to become more expert as they learn, rather than constraining everyone to the lowest common denominator. | | http://www.nakedobjects.org/book/section7.html (emphais added) | So the Naked Objects approach is not about developing UIs faster or any type of architecture. Those are just enablers that helps us reach the goal of augmenting human activities. Augmenting the human activities that both develop and use software systems. Engelbart was the pioneer of using computers for human augmentation. His goal was the "boosting mankind’s capability for coping with complex, urgent problems". Reenskaug's forward to Pawson's thesis includes this quote: | By "augmenting human intellect" we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. . . Increased capability in this respect is taken to mean a mixture of the following: more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex, speedier solutions, better solutions, and the possibility of finding solutions to problems that before seemed insoluble. | | http://www.dougengelbart.org/pubs/augment-3906.html | Engelbarts 'Mother of all Demos' is essential viewing: https://www.youtube.com/watch?v=yJDv-zdhzMY I believe that Apache Isis also suffers from being to ahead of it's time, as Engelbart was. Here's an interesting retrospect on how Engelbart came to see his career as a failure: http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/ I believe that this change of name should be taken as an opportunity to return this goal of human augmentation as the central theme for the project, keeping alive the vision of Pawson and Engelbart. By focusing on allowing humans to do more by augmenting their capabilities rather than seeking to have humans to less by automating what they do. h1. Apache Engelbart * speedier solutions * better solutions * solutions to problems that were once insoluble > 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 > > > 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,
[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=15130231#comment-15130231 ] Ged commented on ISIS-1303: --- Another potential name on this theme is Apache Gestalt, based on this slide from Shyman Sankar's TED Talk !ApacheGestalt.gif! Gestalt means "an organized whole that is perceived as more than the sum of its parts." > 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: ApacheGestalt.jpg > > > 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. > Candidate names: > - hex (might hit
[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=15130587#comment-15130587 ] Cesar Lugo commented on ISIS-1303: -- Hello. I agree that, from a marketing perspective, this is a very good initiative, Despite how elegant Isis might sound, the other Isis is making too much noise to you, and you need to be heard. I have been involved in a few professional marketing processes when marketing some of our products to US, Europe and Latin America, and the marketing experts pointed out more or less the following (in my own words, sorry about that): The name must be memorable (easy to remember). The name should quite simply represent the main properties (not features) of your product (no explanations needed, almost obvious) . The properties are the ones in the minds of your potential customers and actual customers. They also suggested we considered names coming from Latin roots. This helps when addressing non-English spoken people, mostly likely it will be the same or very similar word in many languages, at least Latin root languages. That said, let me share with you which ones I think might be your main competitors, direct or indirect, and their main property in my mind: - Spring Framework. (Comprehensive, de facto standard to many, mature / old?) - Spring Framework. (ups!) - Grails. (Fast) - OpenXava. (Faster) - Vaadin. (Elegant, Beautiful UI, for the Java-only guys) - Play. (Fast?) - Django?. (Yes Python, still a competitor, almost a de facto standard) - RoR? (Ruby on Rails) (Yes Ruby, still a competitor, de facto standard) - Cubicweb?. (Python, fast, semantic) Now, let me share with you the ones I think are the properties that really make a difference in your Framework, at least in my mind, and in the ones I could infer from the mailing list, success stories and quotes. Number 1: Faster development. Faster business results. (Fast implies lower cost in people´s minds, maybe) Number 2: Business oriented (the more business add ons you create the better for your product, IMHO, much more than the technical stuff, where you have done a great job so far). Number 3: Eases IT-business users communication (via prototyping, not paper, users don´t have imagination). Number 4, 5, 6, 7 Great support, nice documentation, and a lot more, but does not matter. It´s hard to remember more than 2 or tree when new to something. I don´t want to suggest a name, Apache Speedy Gonzalez, the latest might be well known but doesn´t necessarily have the desired image or reputation (LOL, just kidding!). A slogan should be short and simple. Don´t you like things like Home Depot´s "More Saving, More Doing" or Walmart´s "Save Money. Live Better"? Something like "Prototype. Deliver. Fast!" or "Business. Results. Now." might work?. I hope that helps. 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: ApacheGestalt.jpg > > > 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
[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=15130634#comment-15130634 ] Cesar Lugo commented on ISIS-1303: -- Following up with Dan and Tobias, if you like hexagon, what about something like XAgon, with X and A leaning forward like giving the impression of speed? Apache XAgon Prototype. Deliver. Fast! > 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: ApacheGestalt.jpg > > > 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. > Candidate names: > - hex (might hit trademark
[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=15131823#comment-15131823 ] Vladimir Nisevic commented on ISIS-1303: Hello, last time I'm showing the prototypes based on Isis, so I need often to explain what is the framework behind and the things it stands for: DDD, NO, hexagonal architecture, invest/focus on business domain and not infrastructure. And yes, lot of other frameworks have some of that arguments as well - especially "idea to focus on your business problems and less boilerplate and/or infrastructure code". But when I step back and look onto it, as the main usp of Isis that I see, is the possibility to establish a totally new way of tight collaboration with customer/requester. I use a kind of process as described by Eric Evans [1] combined with the NO principle - expose current business model in UI within minutes/hours and get the customer on board. This feature boosts me into fastest lane of model exploration ever and this is what brings me very fast to point where we discuss about "do we the right things". There is also a famous quote by Peter Drucker [2]. So I suggest not to promote Isis as a yet another framework for building "faster, cheaper" (doing the things right) but more as a tool/process for "doing the right things". Second thing is the idea behind "problem solver vs. process follower" (there was a great video from Richard Pawson on Vimeo I believe, unfortunately I can't find any more). Building the software thru investment in a company is always associated to the value it should brings, so extrapolating the business case is the part of the game, and the root of business case is often a kind of automation or current business steps/processes. Therefore lot of projects we invest into have as a goal a kind of "automation of business processes" and often bring as a solution "yet another process following system". The power of "problem solving tool" could be also something as a core feature what Isis stands for as a kind "problem solving framework"... Therefore I believe that at least one of those two core values I see, should be somehow embedded/recognizable in the name. 1] http://domainlanguage.com/ddd/whirlpool/ [2] http://www.ukessays.com/essays/business/management-is-doing-things-right-leadership-is-doing-the-right-things-business-essay.php > 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: ApacheGestalt.jpg > > > 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,
