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

Question

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

Navigation

#1 by (3 votes)

5

I've already found some arguments in favor of programming in English, instead of programming in Portuguese, and we already have a # wondering which 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 encode using the terms of the domain. The construction of ubiquitous language is what allows us to construct the model and identify the objects and behaviors. The code ends up mirroring the ubiquitous language that has been established.

It turns out that if we program in English, we're going to have a break, apparently. After all, the code will use other terms, different from the terms of the deal. Now, if the business is from a country where Portuguese is spoken, its terms will be in Portuguese. From there, 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 should we "do everything in one language"?

ddd nomenclatura

asked by anonymous 07.07.2016 / 06:05

1 answer

How does MVVM really work? [duplicate] Make button to change href="" every new access on a certain page

score 3 · Answer 1

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

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

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

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

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

Imagining, for example, that the customer you are making the system for is Brazilian, and especially when you are dealing with tax and tax information, if you use English, the thing will be ugly ...

So, thinking of a system that treats some taxes, in addition to using pronounceable names, there are approaches that you can implement, even to set the domain. According to Evans himself, "... we become experts in new domains at every project ..."

When you need to consider tax / tax issues and still accounting, you can draw, type on the same paper napkin, what would it look like ...

Short form entity to instantiate class

Cost Center cCusto or cC

Nature nature

ResultResults

DREExercise StatementDRE

Tax On Services Of Any Nature ISSQN

iI Importation Tax

CFO CodeOperations CFOP Settings

It is much more intuitive to model the 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 client and the domain of the same, also serves you.

I hope it helped to elucidate the case, even if it has not been exhausted.