Does programming in English conflict with the construction of a ubiquitous language?

Asked

Viewed 306 times

5

I have already found on the internet some arguments in favor of programming in English, instead of programming in Portuguese, and we even have a question questioning what would be the recommended way.

I happened to think about it from the point of view of Domain Driven Design. In this development methodology a very large focus is placed on the construction of a ubiquitous language. This means that the code must speak the same language as the domain.

This means that we code using the domain terms. The construction of ubiquitous language is what allows us to build the model and identify objects and behaviors. The code ends up mirroring the ubiquitous language that has been established.

It turns out that if you program in English, you’re already going to have a breakdown, apparently. After all, the code will use other terms, different from the terms of the business. Now, if the business is of a Portuguese-speaking country, its terms will be in Portuguese. From then on there is a translation layer between the code and the business.

In this sense, does programming in English conflict with the construction of a ubiquitous language? To establish a ubiquitous language and use it in development we must "do everything in one language"?

  • 6

    There are things that are utopian. But there are people who pursue them because someone said they are good. Since I started in this life, and there are already decades promise miraculous tools, some "buy" them, but only those who do not miracle survive.

  • 2

    In my view, if you are developing some framework, library, etc, it would be best to use English. First because it can be used in various applications, and second that nowadays, it is common to have contributions from foreign people. In the case of a system, depending on its theme, I believe it is interesting to use the native language. An ERP for example, it would be very complex to find translations for accounting and fiscal terms. The only strange thing, would be to mix the two, as IsCombustivel or GetValor

1 answer

3

The answer, as you can imagine, is to make anger. But it is the reality. It depends...

About a year and a half ago I had to develop a simple system, but it was for a multinational company. There was an import layout of a certain ERP to generate files with all commercial terms in English.

Bill to Customer (invoice for the customer) Ship to Customer (deliver to customer) . . .

That is, the domain of this client considers terms in English, therefore, I did the same in this way.

When the system is not for client that involves intrinsically English, or other language, besides Portuguese, I prefer to do in Portuguese, no doubt.

Imagining, for example, that the client for which you are doing the system is Brazilian, and especially, when it comes to tax/tax meanders, if you use English, it’s gonna get ugly...

Therefore, thinking of a system that treats some taxes, in addition to using pronunciable names, there are approaches that you can implement, even to fix the domain. According to Evans himself, "...we become specialists of new domains for each project..."

When you need to consider tax/tax issues and still accounting, you can draw, like in the same paper napkin, as would be...

Entity short form to instantiate class

Centrodecost cCusto or cc

Nature nature nature

ContasDeResultado CResultado

Demonstrationsresultherexercicio Dre

ImpostoSobreServicosDeQualquerNatureza ISSQN

Impostodeimportacao ii

CodigoFiscalDeOperacoesEPrestacoes CFOP

It is much more intuitive to model tax-related classes in Portuguese in this example. This is my vote, as long as you analyze if in fact the code in addition to serving the customer and its domain, also serve you.

I hope you’ve helped to clarify the case, even if you haven’t exhausted it.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.