Forem: Bertil Muth

Review your requirements with AI

Bertil Muth — Wed, 29 Nov 2023 15:03:36 +0000

I created a GPT App that assists you in reviewing and improving your softare requirements. You can try it out here:

I'm looking forward to your feedback!

Refactoring to Configurable Dependency in 5 Steps

Bertil Muth — Thu, 18 Aug 2022 13:33:50 +0000

Configurable Dependency, a.k.a. Dependency Injection, is a pattern that enables you to switch dependencies of your application. The term…

Continue reading on Medium »

Act — a library for (hierarchical) state machines

Bertil Muth — Thu, 09 Jun 2022 16:36:00 +0000

I created a library for defining executable state machines in your code. This includes the possibility to define hierarchical state machines with sub states. State machines simplify understanding how your code works when you have complex business rules.

As an oversimplified example for learning purposes, look at the following state machine for a shopping cart.

It represents its two fundamental states of being either empty, or non-empty.

The AddItem trigger causes a change to the non-empty cart state.

The RemoveItem trigger causes a change to the empty cart state, if the cart only contains 1 item.

And here's how the state machine is presented in code:

State<Cart, Trigger> emptyCartState = state("Empty Cart", cart -> cart != null && cart.items().size() == 0);
State<Cart, Trigger> nonEmptyCartState = state("Non-Empty Cart", cart -> cart != null && cart.items().size() > 0);

Statemachine<Cart, Trigger> statemachine = Statemachine.builder()
    .states(emptyCartState,nonEmptyCartState)
    .transitions(
        transition(anyState(), nonEmptyCartState, 
            when(AddItem.class, consumeWith(Cart::addItem))),

        transition(nonEmptyCartState, nonEmptyCartState, 
            whenInCase(RemoveItem.class, i -> i.state().items().size() > 1, supplyWith(Cart::removeItem))),

        transition(nonEmptyCartState, emptyCartState, 
            whenInCase(RemoveItem.class, i -> i.state().items().size() == 1, supplyWith(Cart::removeItem)))
    )
    .flows(
        entryFlow(when(CreateCart.class, init(Cart::createCart)))
    )
    .build();

Please visit the project on GitHub for details. I'm looking forward to your feedback.

Developer-friendly event sourcing

Bertil Muth — Sat, 15 Jan 2022 13:54:38 +0000

Here's what event sourcing is about: Every time you make a change to the application state, you record the change as an event.
You can replay the events since the beginning of the recording, up to a certain time. Then you've recreated the state of the application at that time. And by merging the events into a different data structure, you can provide a user specific view of the state (a "query model").

In short, event sourcing is about persisting events instead of just the current state. Event sourcing can be helpful for auditing purposes, and to analyze or rebuild previous system states for business analysis.

Think of a shopping cart: a typical e-commerce application would only store the state of the cart when the user proceeds to checkout. What if you want to know which shopping cart items have been removed by the user, to optimize the purchasing flow? That's when storing each event becomes helpful, e.g. ShoppingCartItemRemoved.

A Hello World example

In this example, a user sends a POST HTTP request with the data of a CreateGreeting command to the backend. This command contains the name of the person to greet. The backend transforms the command into a GreetingCreated event. This event contains the person's name from the command, and a default salutation (Hello,):

The event also contains the id of the entity you see in the middle: the Greeting entity that consumes the commands, and produces the events. That way, the state of this entity can later be reconstructed.

By producing the event, the Greeting entity has accepted the command as valid, and the event records this as a fact. The event is now stored in a journal, e.g. an in-memory, relational or NoSQL database.

So far, the state of the Greeting entity hasn't changed yet.
To change the state, Greeting takes the event and current state as input, and produces a new instance of the state class:

Objects of GreetingState are immutable. Greeting replaces the old state with the new state after applying the event.

What if you want to change the salutation for Jill's greeting later on? This can be done with a ChangeSalutationcommand. If you encode the id of Jill's Greeting entity in the request URL, the command handling looks like this:

Note that the event captures only the information that is relevant for the change about to happen. It doesn't need to capture all information in GreetingState.

Applying the SalutationChanged event looks like this:

