Sunday, September 29, 2013

CZ The Trilogy

Over the weekend, we visited the Czech Republic for the third time (one and two). It's mostly chance that sends us that way every time though. This time, we were invited by friends to accompany them in staying over at their family's house - who made it their job to lead guided tours through Prague.

We left Thursday right after work, hoping to get there in eight hours. A decent traffic jam, a missed exit, and some bad map reading decided otherwise; it added three hours to the trip.

We stayed in a small town just twenty minutes outside of Prague, which has been able to preserve all of its rural character. We took one day to go out hiking, and were surprised by the local fauna; we were lucky enough to spot wild deer, wild boars and a viper (that last one already crushed to death though). Next to those species, the forest was heavily occupied by locals gathering mushrooms - must be the season?


We used the remaining two days to stroll through Prague, and to live like kings getting the most out of the favorable prices. Food and drinks cost less than half of what they do in Belgium. There is a zero-tolerance alcohol policy for drivers though - I got pulled over too, so they seem to be pretty serious about it.




Sunday, September 22, 2013

Actor Model in COBOL

In an Actor system, each Actor acts as a self-contained and autonomous component. An Actor can only communicate with other Actors by exchanging messages - they are not allowed to share state. Messages are handled asynchronously, and are nondeterministic. The location of Actors should be transparent; they can either live on the same machine, or on a distributed system. These properties make the Actor Model a great fit for parallel and distributed computing.

Even without considering parallelism and distribution, the Actor Model appeals to me. If you take an existing system, and make each aggregate in that system an Actor, what would the impact be? You can get rid of all the messaging and queuing infrastructure; messages and asynchrony are now first class citizens. Where you had to have discipline abiding the aggregate rules of thumb - modifying one aggregate per transaction, no references to other aggregates, Tell Don't Ask... - the very nature of Actors will guide you into doing the right thing.
Next to these implementation concerns, the model itself can be used as a framework for modeling and reasoning about complex systems. Once they are well educated on the constraints, it must come natural for domain experts as well.

Having worked with a team of mainframe programmers over the last year, it recently came to me that how they have designed their systems over the years is compatible with a good amount of Actor laws.


Composition

A good thing about COBOL seems to be that it's nearly impossible to write maintainable big programs, so you're forced to decompose your program into smallish autonomous components - into jobs.

Messages

Communication between these jobs happens by passing flat files around - the only format that's supported out-of-the-box.
Messages come in, and new messages go out. Jobs will never mutate the incoming payload, a new copy is created instead; pipes and filters.
Folders serve as a queue, allowing files to be processed asynchronously and nondeterministic.

Staying clear of mutating messages makes debugging extremely easy; you'll never hear someone on the team asking for reproduction steps, they just restore the production archives locally.

Addresses

Actors send messages to other Actors using their addresses. This can be a memory or disk address, a network address, email address, whatever really. In mainframe land, file system paths serve as addresses.

No shared state

In general they stay away from jobs sharing state; the default is to lock files exclusively, so sharing them is highly impractical. Even most static data gets synchronized instead of shared - banking reference data, customer addresses, configuration etc...

Scheduling

A scheduler sits on top of all these jobs. Its responsibility is to start a job when a new file arrives. If a job fails, the scheduler acts as a supervisor and will notify operations, which will investigate the issue - probably look at what's on the file system, and use the same scheduler to restart the failed job. Notice that one failing job doesn't impact other jobs.

All of this gives you an automated, highly observable and fault-tolerant system.

Although COBOL remains to be a horrible language, mainframe systems do have their strengths. There must be some good reason a lot of core business functions are still running on mainframes, right? Maybe similarities with the Actor Model are far-fetched and merely a figment of my imagination. Feel free to share your thoughts. 

Sunday, September 15, 2013

Slides from my talk on the Ubiquitous Language

I just returned from our yearly Euricom retreat. This year, all forty of us got to spend four days in the South of Spain. Where we had longish sessions and a few workshops last year, we experimented with shorter talks this year - a la lightning talks, TEDx style.

This format made it possible for everyone to speak, but also forced the speaker to keep the scope of the talk focused, and to organize the information in a way that attendees can get the gist of it in only twelve minutes. This makes for high-energy talks designed to peak one's interest, to share useful tips, to plant a seed or to pitch an idea.
Covering more than just technical ground alone made topics extremely diverse; from query tuning to empathy, from automated testing to how to explain your kids what you do for a living, from personal kanban to juggling with a diabolo. Going back and forth between these technical and less technical sessions kept my brain from being oversaturated.

Definitely an experiment that only yielded positive results; we will be using this format more frequently when organizing internal events.

Initially, I planned on doing a session on the DDD strategic patterns; the ubiquitous language, subdomains, bounded contexts, context mapping... but I couldn't capture all of that in a meaningful way in less than twelve minutes. That's why I started over, focusing on the ubiquitous language alone.

You can find my slides embedded below or on Slideshare.


Friday, September 6, 2013

The first DDDBE Modellathon

On our way back from DDD Exchange, heavily influenced by yet another immersive DDD experience, we searched for ways to keep the momentum going. Sure, we met up regularly for CQRS beers, but we felt that we could do more, better. That's when we coined the term modellathon, something like a hackathon, but instead of writing code, we would build models.

Thanks to the effort of Mathias, Stijn and Yves, Tuesday marked the first get-together of the Belgian DDD user group in its official form. Combell was kind enough to provide us with a location, while Mathias fronted paper - lots of it too, post-its and markers.

Mathias and Stijn took the lead introducing themselves as domain experts of the day. The domain? The United Schools of Kazachstan.

We split up into groups of four, and used our first pomodoro trying to understand the domain. The second pomodoro, we threw everything away and started fresh.

The first modeling technique our group tried was Alberto Brandolini's event storming. We took what we thought was the most important event report approved, wrote it on a post-it, and posted it on the center of our sheet of paper. Then we worked our way back to how we got there, but also looked at what happened next. This modeling approach yielded results very quickly; we all gained a decent understanding of everything what's going on in the domain. Talking to the domain expert made it obvious what the hotspots were, he kept referring to two post-its in particular.

We might have zoomed in right there, but for the sake of experimenting with event storming, we stuck to events a little longer. We added commands, looked for clusters, made aggregate boundaries based on that, and looked where they were talking to each other.

We initially used a sheet of paper and stayed seated, but this was holding us back. Once we stood up and moved to the wall, our synergy increased. Space and blood circulation seem to be important.

Flow is important too. Since we only had two domain experts, we often had to make assumptions and come up with a name that made sense. This slowed us down. We should just write down whatever we come up with, and make doubts explicit on the post-it. You can always verify and fix the language consulting the domain experts later.

The next visualization technique, initiated by Yves, took a UI-first approach. While this quickly gives you something concrete to chat about with the domain expert, I learned it can also lead you to bounded context boundaries by helping you answer the question "Where is all this data coming from, which contexts does this data belong to?"

I thought this first experiment went really well - a lot better than I expected. It proves once again the value of visualization and collaboration. All models were probably wrong, but turned out to be useful. The end result probably doesn't matter that much, discovery and learning along the way does.



Note to self: make pictures of the end results; they would help explaining some of the experiments.