Josef Blake write an article at Spotify about when to write Architecture Decision Records. Short summary: “Almost always!”.
Embarc has a set of cheat sheets (in German) for Software Architecture.
Simon Brown writes about an architecturally-evident coding style. He proposes to structure the components (what Eric Evans calls modules in Domain-Driven Design) along the architecture: In his example, he prefers functional components (parts of the domain) over a layer-style separation of the various program parts.
He concludes with:
The thinking [here] behind creating a micro-services architecture is essentially the same […]
Which seems a reasonable approach. He notes that this way of architecture design does not apply everywhere, of course. He notes the example of writing unit tests with mocks if the whole component only exposes a domain-layer interface.
I tend to agree with this design, as I like putting the domain as much into focus as possible. It might be a valid approach even to consider parts of the technical solution (i.e. persistence) as part of the domain. Still, it seems valid to cut a larger application along domains, if only to keep the various components small and isolated.
An interesting question on SoftwareEngineering on StackOverflow discusses Ubiquitous Language in a non-English domain. They note three options:
- Fully use the natural language of the domain.
- Fully work in english only.
- 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.
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.
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.
OpenID Connect, as a technology for authentication, has a set of libraries in many languages. One in particular is a library for Typescript, and is, appropriately, called OpenYOLO: “You only login once”.
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.
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.
What’s it mean to be a Software Engineer? Or, for that matter, a Software Architect?
Brian Webb gives a possible answer on the title distinction, classifying programmers, engineers and architects. The separation in these three groups might seem useful; more investigation necessary, as usual.