The interesting thing is this: Greeting takes the salutation from the event, and combines it with the personName from its current state, to produce the new state.

The implementation problem

The problem I've seen in this. When building an event-sourced application, there is a steep learning curve. Not only do you need to get adjusted to this new way of thinking about state. You also need to learn the event sourcing library/framework details.

I want to change that. I created the Being library. It aims to cut down the technical complexity as far as possible. You can find it on Github. It's in an early stage of development, so I'm very thankful for Feedback.

Command and event handling code

When you use Being, you need to define the command handlers: which types of commands the entity consumes, and which event(s) it produces as a reaction to each command.

You also need to define the event handlers: for each of the event types, which new entity state to create as a reaction to it.

The behavior of the Greeting entity shown below has the following code:

public class Greeting implements AggregateBehavior<GreetingCommand, GreetingState> {
    @Override
    public GreetingState initialState(final String id) {
        return GreetingState.identifiedBy(id);
    }

    @Override
    public CommandHandlers<GreetingCommand, GreetingState> commandHandlers() {
        return CommandHandlers.handle(
            commandsOf(CreateGreeting.class).with((cmd,state) -> new GreetingCreated(state.id, "Hello,", cmd.personName)),
            commandsOf(ChangeSalutation.class).with((cmd, state) -> new SalutationChanged(state.id, cmd.salutation))
        );
    }

    @Override
    public EventHandlers<GreetingState> eventHandlers() {
        return EventHandlers.handle(
            eventsOf(GreetingCreated.class).with((event,state) -> new GreetingState(event.id, event.salutation, event.personName)),
            eventsOf(SalutationChanged.class).with((event,state) -> new GreetingState(event.id, event.salutation, state.personName))
        );
    }
}

Apart from the initialState() method that defines the starting state of Greeting, this should look pretty familiar.

The first command handler consumes a CreateGreeting command that contains the name of the person to greet, and produces a GreetingCreated event.

But a user can also change the salutation via a ChangeSalutation command. This command contains only the new text for the salutation, not the person's name. The person is identified by the entity's id, state.id.

Both the command handlers and the event handlers can use the current state of the entity. So when a SalutationChanged event is applied, the person name is not taken from the event, but from the current state of the entity: (event,state) -> new GreetingState(event.id, event.salutation, state.personName).

Code for the Greeting entity's state

Here's the code for the GreetingState class that represents the state of the entity:

public final class GreetingState {
    public final String id;
    public final String salutation;
    public final String personName;

    public static GreetingState identifiedBy(final String id) {
        return new GreetingState(id, "", "");
    }

    public GreetingState(final String id, final String salutation, final String personName) {
        this.id = id;
        this.salutation = salutation;
        this.personName = personName;
    }

    @Override
    public String toString() {
        return "GreetingState [id=" + id + ", salutation=" + salutation + ", personName=" + personName + "]";
    }
    // hashCode() and equals() omitted for brevity
}

As you can see, objects of the state class are immutable.

Code for commands and events

Commands are simple POJOs, as you can see in the following example:

public class CreateGreeting implements GreetingCommand{
    public final String personName;

    public CreateGreeting(String personName) {
        this.personName = personName;
    }

    @Override
    public String toString() {
        return "CreateGreeting [personName=" + personName + "]";
    }
}

Commands of an entity implement a common interface, like GreetingCommand in the example, which may be empty:

public interface GreetingCommand {
}

The reason for having a common interface for the commands is type safety. Use this command interface as the first type parameter of the entity class, as shown above.

Each event class must be a subclass of IdentifiedDomainEvent:

public final class GreetingCreated extends IdentifiedDomainEvent {
    public final String id;
    public final String salutation;
    public final String personName;

    public GreetingCreated(final String id, final String salutation, String personName) {
        super(SemanticVersion.from("1.0.0").toValue());
        this.id = id;
        this.salutation = salutation;
        this.personName = personName;
    }

    @Override
    public String identity() {
        return id;
    }

    @Override
    public String toString() {
        return "GreetingCreated [id=" + id + ", salutation=" + salutation + ", personName=" + personName + "]";
    }
}

Being is based on the powerful VLINGO XOOM platform that defines the IdentifiedDomainEvent super class.

