Big Ball of Code

Compositional user interfaces for distributed systems

Fri, 07 Jun 2019 14:00:00 +0200

In May I had the honour of presenting my “But what about the UI”-talk at µCon London 2019. This is a talk where I explore different patterns and strategies for composing user interfaces in distributed systems, like a microservice architecture. I had a great time delivering the talk - albeit I ran out of time and had to rush through some of the more beefy slides.

You can see the recording, and slides, of the presentation here. Signing up is free, and you get to watch all the other great talks from the conference as well!

Ever since developers started breaking applications into services, be it in the era of SOA or more recently with microservices, they’ve struggled to incorporate user interfaces into their decoupled, distributed architectures.

We’ve all seen frontends versioned separately with tight coupling to dependent services, breaking cohesion. The rise of Backend-For-Frontend is real and so is the emerge of micro frontends. We all talk about composition, yet so many projects fail to implement actual composition. The result seem to be some kind of compromise proving hard to scale when multiple teams are involved - causing lock-step deployment, latency, bottlenecks and coordination issues.

What if you could find a viable solution that allowed you to scale development, keep distribution and cohesion and also provide composition of user interfaces?

This talk explores the different patterns available, and attempts to pinpoint their pros and cons, effectively serving as guidance to implementing proper composition. Thomas will go beyond the simple “Hello World” example that always seems to work, and you’ll learn patterns in modelling and designing that can actually be employed for composition.

Who am I?

Thomas is a consultant from Norway who specializes in software architecture and development. He’s been a practitioner of Domain-Driven Design for the past 8 years or so and finds great joy in pondering in business problems. Clients and colleagues know him as an energetic and passionate craftsman who loves to learn, experiment, fail and succeed while sharing his own experiences and knowledge. Having worked with too many languages and technologies to mention, Thomas has found the intersection between business and IT to be a far more rewarding approach to problem solving and easing up the everyday work of software development. He’s known for holding workshops and talks for both his clients and at local user groups.

Cleaning up an unwieldy monolith without using microservices

Fri, 01 Jun 2018 14:00:00 +0200

Back in April I got the chance to present my talk “Cleaning up an unwieldy monolith without using microservices” at DDD eXchange 2018 in London. I’m honored by the opportunity I got, and had a blast talking about this subject - which is very dear to my heart.

You can see the recording, and slides, of the presentation here. Signing up is free, and you get to see all the other awesome talks as well!

As practitioners of domain-driven design we want to model and align our software with the business, but many of us experience how our legacy codebases holds us back. They provide value, but are often constraining, making it harder to apply domain-driven design. Have you not fantasized about the greenfield rewrite with proper models and abstractions, only to realize how hopeless it would be? Enter microservices: The promised land and seemingly silver bullet for tidying up an unwieldy monolith. They certainly appear tempting, but aren’t suitable for all of us, and cleaning up a messy monolith really isn’t their job. Eric Evans proposed the notion of bubble contexts back in 2012 as a means to create space for modelling in a legacy system. Perhaps we could take a step back and build a better understanding of our monoliths’ boundaries using this heritage.

This case study will look into how we started our journey of cleaning up a mission-critical monolith at a major Scandinavian payment solutions provider using bubble contexts and other aspects from domain-driven design. Using these we found a low-risk method of attacking our monolith and how to structure it based on our newfound insights of the domain.

You will learn how we took control over our monolith using DDD, why we chose not to use microservices - as well as both the failures and successes we had. You will also learn more technical details of some of the techniques we employed, and how we went about to adjust our surrounding organization to start thinking about business and development as one.

Who am I?

Thomas is a consultant from Norway who specializes in software architecture and development. He’s been a practitioner of Domain-Driven Design for the past 7 years or so and finds great joy in pondering in business problems. Clients and colleagues know him as an energetic and passionate craftsman who loves to learn, experiment, fail and succeed while sharing his own experiences and knowledge. Having worked with too many languages and technologies to mention, Thomas has found the intersection between business and IT to be a far more rewarding approach to problem solving and easing up the everyday work of software development. He’s known for holding workshops and talks for both his clients and at local user groups.

Facelift

Sat, 17 Sep 2016 14:00:00 +0200

