Ubiquitous Language in non-English domains

An interesting question on SoftwareEngineering on StackOverflow discusses Ubiquitous Language in a non-English domain. They note three options:

  1. Fully use the natural language of the domain.
  2. Fully work in english only.
  3. Create a translation table, use english internally, and the natural language outwards.

The original asker reports that about a year later, they made good experience with the third option. Translation is not an issue, and explicit translation has even helped to think about the domain more.

Answers highlight the difficulty of this decision. ZioBrando notes that the Ubiquitous Language is just a tool: If you don’t have an issue with translation or understanding, there is no need to fix anything.

PierreHenry notes a project in Switzerland that used mixed-language code base, and considers that the right decision, as much of the domain language was untranslatable.

OOP: Now and Future

On the StackOverflow blog, Medi Madelen Gwosdz wrote about why OOP is still a popular paradigm for programming. She found a couple of common advantages usually associated with Object Oriented Programming:

  • Encapsulation helps to hide complexity behind well-defined interfaces.
  • Inheritance helps to tackle repetition by extracting common code to parent classes.
  • Polymorphism enables code to adapt to varying scenarios in a localised way.

She argues that most of these features also pop up in functional programming, and finds a trend to shift towards that paradigm, with languages like Skala gaining popularity, and functional features arising in major languages Javascript and Java.

Note: Self-Contained Systems

Self-Contained Systems are a software-architecture pattern, described on https://scs-architecture.org/. They are similar to micro services, but include a UI. They are full systems with everything, they do not depend on other things. They represent a single, vertical slice through the overall system.

One advantage, according to Eberhard Wolff as he describes on his video cast, is that a functional requirement can be solved completely within this system. You (usually) don’t have to cross developer teams when you change things; API may turn to be internal APIs if they are not required externally, and may be easier to manage.

C# Profiling with Linux

With dotnet working rather flawlessly on Linux, sooner or later one stumbles upon the need to profile a dotnet application.

Microsoft provides a handy command-line tool for this: perfcollect. This tool measures dotnet performance indicators for a manual or pre-specified duration and generates a nice report about this.

Microsoft has documentation for perfcollect, or pav from Dots and Brackest wrote a post about profiling .Net core apps on Linux.

OAuth2: Authentication vs. Authorisation

Scott Brady makes a point that OAuth2 is not an authentication scheme, but an authorisation, or better yet, a delegation mechanism. He points out that tokens just provide validated access to any resource: Usually data of a user, but not necessarily; It may even only indicate that an application gets routine access to e.g. write to a log file.

He proposes to use OpenID Connect as the actual authentication mechanism built upon OAuth2.