Conclusion

Apart from what I've shown above, you also need to define the HTTP request handlers. The Being website explains how to do that.

I want to invite you to have a look at it, if you find this topic interesting. And I'm very grateful for feedback.
Drop a note in the comments, visit the Gitter community or contact me on Twitter.

Time to follow back

Bertil Muth — Sun, 07 Nov 2021 17:03:25 +0000

I noticed it on Twitter first: I became increasingly bored by the content I was seeing. I also noticed the almost cultish appraisal of “thought leaders”. Sure, some of them are great minds and post interesting stuff. But overall I found much of it trivial. And some responses were outright arrogant.

I suspect much of what happens on social media is based on popularity and social group phenomena, rather than quality of content. And I have probably missed a lot of interesting ideas because I followed the “big names” instead of giving everybody a fair chance.

So I’m ready for an experiment. At the time of this writing, I have close to 3100 followers on dev.to. But I only follow around 50 people. Shame on me ;-)

In the next couple of days, I will follow everyone who follows me back - all the existing followers, and new followers. Let’s see how that goes.

What do you think about all of this?

The most interesting topic

Bertil Muth — Sun, 31 Oct 2021 12:52:56 +0000

What’s the most interesting topic you’re learning about at the moment, tech or otherwise?

A laser-sharp analysis of the dysfunctions in large scale organizations

Bertil Muth — Thu, 30 Sep 2021 12:37:49 +0000

I recently posted this question on Twitter:

// Detect dark theme var iframe = document.getElementById('tweet-1443239158475108367-752'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1443239158475108367&theme=dark" }

My friend Daniel answered:

// Detect dark theme var iframe = document.getElementById('tweet-1443264870938517507-246'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1443264870938517507&theme=dark" }

I didn’t see that one coming. Okay…
I’ve been working as an Agile Coach, Scrum Master, consultant and trainer for large organizations like banks, insurances, automotive companies, medical device manufacturers and software development houses. I’ve seen the same dysfunctional patterns repeat over and over again. So I surely have an opinion on that. Is my analysis laser-sharp? Well, you decide.

The machine metaphor

We need to go way back in history to understand what happens in organizations today. Up to the first part of the 19th century, development of products was mainly done by craftsmen. Products were tailor made for the customers. Markets were mostly local.

The game changed with the industrialization. A different problem needed to be solved. Instead of tailoring a product for the individual customer, the question became: How do we produce the same product in large numbers? How do we ensure an acceptable quality, efficient and at low cost? How do we conquer new markets, once a market gets saturated?

The most important technical innovation that made a solution possible was the assembly line. Companies could now hire uneducated workers at low cost. All they needed to do was teach the workers how to play their part. Every employee working at the line was supposed to repeat the same kind of actions over and over again.

In a way, those employees acted like parts of a machine. And like parts of a machine, they were considered replaceable.

Spitfire manufacture. WWII World War 2 Castle Bromwich Aeroplane Factory, Birmingham 1940-46. Manufacturers: Vickers Armstrong. On Unsplash.
But there needed to be someone overseeing production. Someone with more knowledge. Who could make the right decisions when something went wrong. That's how 20th century management was born.

The job of the managers was to control that the machine was working in order. Issue a command if necessary. And control the output. The managers were the users of the machine.

The machine metaphor as an explanation of how the world works had been around in science and philosophy long before.

But now, it also started shaping how people thought about product development. And it has been ever since.

The machine metaphor is ubiquitous. We can hear it in
everyday speech: “things are humming,” “well-oiled,” “on
autopilot,” “firing on all cylinders,” “re-engineering,” and
“I’m just a cog in the wheel.” Viewing an organization as a
machine shapes our perceptions, expectations, and actions
profoundly.
Organizations as Machines, Organizations as Conversations

I will highlight three typical dysfunctions that result from it next.

Dysfunction #1: Command & Control

The idea that it makes sense for a manager to control the work and assign tasks to workers relies on the following assumptions:

The manager has an overview of the situation
The manager has more knowledge than the worker doing the job, concerning the task
The task can be assigned to a single individual

These assumptions were fulfilled in industrial production. They may still be useful in restaurant kitchens. But they can hardly be applied to knowledge work.