Music has always been a passion for me, and I play a lot of it myself. As a gitarist, pianist, drummer and bassist I naturally have a lot of instruments (probably too many, to be honest). My instruments are of varying quality and price classes. When starting out playing something it’s tempting to buy something cheap in case you find you don’t like playing. This can be deceiving, though. Cheap instruments are more than often of a low quality. Playing a low quality instrument can be fun in the very beginning, but since it’s generally harder to make them sound good it soon becomes demotivating to play them.

I think maybe it’s the same with this blog. When I first created it I settled on using Jekyll and quickly threw together a layout that I figured would work. It was, however, not pretty. And to be frank, it’s kind of been keeping me from writing.

So now I’ve taken the step to give the blog a facelift. Instead of hacking together a new theme myself, I’ve gone for the excellent and open-source Minimal Mistakes Theme.

Breaking the monolith - without microservices

Mon, 20 Jun 2016 14:00:00 +0200

I recently gave a talk on how you can regain structure and control over a big ball of mud-ified monolith.

This talk is based on experiences from a customer I worked with some years ago. When we set out on this path we considered going the microservice-way, but ended up deciding against it.

We’ve seen quite a few talks the past years advocating the use of microservices for breaking up monoliths that have grown out of control. While there are many valid uses for microservices, I don’t think that this is one of them. As Simon Brown have previously said - If you can’t make a well-structured monolith, what makes you think you can create a well-structured microservices architecture?

In the talk, I present some stragies using domain-driven design to regain modelling space and structure in an existing monolith and delivering new value to the business in a fraction of time it would take to break this up into microservices.

The talk was delivered at Norwegian .NET User Group Vestfold, but is not .NET specific. It is, however, in Norwegian.

Slides

Presentation

Tell, don't ask!

Wed, 23 Mar 2016 23:00:00 +0100

Tell, don’t ask is a principle commonly used in object-oriented programming. It guides our designs towards less coupling and less ambiguity in our interfaces.

Object-oriented programming was meant to be objects sending each other messages. Today we know this as objects invoking methods on each other. I feel that many programmers have yet to grasp the idea of message-sending, which leads them to writing code like this:

condition = other_object.get_state()
if condition.foo == "bar":
  other_object.do_this()
else:
  other_object.do_that()

This might, at first glance, seem fine. But what happens when the list of conditions grow? Or what happens if other object is used from another place?

We’re basically breaking a couple of principles here. Most importantly, we’re breaking encapsulation. OtherObject is no longer in charge of its invariants, since we’re peeking into it and doing operations based on how we interpret its state. What happens if we make changes to OtherObject? We’ll probably break something, as we have other objects depending on its internal state.

Another issue caused by this kind of code is that of readability. A new consumer of OtherObject would have to check out the source for OtherObject before using it, because its exposed interface doesn’t tell the consumer how to use it.

If we instead apply the Tell, don’t ask principle our code would take on a shape similar to this:

class OtherObject:
  state = {..}
  
  def do_your_job(self):
    if state.foo == "bar":
      self.do_this()
    else:
      self.do_that()
  
  {..}
  
class CallingObject:
  def __main__():
    other_object = OtherObject()
    other_object.do_your_job()

Now our calling object doesn’t have to peek into OtherObject to determine what to do. We’ve encapsulated the behavior with its associated data in the object owning it. Furthermore we’ve effectively applied the Tell, don’t ask principle by letting our calling object trust the other object to do its job.

The code reads better, is easier to understand and ensures that we can refactor the internals of OtherObject however we like, as long as we maintain that simple interface of “do_your_job()”.

Avoid serialization objects

Sat, 20 Feb 2016 20:00:12 +0100

I’ve long honored and practiced the idea of translating objects when their data moves across contexts and boundaries. In this post I’m going to take a look at how this tends to be done, and ponder about whether the wide-spread practice of using objects to represent contracts and serializing them really is a good solution or not.

