Re: Re: What ubiquitous language should we speak?
Luis Abreu <[email protected]>
| Newsgroups | gmane.comp.programming.domain-driven-design |
|---|---|
| Message-ID | <CAA0ri5BO53OpuCEezvMq6OUAPGg+1V12HKc5BuU9ZZcwWHEMEA@mail.gmail.com> |
Nobody said only domain expert. I said that companies typically pick one language and that there was a chance of using one language per bc in the worst case scenario. Anyway, these were just possibilities, not definitive answers... On Jun 2, 2013 1:30 AM, <[email protected]> wrote: > ** > > > ** If you only have one domain expert is it really ddd? I always think > that ends up being waterfall. Especially if pushback is frowned upon. > Sent from my BlackBerry device on the Rogers Wireless Network > ------------------------------ > *From: * Luis Abreu <[email protected]> > *Sender: * [email protected] > *Date: *Sun, 2 Jun 2013 00:00:54 +0100 > *To: *<[email protected]> > *ReplyTo: * [email protected] > *Subject: *Re: [domaindrivendesign] Re: What ubiquitous language should > we speak? > > > > in a mixed-language environment, and in my experience, companies pick a > language which is used by everybody. What you say is true, but it's also > true that using a language which isn't understood by the domain expert > might end up getting you into trouble too... > > > On Sat, Jun 1, 2013 at 9:28 PM, guterfluss <[email protected]> wrote: > >> ** >> >> >> Hi, thanks for the reply. >> >> So, I'm talking in dutch. The domain expert speaks dutch. The classes and >> method names in the domain model are in dutch. >> >> And then suddenly the domain expert is replaced by someone else. He only >> speaks french and some english. >> >> Or... our dutch oriented company is taken over by an international >> company and the source code is now maintained by another team. Somewhere in >> the US. They have no idea what those classes and method names mean. >> >> It just seams very dangerous to express your UL in something else than >> english. >> >> Greetings >> Jan >> >> >> --- In [email protected], Luis Abreu <labreu@...> wrote: >> > >> > Probably use different languages for different bc according with the >> > language spoken by that bc's domain expert? >> > On May 31, 2013 11:13 PM, "guterfluss" <guterfluss@...> wrote: >> > >> > > ** >> >> > > >> > > >> > > I live in Belgium. The upper part speaks dutch, the lower french. My >> > > native tongue is dutch. The domain experts we work with speak dutch, >> french >> > > or sometimes english. >> > > >> > > Sometimes we even have a dutch speaking domain expert that leaves the >> > > company and is replaced by a french speaking domain expert. >> > > >> > > For these reasons I see no other possibility than to use english as >> the >> > > universal language. Unless you would know for sure that your customer >> will >> > > always be using dutch speaking domain experts. >> > > >> > > However, talking to domain experts in a language that is not yours >> and is >> > > not theirs as well is not that hard, but you tend to miss a lot of the >> > > small details of the language. >> > > >> > > So currently, we're constructing our UL by translating it from >> > > dutch/french to english. The code is in english, the conversations >> with the >> > > domain experts are in dutch or french. >> > > >> > > The sad thing is that the translations aren't always very good. We >> might >> > > use google translate to come up with some english translation but >> most of >> > > the time we end up with plain poor english. Things like >> > > 'something.assignSomethingElse()' or 'something.updated()' or >> > > 'something.doXXX'. >> > > >> > > So I guess, english speaking developers have a head start on others >> when >> > > doing DDD. >> > > >> > > I would like to know what others do in this situation when working in >> an >> > > environment where the language is not english, where you're working >> with >> > > domain experts that don't speak your language or when suddenly your >> domain >> > > expert's language changed. >> > > >> > > What ubiquitous language should we speak? >> > > >> > > Greetings >> > > Jan >> > > >> > > >> > > >> > >> >> > > > -- > Regards, > Luis Abreu > >