For innovative products, software development requires a whole group of creative people to exchange ideas. This is the best way to solve unknown problems that exceed the capabilities of a single individual that humanity knows.

Dysfunction #2: Optimizing utilization

At the assembly line, optimizing utilization of individual workers led to an optimization of the overall throughput of the system. Likewise, in many organizations today, employees work on multiple tasks or even projects at the same time. Yet the hope that a utilization close to 100% will lead to maximum productivity is often in vain.

Counterintuitively, the linear relationship between utilization and productivity doesn't hold up in environments with high variability in the arrival rate and size of work items. Note that this isn't my personal opinion. You can prove it mathematically, using queuing theory.

It is not the case that everything goes fast and smooth on the highway until just before 100 percent capacity of cars on the road. Rather, things slow down and gridlock happens well before capacity is reached.
[...]
With the misunderstanding “delay only starts when the highway is 100 percent full, ” there is a misguided focus on trying to improve cycle time by increasing resource utilization—getting the people in product development to be more busy, usually by more multitasking. This is the local-optimization thinking mistake.
[...]
As utilization goes up in a system with lots of variability, average cycle time gets worse, not better.
Large Scale Scrum on Queuing Theory

Dysfunction #3: Single function silos

Knowledge silos can't be avoided in large scale organizations. Due to the many possible communication relationships, each employee only communicates with a limited number of his colleagues. Software architecture styles like microservices even promote the reduction of dependencies between teams as a key benefit.

Yet there is a problem with how organizations set up these silos. Assembly line workers repeated the same activities over and over again. Departments in organizations follow that model: they have a single function. The QA department, the IT department, the Business Analysts etc.

Do one thing, and do it well. What has worked for the UNIX philosophy became a problem for departments that needed to cooperate to make any progress with the product they built together.

The consequences are:

delays when exchanging information
local optimization based on department specific goals
individual bonus systems that stand in the way of overall progress

Conclusion

I have highlighted three dysfunctions of large scale organizations. There are many more. But even after 18 years in the industry, I still believe there's a lot we can do about it. And we need to have patience. There's a lot of unlearning and learning that needs to happen.

Let us build a better, more inclusive and sustainable future together. Inside and outside of tech.

And one final remark: are you happy now, Daniel ;-) ?

Hello world, modular monolith

Bertil Muth — Fri, 27 Aug 2021 06:43:26 +0000

Photo by Kaleidico on Unsplash

I just published a new side project of mine, for creating modular monoliths.

It’s very early stage. Not more than an outline. I’m curious what you think about it, please leave me a note in the comments.

GitHub - bertilmuth/modular-monolith-helloworld: A hello world style example of a producer and consumer communicating with an event bus.

Each module is contained in its own Gradle project. Apart from main and connector, the modules have no dependencies.

This modular style of development potentially has the following benefits:

The modules mark team boundaries. Each team can work on its own data and behavior, hardly affected by the work of other teams. That can reduce the time to market of development teams.
Isolating the modules reduces cognitive load. A developer no longer needs to understand the whole application, but only the module she works on.
Reducing the dependencies avoids the dreaded big ball of mud, and makes the application in general more maintainable. In particular, it avoids cyclic dependencies between parts of the application.

This modular style has the following downsides:

It leads to eventual consistency. Since the modules communicate asynchronously, there is no guarantee for immediate consistency of data between modules.
More effort for reliable messaging. In a real world application, it must be made sure that no events get lost. This complicates the infrastructure logic.

Have you built a modular monolith?

Bertil Muth — Tue, 24 Aug 2021 11:55:36 +0000

Anybody has built a modular monolith? If yes: what were the design principles you used (i.e. request/response via interfaces, events on an in memory event bus for decoupling etc.)?

Dependency Injection in Javascript for Beginners

Bertil Muth — Thu, 19 Aug 2021 14:51:43 +0000

A few days ago, one of my students showed me his code. He had written an AWS lambda function that scrapes a web site and posts contents to Discord. He was unhappy because he couldn't test the contents of the messages being posted. He said that there wasn't a mocking framework for the external services.