Be it XML, JSON or practically any serialization format - when working with them in object-oriented languages, we tend to craft objects that represent the contract, or even protocol, of our messages. Typically, these are POCOs (C#) or POJOs (Java). Establishing these objects makes it easy to serialize our messages, as we can simply run them through a serializer - like e.g. Newtonsoft JSON for .NET or Jackson for Java.

An object like this:

class Customer
{
  public string Name { get; set; }
  public AddressDetails Address { get; set; }

  class AddressDetails
  {
    public string Street { get; set; }
    public string ZipCode { get; set; }
    public string Town { get; set; }
  }
}

is automatically turned into something resembling this:

{
  "name": "John Doe",
  "address": {
    "street": "Some street",
    "zipCode": "1337",
    "town": "Our city"
  }
}

Seems all good, but if we poke a little at this, we’ll discover why this might actually not be what we want.

The first time you need to serialize some objects to a message, you’ll probably go ahead and feed your domain objects straight into the serializer of your choice. Mission accomplished; you’ve mapped your objects to a message that can easily be sent over the wire. After some time though, you refactor your domain objects. Suddenly your unit tests (because you wrote them, right?) are turning red. Quite naturally too, seeing as your message contract is effectively derived from your domain objects - which have now been leaked through a boundary crossing.

Wise from damage, you create a new set of objects resembling your domain since before your refactoring. You then create an Anti-Corruption Layer, or a mapper mechanism that takes your current domain object and map it into your “new” message object. You’ve now established a message contract.

I’ve done this myself many times, and I’ve even felt that it was a nice approach because the objects belonging to the mapping domain kind of represent your message contract. Lately, I’ve however started to notice that this not only carries along extra (and unnecessary double-work), but it’s also confusing for some team members. Especially when they’re not quite able to differentiate between objects of the domain and contract objects.

Then I saw Eric Evans tweeting about something similar the other day:

@mjpt777 @Daneel3001 Automatic conversion of objects into DTOs or other transferable things, leads to context leaks and dumb objects.
— Eric Evans (@ericevans0) February 15, 2016

I think these two tweets nail the issue. Objects encapsulate state and behavior. Our mapping objects are simple data-bags that in turn is reflected upon by some serializer to create a message. They have no behavior, and no state - making them quite dumb.

So I propose another approach to implementing your messaging protocols: Maintain the mapping code yourself in an Anti-Corruption layer. Mapping is actually very functional: f(object) -> mappedObject. We don’t need an object to represent this when a function is enough.

This clears things up a lot, because there are no mapping objects - and so the ambiguity surrounding contract objects versus domain objects is effectively removed.

How might we go ahead and implement this? It depends on your platform, language and toolbox of course. But just for the sake of it, I’ll provide an example for C# using Newtonsoft JSON.

static JObject CreateMessageRepresentation(Customer customer)
{
  return new JObject(
    new JProperty("customer",
      new JObject(
        new JProperty("name", customer.Name),
        new JProperty("address",
          new JObject(
            new JProperty("street", customer.Address.Street),
            new JProperty("zipCode", customer.Address.Zip),
            new JProperty("town", customer.Address.City)
          )
        )
      )
    )
  )
}

var message = CreateMessageRepresentation(someCustomer);
Console.WriteLine(message);

This gives us something like:

{
  "customer": {
    "name": "John Doe",
    "address": {
      "street": "Some street",
      "zipCode": "1337",
      "town": "Our city"
    }
  }
}

Note how explicit the mapping is. This gives you total control of how the message is produced, without relying on the reflection-abilities of a serializer.

The Cake Pattern

Sun, 26 Jan 2014 18:23:00 +0100

The past few months I’ve been toying around with the Scala programming language. My interest in Scala probably started with my currenct contract engaging me in developing on a Java-based stack. As I’m not a big fan of Java’s code noise and verbosity, I started looking at other JVM languages. Functional Programming has also been something that I wanted to look more into, so Scala seemed like a good start.

After having done quite a lot of playing around with pattern matching and other cool aspects of Scala I got tired of writing small playground applications and decided it was about time to write something closer to a real world application. Now, the real world is saturated with complexity and complexity is a well-known application killer. Thus many smart people have defined principles for helping developers deal with complexity in simpler ways. Some of these principles have been gathered into the SOLID acronym: Single Responsibility principle, Open/Closed principle, Liskov Substitution principle, Interface Segregation principle and the Dependency Inversion principle.

I won’t go into detail about any of these principles today, but rather talk about how we can solve Dependency Inversion in scala. Dependency Inversion can be summarized as having details depend upon abstractions (and not upon other details), as well as having abstractions not depend upon details.

Dependency Inversion is often solved through IoC - Inversion of Control, whereas Dependency Injection and Service Locating is two known patterns. The latter is considered an anti-pattern, while Dependency Injection has gained widespread usage.

Dependency Injection often looks like this in Java:

public interface OrderRepository {
	Order getOrderBy(int number);
}

@Component
public class MysqlOrderRepository : OrderRepository {
	public Order getOrderBy(int number) {
		...
	}
}

public class UseCase {
	private final OrderRepository _orders;

	@Autowired
	public UseCase(OrderRepository orderRepository) {
		this._orders = orderRepository;
	}

	public void doSomething(int ordernumber) {
		_orders.getOrderBy(ordernumber);
	}
}

Here we are using Spring as an IoC container. Basically we register MysqlOrderRepository as a candidate for being injected as OrderRepository, and signal that UseCase needs an OrderRepository to function. When we load up an instance of UseCase, Spring will automagically pass an instace of MysqlOrderRepository into it.

This might look all fine and dandy, but it sure gets complicated when you start having multiple implementations that you want to use in test- and production situations. And because it’s so easy to use Autowired, it’s normal to end up with lots of nested dependencies. Nested dependencies are allright in some, rare scenarios. Usually, though, having lots of nested dependencies is an indication that you’re doing something wrong.

In Scala, though, we can use the Cake Pattern to explicitly define our dependencies, and wiring them up just as we need them. I think this makes a code base far easier to read and understand, because you can immediatly see what’s going on.

Let’s go ahead and try implementing our example from before in Scala. First we create our OrderRepository:

class OrderRepository {
  def getOrderBy(number: Int): Order {
    println("Getting order by " + number)
    Order(number)
  }
}

Of course we could have extracted this into a trait. That would make the code look more like the Java example, but as we’re dealing with a pretty simple case here, I simply didn’t find it to useful to split it further.

Next up is our UseCase:

class UseCase {
  def doSomething(orderNumber: Int) {
    val order = orderRepository.getOrderBy(orderNumber)
    println("Doing something with " + order)
  }
}

As you can see, we’re now referencing an orderRepository that has a function getOrderBy(x: Int). How is this even gonna compile, you may ask? Well, it won’t yet. This is where the cake pattern enters.

First we wrap our dependency - the OrderRepository - into a trait:

trait OrderRepositoryComponent {
  val orderRepository: OrderRepository

  class OrderRepository {
    def getOrderBy(number: Int): Order {
      println("Getting order by " + number)
      Order(number)
    }
  }
}

Here we enclose the repository, and define an abstract field of OrderRepository.

Now we’re gonna look at the UseCase again, which is the consumer of our dependency. In order to have our OrderRepository injected into it, we’ll enclose it in a trait of it’s own, and then use a self-type annotation to declare our dependency:

trait UseCaseComponent { 
this: OrderRepositoryComponent =>
  val useCase: UseCase

  class UseCase {
    def doSomething(orderNumber: Int) {
      val order = orderRepository.getOrderBy(orderNumber)
      println("Doing something with " + order)
    }
  }
}

What’s interesting here is this snippet:

this: OrderRepositoryComponent =>

That’s what we call a self-type annotation, and basically it means that this trait has to be mixed-in with an OrderRepositoryComponent trait.

I guess it’s time to wire it all up. In order to regain some common ground, we’ll wire these components together in a registry:

object Registry extends
  UseCaseComponent with
  OrderRepositoryComponent
{
  val orderRepository = new OrderRepository
  val useCase = new UseCase
}

What we’ve gained now, is removing the instantion of dependencies from our concrete implementations, and into a registry object. This could well be your top-level service or the like. Inside of it, we have the complete freedom and flexibility to instantiate our dependencies as we need to.

We also make our dependencies explicit and visible from the entry-point of our code. There is no need for checking Spring XML configuration files, or having your IDE “find all implementations” of OrderRepository. We can see from the start, that orderRepository is instantiated as new OrderRepository. This is even more powerful when you have multiple implementations of OrderRepository, of course.

What’s even cooler, is that we can simply compose different objects to control our dependencies in different scenarios - e.g. for testing. We can now do something like this:

class UseCaseSuite extends TestNGSuite 
  with UseCaseComponent 
  with OrderRepositoryComponent
{
  val orderRepository = mock(classOf[OrderRepository])

  @Test
  def doSomething() = {
    val useCase = new UseCase
    
    useCase.doSomething(5)

    // assert..
  }
}

Here we’ve mocked away our orderRepository, while creating a fresh UseCase for testing. Pretty elegant, pretty neat.

Exploring domains with python

Sun, 22 Dec 2013 18:19:00 +0100

I’m currently working on a Proof of Concept project. But the concept isn’t really finished. This leads to a rather fun path of development: Discovering the concept and exploring its domain(s) at the same time.

The concept I’m prototyping has rather complex business logic and requirements, and we’ve decided to use domain-driven design in developing it. Domain-driven design lets us define clear business goals and mechanisms, while implementing fitting software based on the actual business needs and domains. The product is further broken down into (at the moment) 2 different bounded contexts. I’ll write more about bounded contexts in another post.

I’ve chosen to start coding in the bounded context that contains our primary domain. When prototyping like this, I don’t want to get bugged down by strict infrastructure, limiting frameworks or anything else. I just want to start sketching out my models in actual code. I’ve found python to be a great tool for this kind of work. A dynamic, verbose language with a full-packed toolkit of standard libraries empowers me to get up and running quickly.

###Repositories

A well-known tactical pattern of domain-driven design is the Repository. A repository encapsulates the storage and retrieval of our domain objects. Be it towards a database, event store, web service or frankly anything.

When prototyping, I like to keep the number of dependencies in my project down. This also adheres to one of my rules of good architecture: Good architecture lets you defer concrete decisions. E.g. allowing you to code up your domain without thinking about databases and those kind of things. Repositories serves as a nice seam in our code to isolate the domain from this kind of concerns. Another goal of domain-driven design is also to keep development focused on the model instead of technology.

One of my best friends in the python standard library is pickle. Pickle lets us serialize and deserialize nearly any python object or structure.

By using pickle, an example repository might look like this:

import pickle

class AccountRepository:
  def get(self, account_name):
    return pickle.load(open("account-%s" % account_name, "rb"))

  def store(self, account):
    pickle.dump(open("account-%s" % account_name, "wb"))

Of course, this code could easily be refactored into a pickle-backed generic repository, serving as a quick-to-use building block in our prototype project so we won’t have to worry about storage again anytime soon.

class PickleStorage:
  def __init__(self, path):
    self.path = path

  def open_file(self, filename, mode):
    return open(os.path.join(self.path, filename), mode)

  def get(self, filename):
    with self.open_file(filename, "rb") as f:
        obj = pickle.load(f)
        return obj

  def store(self, obj, filename):
    with self.open_file(filname, "wb") as f:
        pickle.dump(obj, f)

class AccountRepository:
  def __init__(self, storage):
    self.storage = storage

  def get(self, account_name):
    return self.storage.get("account-%s" % account_name)

  def store(self, account):
    self.storage.store(account, "account-%s" % account.name)

Now we’ve simply encapsulated the lifecycle management of our Account aggregate in an AccountRepository that can be replaced when the need arises. Using duck-typing, we can also switch out the storage mechanism very easily when writing tests.

###Summary

This has been a short introduction to Repositories and how we can use them when prototyping in python. I expect to write about other concepts from domain-driven design, and other ways of utilizing python for prototyping, in future posts.

First post!

Sat, 21 Dec 2013 13:45:45 +0100

Recently I decided to start a new blog. I’ve been blogging previously, but not really in a technical context. My previous blog was focused on politics, economics and society. Although I’m still interested in those topics, I feel more like writing up some technical stuff now.

So what am I going to write about? Probably quite a few different things. I’m planning on telling you about my experiences - both previous and current - with differente programming languages, methods, archicture and projects.

Right now I’m working on a Proof of Concept project using Python for prototyping and exploring the domain of the concept. That’ll probably be the first thing to get its own post.

Until then!