Loading ...
Sorry, an error occurred while loading the content.
 

Renaming words in the ubiquitos language? Is it important ?

Expand Messages
  • cjjohansen_ddd
    Hi our team has discovered a better word for a concept in our ubiquitos language. What we used to call an Actor on an Order is now going to be called.
    Message 1 of 14 , Feb 12, 2013
      Hi our team has discovered a better word for a concept in our ubiquitos language.

      What we used to call an 'Actor' on an Order is now going to be called. 'Collaborator' on a Form in the UI.

      Collaborator is not a bad word, its a quite good.
      Should I now do search and replace in our code in order to use the new word ?

      My Product Owner (PO), and team member would think I had been smoking crack or worse if i came up with a suggestion like that.
      Anyway We have used the old word Actor in a webservice contract, so that is not easily changed. (I know i could introduce 'Collaborator' and by time make actor obsolete.

      I know common sense would suggest not to get religious, and simply accept the old word. How ever i do feel tempted to use the new word.

      Eric Evans uses a term like "Hammering the ubiquitos language". Which i understand as "Its really really important to use the language/ concepts of the Project Owner/Users"


      Im curious to hear your comments and what you did in a similar situation.
    • Kevin Trethewey
      From my experience its impossible to get the business side to change their names for things. So even when we had come up with a more concise word for something
      Message 2 of 14 , Feb 12, 2013
        From my experience its impossible to get the business side to change their names for things. So even when we had come up with a more concise word for something we just ended up with two words for it if we tried to get people to use a new one. And that lead to even more confusion. So we don't do that anymore.

        I'm not sure that Actor or Collaborator where words that pre-existed in the domain, so you may not have that issue.

        TLDR: we rename code to be more meaningful all the time, but don't refactor our users.


        K

        --

        From: "cjjohansen_ddd" <chr.j.johansen@...>
        Sender: domaindrivendesign@yahoogroups.com
        Date: Tue, 12 Feb 2013 22:42:18 -0000
        To: <domaindrivendesign@yahoogroups.com>
        ReplyTo: domaindrivendesign@yahoogroups.com
        Subject: [domaindrivendesign] Renaming words in the ubiquitos language? Is it important ?

         

        Hi our team has discovered a better word for a concept in our ubiquitos language.

        What we used to call an 'Actor' on an Order is now going to be called. 'Collaborator' on a Form in the UI.

        Collaborator is not a bad word, its a quite good.
        Should I now do search and replace in our code in order to use the new word ?

        My Product Owner (PO), and team member would think I had been smoking crack or worse if i came up with a suggestion like that.
        Anyway We have used the old word Actor in a webservice contract, so that is not easily changed. (I know i could introduce 'Collaborator' and by time make actor obsolete.

        I know common sense would suggest not to get religious, and simply accept the old word. How ever i do feel tempted to use the new word.

        Eric Evans uses a term like "Hammering the ubiquitos language". Which i understand as "Its really really important to use the language/ concepts of the Project Owner/Users"

        Im curious to hear your comments and what you did in a similar situation.

      • Dan Haywood
        I have to say that we change names all the time. But then, I work with naked objects-pattern [1] frameworks [2], [3] where there are very few DRY
        Message 3 of 14 , Feb 13, 2013
          I have to say that we change names all the time.  But then, I work with naked objects-pattern [1] frameworks [2], [3] where there are very few DRY violations... so it's no great hardship.  These frameworks - because they reflect the code into the UI - also prevent there being two languages, one used by the business and one by the techies.

          Dan

          [3] http://nakedobjects.codeplex.com/


          On 13 February 2013 04:41, Kevin Trethewey <kevint@...> wrote:


          From my experience its impossible to get the business side to change their names for things. So even when we had come up with a more concise word for something we just ended up with two words for it if we tried to get people to use a new one. And that lead to even more confusion. So we don't do that anymore.

          I'm not sure that Actor or Collaborator where words that pre-existed in the domain, so you may not have that issue.

          TLDR: we rename code to be more meaningful all the time, but don't refactor our users.


          K

          --

          From: "cjjohansen_ddd" <chr.j.johansen@...>
          Date: Tue, 12 Feb 2013 22:42:18 -0000
          Subject: [domaindrivendesign] Renaming words in the ubiquitos language? Is it important ?

           

          Hi our team has discovered a better word for a concept in our ubiquitos language.

          What we used to call an 'Actor' on an Order is now going to be called. 'Collaborator' on a Form in the UI.

          Collaborator is not a bad word, its a quite good.
          Should I now do search and replace in our code in order to use the new word ?

          My Product Owner (PO), and team member would think I had been smoking crack or worse if i came up with a suggestion like that.
          Anyway We have used the old word Actor in a webservice contract, so that is not easily changed. (I know i could introduce 'Collaborator' and by time make actor obsolete.

          I know common sense would suggest not to get religious, and simply accept the old word. How ever i do feel tempted to use the new word.

          Eric Evans uses a term like "Hammering the ubiquitos language". Which i understand as "Its really really important to use the language/ concepts of the Project Owner/Users"

          Im curious to hear your comments and what you did in a similar situation.




        • Willem van Gool
          My understanding of the Ubiquitous Language has always been that is has to be a language that both the business people and the techies use and agree on,
          Message 4 of 14 , Feb 13, 2013
            My understanding of the Ubiquitous Language has always been that is has to be a language that both the business people and the techies use and agree on, because the sole purpose for that language is to minimize confusion during communication (whether it's meetings, documentation or code). If 'the business' has used the term Actor and is still using that today, while the techies (you guys) have found that 'collaborator' is probably more concise/appropriate, then you

            A. either have to convince everybody to adopt the new term first, and refactor when it's become the mainstream language, or
            B. accept the fact that 'Actor', even though it might not be the 'perfect term' in your eyes, is preferred simply because it is the status quo within the bounded context you're working in and leave it at that.

            On the other hand, if you've noticed that 'the business people' have started using 'Collaborator' more often than 'Actor' and you all agree this is a better term, you have a good case to convince all the techies/PO that that should be reflected in all documentation and code as well..

            On Tue, Feb 12, 2013 at 11:42 PM, cjjohansen_ddd <chr.j.johansen@...> wrote:
             

            Hi our team has discovered a better word for a concept in our ubiquitos language.

            What we used to call an 'Actor' on an Order is now going to be called. 'Collaborator' on a Form in the UI.

            Collaborator is not a bad word, its a quite good.
            Should I now do search and replace in our code in order to use the new word ?

            My Product Owner (PO), and team member would think I had been smoking crack or worse if i came up with a suggestion like that.
            Anyway We have used the old word Actor in a webservice contract, so that is not easily changed. (I know i could introduce 'Collaborator' and by time make actor obsolete.

            I know common sense would suggest not to get religious, and simply accept the old word. How ever i do feel tempted to use the new word.

            Eric Evans uses a term like "Hammering the ubiquitos language". Which i understand as "Its really really important to use the language/ concepts of the Project Owner/Users"

            Im curious to hear your comments and what you did in a similar situation.


          • Greg Young
            I normally try to keep my responses on the list short. As it got to be a bit longer I dropped it up on my blog.
            Message 5 of 14 , Feb 13, 2013
              I normally try to keep my responses on the list short. As it got to be a bit longer I dropped it up on my blog.


              Cheers,

              Greg

              On Wed, Feb 13, 2013 at 12:42 AM, cjjohansen_ddd <chr.j.johansen@...> wrote:
               

              Hi our team has discovered a better word for a concept in our ubiquitos language.

              What we used to call an 'Actor' on an Order is now going to be called. 'Collaborator' on a Form in the UI.

              Collaborator is not a bad word, its a quite good.
              Should I now do search and replace in our code in order to use the new word ?

              My Product Owner (PO), and team member would think I had been smoking crack or worse if i came up with a suggestion like that.
              Anyway We have used the old word Actor in a webservice contract, so that is not easily changed. (I know i could introduce 'Collaborator' and by time make actor obsolete.

              I know common sense would suggest not to get religious, and simply accept the old word. How ever i do feel tempted to use the new word.

              Eric Evans uses a term like "Hammering the ubiquitos language". Which i understand as "Its really really important to use the language/ concepts of the Project Owner/Users"

              Im curious to hear your comments and what you did in a similar situation.




              --
              Le doute n'est pas une condition agréable, mais la certitude est absurde.
            • Dan Haywood
              I see Greg in his blog has taken me to task for not addressing the point in the OP s post: We have used the old word Actor in a webservice contract .
              Message 6 of 14 , Feb 13, 2013
                I see Greg in his blog has taken me to task for not addressing the point in the OP's post: "We have used the old word Actor in a webservice contract".

                Agreed... as any fule kno, you don't go breaking wire protocols... The consumer is in a different bounded context and so (unless they are all strictly conformist, [p361]), you'd better find a way to not break them.  That always requires some sort of wrapper around the domain model.

                My original post - when I said that yes you should change the word - was in response to the OP's statement: "our team has discovered a better word...".  If "team" is used [as per p25], then both domain experts and techies are using the new word, and so within their bounded context of course the code should change.  That's what model driven design [p47] means, isn't it?

                Dan


                On 13 February 2013 10:37, Greg Young <gregoryyoung1@...> wrote:


                I normally try to keep my responses on the list short. As it got to be a bit longer I dropped it up on my blog.


                Cheers,

                Greg


                On Wed, Feb 13, 2013 at 12:42 AM, cjjohansen_ddd <chr.j.johansen@...> wrote:
                 

                Hi our team has discovered a better word for a concept in our ubiquitos language.

                What we used to call an 'Actor' on an Order is now going to be called. 'Collaborator' on a Form in the UI.

                Collaborator is not a bad word, its a quite good.
                Should I now do search and replace in our code in order to use the new word ?

                My Product Owner (PO), and team member would think I had been smoking crack or worse if i came up with a suggestion like that.
                Anyway We have used the old word Actor in a webservice contract, so that is not easily changed. (I know i could introduce 'Collaborator' and by time make actor obsolete.

                I know common sense would suggest not to get religious, and simply accept the old word. How ever i do feel tempted to use the new word.

                Eric Evans uses a term like "Hammering the ubiquitos language". Which i understand as "Its really really important to use the language/ concepts of the Project Owner/Users"

                Im curious to hear your comments and what you did in a similar situation.




                --
                Le doute n'est pas une condition agréable, mais la certitude est absurde.



              • Greg Young
                taken to task ? I suggested you may all ready be in an environment that supports the change with naked objects. On Wed, Feb 13, 2013 at 7:36 PM, Dan Haywood
                Message 7 of 14 , Feb 13, 2013
                  "taken to task"? I suggested you may all ready be in an environment that supports the change with naked objects.

                  On Wed, Feb 13, 2013 at 7:36 PM, Dan Haywood <dan@...> wrote:
                   

                  I see Greg in his blog has taken me to task for not addressing the point in the OP's post: "We have used the old word Actor in a webservice contract".


                  Agreed... as any fule kno, you don't go breaking wire protocols... The consumer is in a different bounded context and so (unless they are all strictly conformist, [p361]), you'd better find a way to not break them.  That always requires some sort of wrapper around the domain model.

                  My original post - when I said that yes you should change the word - was in response to the OP's statement: "our team has discovered a better word...".  If "team" is used [as per p25], then both domain experts and techies are using the new word, and so within their bounded context of course the code should change.  That's what model driven design [p47] means, isn't it?

                  Dan


                  On 13 February 2013 10:37, Greg Young <gregoryyoung1@...> wrote:


                  I normally try to keep my responses on the list short. As it got to be a bit longer I dropped it up on my blog.


                  Cheers,

                  Greg


                  On Wed, Feb 13, 2013 at 12:42 AM, cjjohansen_ddd <chr.j.johansen@...> wrote:
                   

                  Hi our team has discovered a better word for a concept in our ubiquitos language.

                  What we used to call an 'Actor' on an Order is now going to be called. 'Collaborator' on a Form in the UI.

                  Collaborator is not a bad word, its a quite good.
                  Should I now do search and replace in our code in order to use the new word ?

                  My Product Owner (PO), and team member would think I had been smoking crack or worse if i came up with a suggestion like that.
                  Anyway We have used the old word Actor in a webservice contract, so that is not easily changed. (I know i could introduce 'Collaborator' and by time make actor obsolete.

                  I know common sense would suggest not to get religious, and simply accept the old word. How ever i do feel tempted to use the new word.

                  Eric Evans uses a term like "Hammering the ubiquitos language". Which i understand as "Its really really important to use the language/ concepts of the Project Owner/Users"

                  Im curious to hear your comments and what you did in a similar situation.




                  --
                  Le doute n'est pas une condition agréable, mais la certitude est absurde.






                  --
                  Le doute n'est pas une condition agréable, mais la certitude est absurde.
                • Giacomo Tesio
                  In the core domain, I saw that a strict matching with the domain expert language worth the change. In secondary contexts it s harder to measure the ROI of the
                  Message 8 of 14 , Feb 13, 2013
                    In the core domain, I saw that a strict matching with the domain expert language worth the change.

                    In secondary contexts it's harder to measure the ROI of the change.

                    Indeed, as the business evolves, ancillary contexts can acquire value and a better model become mandatory, but in such cases we have to rewrite them from scratch (often with different domain experts than those who drafted the original one).

                    So, for non-core bounded contexts, in such condition I ask to my self: how many people are affected by such a change? If it's more than three, I don't change the name. Indeed if it's more than three, probably that context is not so secondary...

                    However, you should also keep in mind that usually users are good domain experts: so if you have to translate a term from the UL in the UI to make it understandable (localization apart, of course), may be there's some smell in the model.


                    Giacomo



                    On Tue, Feb 12, 2013 at 11:42 PM, cjjohansen_ddd <chr.j.johansen@...> wrote:
                     

                    Hi our team has discovered a better word for a concept in our ubiquitos language.

                    What we used to call an 'Actor' on an Order is now going to be called. 'Collaborator' on a Form in the UI.

                    Collaborator is not a bad word, its a quite good.
                    Should I now do search and replace in our code in order to use the new word ?

                    My Product Owner (PO), and team member would think I had been smoking crack or worse if i came up with a suggestion like that.
                    Anyway We have used the old word Actor in a webservice contract, so that is not easily changed. (I know i could introduce 'Collaborator' and by time make actor obsolete.

                    I know common sense would suggest not to get religious, and simply accept the old word. How ever i do feel tempted to use the new word.

                    Eric Evans uses a term like "Hammering the ubiquitos language". Which i understand as "Its really really important to use the language/ concepts of the Project Owner/Users"

                    Im curious to hear your comments and what you did in a similar situation.


                  • Rickard Öberg
                    ... Excellent post, and I m glad you brought up the point of HATOEAS in REST APIs as a way to version client interactions. This allows you to change your
                    Message 9 of 14 , Feb 13, 2013
                      On 2/13/13 18:37 , Greg Young wrote:
                      > I normally try to keep my responses on the list short. As it got to be a
                      > bit longer I dropped it up on my blog.
                      >
                      >
                      > http://goodenoughsoftware.net/2013/02/13/refactoring-and-the-ubiquitous-language/

                      Excellent post, and I'm glad you brought up the point of HATOEAS in REST
                      APIs as a way to version client interactions. This allows you to change
                      your internal domain model anytime you want without having to use a
                      deprecation system, while still being able to maintain multiple
                      contracts with external clients (as long as the domain model can still
                      support the old usecases).

                      /Rickard
                    • cjjohansen_ddd
                      Thanks for all the replies. Hi Willem This phrase says what i m experiencing. On the other hand, if you ve noticed that the business people have started
                      Message 10 of 14 , Feb 14, 2013
                        Thanks for all the replies.

                        Hi Willem This phrase says what i'm experiencing.
                        "On the other hand, if you've noticed that 'the business people' have started using 'Collaborator' more often than 'Actor' and you all agree this is a better term, you have a good case to convince all the techies/PO that that should be reflected in all documentation and code as well.."

                        It is the PO who discovered 'Collaborator' (In my world PO is equal to Domain expert). The techies are familiar with 'Actor' and 'ActorRoles'.
                        I Have yet to see what words will be preferred by PO and other Domain Experts.



                        --- In domaindrivendesign@yahoogroups.com, Willem van Gool wrote:
                        >
                        > My understanding of the Ubiquitous Language has always been that is has to
                        > be a language that both the business people and the techies use and agree
                        > on, because the sole purpose for that language is to minimize confusion
                        > during communication (whether it's meetings, documentation or code). If
                        > 'the business' has used the term Actor and is still using that today, while
                        > the techies (you guys) have found that 'collaborator' is probably more
                        > concise/appropriate, then you
                        >
                        > A. either have to convince everybody to adopt the new term first, and
                        > refactor when it's become the mainstream language, or
                        > B. accept the fact that 'Actor', even though it might not be the 'perfect
                        > term' in your eyes, is preferred simply because it is the status quo within
                        > the bounded context you're working in and leave it at that.
                        >
                        > On the other hand, if you've noticed that 'the business people' have
                        > started using 'Collaborator' more often than 'Actor' and you all agree this
                        > is a better term, you have a good case to convince all the techies/PO that
                        > that should be reflected in all documentation and code as well..
                        >
                        > On Tue, Feb 12, 2013 at 11:42 PM, cjjohansen_ddd
                        > wrote:
                        >
                        > > **
                        > >
                        > >
                        > > Hi our team has discovered a better word for a concept in our ubiquitos
                        > > language.
                        > >
                        > > What we used to call an 'Actor' on an Order is now going to be called.
                        > > 'Collaborator' on a Form in the UI.
                        > >
                        > > Collaborator is not a bad word, its a quite good.
                        > > Should I now do search and replace in our code in order to use the new
                        > > word ?
                        > >
                        > > My Product Owner (PO), and team member would think I had been smoking
                        > > crack or worse if i came up with a suggestion like that.
                        > > Anyway We have used the old word Actor in a webservice contract, so that
                        > > is not easily changed. (I know i could introduce 'Collaborator' and by time
                        > > make actor obsolete.
                        > >
                        > > I know common sense would suggest not to get religious, and simply accept
                        > > the old word. How ever i do feel tempted to use the new word.
                        > >
                        > > Eric Evans uses a term like "Hammering the ubiquitos language". Which i
                        > > understand as "Its really really important to use the language/ concepts of
                        > > the Project Owner/Users"
                        > >
                        > > Im curious to hear your comments and what you did in a similar situation.
                        > >
                        > >
                        > >
                        >
                      • cjjohansen_ddd
                        Thanks Greg For a detailed and interesting answer. Yes exactly! My biggest concern is the Web Service contract. So i m weighing the advantage of using
                        Message 11 of 14 , Feb 14, 2013
                          Thanks Greg

                          For a detailed and interesting answer.
                          Yes exactly! My biggest concern is the Web Service contract.

                          So i'm weighing the advantage of using collaborator in the domain to keep that clean and in sync with Domain Experts; versus the disadavantage of having a different or obsolete name in the webservice contract, with the confusion that could cause. not to mind the wonder from colleagues and stakeholders "why i would fix something which ain't broken"

                          BR Christian

                          --- In domaindrivendesign@yahoogroups.com, Greg Young wrote:
                          >
                          > I normally try to keep my responses on the list short. As it got to be a
                          > bit longer I dropped it up on my blog.
                          >
                          > http://goodenoughsoftware.net/2013/02/13/refactoring-and-the-ubiquitous-language/
                          >
                          > Cheers,
                          >
                          > Greg
                          >
                          > On Wed, Feb 13, 2013 at 12:42 AM, cjjohansen_ddd
                          > wrote:
                          >
                          > > **
                          > >
                          > >
                          > > Hi our team has discovered a better word for a concept in our ubiquitos
                          > > language.
                          > >
                          > > What we used to call an 'Actor' on an Order is now going to be called.
                          > > 'Collaborator' on a Form in the UI.
                          > >
                          > > Collaborator is not a bad word, its a quite good.
                          > > Should I now do search and replace in our code in order to use the new
                          > > word ?
                          > >
                          > > My Product Owner (PO), and team member would think I had been smoking
                          > > crack or worse if i came up with a suggestion like that.
                          > > Anyway We have used the old word Actor in a webservice contract, so that
                          > > is not easily changed. (I know i could introduce 'Collaborator' and by time
                          > > make actor obsolete.
                          > >
                          > > I know common sense would suggest not to get religious, and simply accept
                          > > the old word. How ever i do feel tempted to use the new word.
                          > >
                          > > Eric Evans uses a term like "Hammering the ubiquitos language". Which i
                          > > understand as "Its really really important to use the language/ concepts of
                          > > the Project Owner/Users"
                          > >
                          > > Im curious to hear your comments and what you did in a similar situation.
                          > >
                          > >
                          > >
                          >
                          >
                          >
                          > --
                          > Le doute n'est pas une condition agréable, mais la certitude est absurde.
                          >
                        • cjjohansen_ddd
                          Hi Dan, Greg You are both right. With my Team i mean the PO + techies developing the server + clientside parts integrating with the server. This is one
                          Message 12 of 14 , Feb 14, 2013
                            Hi Dan, Greg

                            You are both right. With 'my Team' i mean the PO + techies developing the server + clientside parts integrating with the server. This is one bounded context.
                            We have other teams in my company which develops the Clients. They use an xml order format where this Actor concept is defined.

                            I only have full power to protect the server side domain model. I'm not in control how Client teams name or write their code. The code is not even developed with DDD in mind.

                            Actor and collaborator is very near each other. I'm only thinking that non tech users would more easily understand the word 'collaborator'.
                            Thus the PO (Domain Expert) wants this on the UI.

                            BR Christian




                            --- In domaindrivendesign@yahoogroups.com, Dan Haywood wrote:
                            >
                            > I see Greg in his blog has taken me to task for not addressing the point in
                            > the OP's post: "We have used the old word Actor in a webservice contract".
                            >
                            > Agreed... as any fule kno, you don't go breaking wire protocols... The
                            > consumer is in a different bounded context and so (unless they are all
                            > strictly conformist, [p361]), you'd better find a way to not break them.
                            > That always requires some sort of wrapper around the domain model.
                            >
                            > My original post - when I said that yes you should change the word - was in
                            > response to the OP's statement: "our team has discovered a better word...".
                            > If "team" is used [as per p25], then both domain experts and techies are
                            > using the new word, and so within their bounded context of course the code
                            > should change. That's what model driven design [p47] means, isn't it?
                            >
                            > Dan
                            >
                            >
                            > On 13 February 2013 10:37, Greg Young wrote:
                            >
                            > >
                            > >
                            > > I normally try to keep my responses on the list short. As it got to be a
                            > > bit longer I dropped it up on my blog.
                            > >
                            > >
                            > > http://goodenoughsoftware.net/2013/02/13/refactoring-and-the-ubiquitous-language/
                            > >
                            > > Cheers,
                            > >
                            > > Greg
                            > >
                            > >
                            > > On Wed, Feb 13, 2013 at 12:42 AM, cjjohansen_ddd
                            > > wrote:
                            > >
                            > >> **
                            > >>
                            > >>
                            > >> Hi our team has discovered a better word for a concept in our ubiquitos
                            > >> language.
                            > >>
                            > >> What we used to call an 'Actor' on an Order is now going to be called.
                            > >> 'Collaborator' on a Form in the UI.
                            > >>
                            > >> Collaborator is not a bad word, its a quite good.
                            > >> Should I now do search and replace in our code in order to use the new
                            > >> word ?
                            > >>
                            > >> My Product Owner (PO), and team member would think I had been smoking
                            > >> crack or worse if i came up with a suggestion like that.
                            > >> Anyway We have used the old word Actor in a webservice contract, so that
                            > >> is not easily changed. (I know i could introduce 'Collaborator' and by time
                            > >> make actor obsolete.
                            > >>
                            > >> I know common sense would suggest not to get religious, and simply accept
                            > >> the old word. How ever i do feel tempted to use the new word.
                            > >>
                            > >> Eric Evans uses a term like "Hammering the ubiquitos language". Which i
                            > >> understand as "Its really really important to use the language/ concepts of
                            > >> the Project Owner/Users"
                            > >>
                            > >> Im curious to hear your comments and what you did in a similar situation.
                            > >>
                            > >>
                            > >
                            > >
                            > > --
                            > > Le doute n'est pas une condition agréable, mais la certitude est absurde.
                            > >
                            > >
                            > >
                            >
                          • rdingwall
                            Sorry it s a bit late, but I posted a couple of thoughts as well on my blog: http://richarddingwall.name/2013/02/16/ubiquitious-language-handling-change In
                            Message 13 of 14 , Mar 8, 2013
                              Sorry it's a bit late, but I posted a couple of thoughts as well on my blog: http://richarddingwall.name/2013/02/16/ubiquitious-language-handling-change

                              In your case, it sounds like 'Collaborator' is the new adopted term, and and as a matter of technical debt, you should update your code to reflect this.

                              For the webservice, I would definitely leave the old name - you can't break wire compatibility. I don't think it's a big problem to use the wrong term here - only developers will see it, typically APIs are well documented (so you can clearly explain gotchas), and you can always fix it in a future API version.

                              Rich
                            • cjjohansen_ddd
                              Thx Rich All Commenters has suggested to do rename the domain. I will hold my breath and see if the new Collaborator term gains critical popularity. Yes
                              Message 14 of 14 , Mar 31, 2013
                                Thx Rich

                                All Commenters has suggested to do rename the domain. I will hold my breath and see if the new 'Collaborator' term gains 'critical' popularity.
                                Yes future versions of the Published language (xsd) can use new names.
                                Christian


                                --- In domaindrivendesign@yahoogroups.com, "rdingwall" <rdingwall@...> wrote:
                                >
                                >
                                >
                                > Sorry it's a bit late, but I posted a couple of thoughts as well on my blog: http://richarddingwall.name/2013/02/16/ubiquitious-language-handling-change
                                >
                                > In your case, it sounds like 'Collaborator' is the new adopted term, and and as a matter of technical debt, you should update your code to reflect this.
                                >
                                > For the webservice, I would definitely leave the old name - you can't break wire compatibility. I don't think it's a big problem to use the wrong term here - only developers will see it, typically APIs are well documented (so you can clearly explain gotchas), and you can always fix it in a future API version.
                                >
                                > Rich
                                >
                              Your message has been successfully submitted and would be delivered to recipients shortly.