I told him that he doesn't need a mocking framework. He just needs to use Dependency Injection (DI). DI enables you to:

test business logic isolated from external services and frameworks
switch services, technologies and frameworks more easily

Dependency Injection is at the heart of architectural styles like Clean Architecture and Hexagonal Architecture. Yet, you hardly find any simple examples that address DI specifically.

In this article, I will walk you through a simple example. Think of a calculator that adds and subtracts numbers and prints the results to the console:

add(5,3);
sub(100,1);

function log(result){
    console.log(result);
}

function add(x, y){
    const result = x + y;
    log(result);
}

function sub(x, y){
    const result = x - y;
    log(result);
}

This is what the code prints to the console:

8
99

The add and sub functions know the log function. Calculation and console logging are tightly coupled.

Think about that for a minute. What's the problem?

If you want to display the result on some other output channel, i.e. the GUI, you need to adapt the functions. The more output channels, the more complicated the functions become. Even though their main purpose is to calculate the result.

In your tests, you don't even want to print to the console. It only makes your tests slow. You just want to know if the result of the mathematical operation is correct.

So what can you do about it? How does DI help in the example?

You need to move the knowledge about the concrete display function out of add and sub. The simplest way to do that is to pass it as an argument. Here's the same example, but using DI. The output is the same as above.

add(5,3, log);
sub(100,1, log);

function log(result){
    console.log(result);
}

function add(x, y, display){
    const result = x + y;
    display(result);
}

function sub(x, y, display){
    const result = x - y;
    display(result);
}

You pass in the log function as an argument to add and sub. These functions then call log by using display, like an alias. So in this code, display(result); is equivalent to log(result);.

Since add and sub no longer know the exact function for displaying, you can pass in other functions. Say that on top of logging, you want to show an alert to the user in the GUI. Here's the code for that:

add(5,3, log);
add(5,3, alert);

sub(100,1, log);
sub(100,1, alert);

function log(result){
    console.log(result);
}

function add(x, y, display){
    const result = x + y;
    display(result);
}

function sub(x, y, display){
    const result = x - y;
    display(result);
}

We don't need to write code for alert. It's a built in Javascript function.

Finally, how do you approach testing? I'm not going into details of a testing framework. But here's the idea how to test with DI.

Using DI, you can pass in any function. It doesn't have to display. It can check whether the result is correct instead.
So here's a call that shows whether the result of 5 plus 3 equals 8:

add(5,3, r => alert(r == 8));

The code passes an anonymous function as third argument. Also known as a lambda function. It could have been a named function instead - that doesn't matter.

The point is: instead of displaying anything, the function takes the result of add and shows an alert whether it is equal to 8.

In a real world application, the next steps would be:

Move the functions that call I/O, external services etc. to a separate file
Establish a single place where all dependencies to I/O, external services etc. are created

Then, you can switch these dependencies. For testing, or in your production code. And that's a simple way to do dependency injection in Javascript.

Modern Clean Architecture

Bertil Muth — Tue, 10 Aug 2021 15:55:32 +0000

Clean Architecture is a term coined by Robert C. Martin. The main idea: Entities and use cases are independent of frameworks, UI, the database and external services.

Continue reading on Medium (paywall free) »

Modern clean architecture

Bertil Muth — Fri, 06 Aug 2021 19:28:30 +0000

I am pleased to announce the release of the modern-clean-architecture project.

Clean architecture follows these principles:

The domain code and use cases of an application are independent of frameworks, UI, the database or any external agency, e.g. external services.
Through this clear separation of concern, the domain code and use cases become testable independent of the framework, UI or infrastructure.
The user interface, database technology, external services and framework specific code can change without affecting the domain code and vice versa.

Modern clean architecture provides a fresh view on clean architecture, in a Spring Boot environment. It reduces the effort required to create a clean architecture through the following constraints:

Serialization of immutable requests and responses without serialization specific annotations.
No necessity for DTOs. You can use the same immutable value objects for requests/responses in web layer and use cases.
Generic endpoint that receives and forwards POST requests. New behavior and domain logic can be added and used without the need to write framework specific code.
Testing with a repository double that acts like a normal repository. No need for mocking it.

Visit the website, I'm happy to hear your thoughts.