Behaviour-Driven Development (BDD) is a software development process. As the name implies, it is based on the idea that the expected behavior of a system is defined before the source code for that system is written.

The behavior is documented in the form of a suit of tests that can be executed to validate how the system responds to a set of examples that cover the use cases of that system.

What events should my component publish? Not always an easy question to answer.

Software design is a continuous task. You never finish a software project, because it needs to evolve as the team’s knowledge about the problem it solves grows. This is why one of the principal characteristics of good software is being easy to change.

In an asynchronous software architecture, the events that a component publishes define its contract with the other components in the system. And a good interface contract is one that lets the component be useful to the other components, while making it easy enough to modify as the project grows.

A few days ago I stumpled upon this LinkedIn post (in Spanish, but easily understandable) including this image with two solutions to the same problem:

A software system is considered Multitenant when it can serve multiple clients with different data. Each registered user is part of one tenant, and will have access to the data that their tenant owns only.

In this article I will be covering how the Micronaut framework supports the creation of multi-tenant applications, as well as many other useful features for general development.

API-First development (also known as Contract-driven development) starts by designing and documenting the contracts between the components that build your system (services, user interfaces, third party providers, etc.) before writing the source code.

There are many benefits to this approach. Some of the main ones include:

• Central Source of Truth: The API specification serves as the definitive guide for component behavior, simplifying testing and validation.
• Parallel Development: Provider and consumer components can be developed simultaneously.
• Automation: Shared artifacts of the system can be generated directly from the specification documents.

An API specification document describes two things: component behavior and shared data schema. For component behavior we use specifications like OpenAPI for REST APIs, or AsyncAPI for Event-driven Architectures. These specifications allow us to define how our components interact, which endpoints they expose, which messages they publish and consume.

@ThreaderBot listens for Twitter mentions. When someone sends it a link, the bot will:

• Download the content of that link
• Extract and clean the text
• Summarize the text into up to five sentences using the TextRank algorithm
• Answers the Twitter mention with a thread including the generated summary.

The bot is developed in PHP with Symfony, and runs as a cron job in a Raspberry PI.