[Intro Music]
Hello, and welcome to Making Tech Better – Made Tech’s fortnightly podcast, bringing you content from all over the world on how to improve your software delivery.
My name is Clare Sudbery, my pronouns are she and her, and I am a lead engineer at Made Tech.
Ted Young is an expert on hexagonal architecture, which is something that I’m particularly interested in, because of the way that it really helps you to test your code. So, on Wednesday 12th January 2022 I spoke to Ted. Ted is a long-time Java developer, 26 years. He’s also a trainer and coach. And he helps developers to improve their code with test-driven development and hexagonal architecture, which is what we’ll be talking about.
Clare: Hello, Ted. It’s great to have you here!
Ted: It’s great to be here.
Claire: I’m just gonna leap straight in, and I’m going to ask you: Who in this industry are you inspired by?
Ted: So there’s sort of, I think the usual suspects. I’d say Martin Fowler, probably one of my favourites. He was the one who inspired me to get into extreme programming back in 1999. And the stuff that he’s written has been, over the years, a huge influence.
And someone else who is an influence in an interesting way is Michelle Glauser. So she formed an organisation here in San Francisco in California, called Techtonica. And it’s very much like your typical coding boot camp, but it’s aimed at women who can’t afford it, who don’t have to pay, who gets subsidised by companies. And I worked with her a little bit on some of the stuff and just helping out and volunteering early on. And her forming this organisation to really target people who just would not otherwise have the opportunities, is just really inspiring.
Clare: Fantastic, I love that. So the reason I’ve invited you here is because I know that you know a lot about hexagonal architecture. And hexagonal architecture is actually something that I’m personally really interested in. I think it’s a really interesting topic, and so I just thought it’d be great to get you on to talk about it. I’m going to start with just the really, really simple question: What is hexagonal architecture?
Ted: Yeah, so hexagonal architecture… The first thing a lot of people always ask, what’s special about the shape hexagonal? Six sides, is there anything special? And basically, no, there’s nothing special about the number of sides. The intention of Alistair Coburn, who I would say invented hexagonal architecture back in the early 2000s, was just he wanted to get away from stack boxes that we might see in our architecture diagrams where we vertically stack things. He wanted to get away from that and make something that was different enough from a diagramming standpoint to stand out.
So you have a hexagon. And a hexagon is a closed shape, closed polygon. And what’s important is that there’s an inside and an outside. So in this context, it’s really about: Where do we put our code? How do we organise it? What goes where? And inside of the hexagon is all the stuff that the business cares about. So somebody told us “We want some application that’s gonna solve some problem”. So there’s a domain, and it’s become a really strong link between hexagonal architecture and how well it fits with domain-driven design.
One of the main points of this inside and outside is the idea of separation of concerns. So for me, one of the most important aspects of hexagonal architecture is how it helps us make code testable. I’m all about testability – TDD, unit testing, testing things quickly for test-driven development. You really need that fast feedback. And hexagonal architecture really tells you what to do to make your code testable because I had struggled with testability of code in organisations where you literally could not write a unit test, or what GeePawHill calls a micro test. You could not create an object and write a test against it, and it’s so frustrating. And so I think about it like, the code that I want that’s easily testable is code that runs in memory on a CPU and does nothing else. It doesn’t touch the hardware, doesn’t touch the clock, doesn’t touch the file system, doesn’t touch the network. It’s like it’s running inside of the brain without touching anything in the outside world. Because then we can just instantiate objects and connect them together and write an assertion and it all runs super fast.
Then ultimately, we will have to connect it to the outside world. It’s not very useful to have code that just runs in memory. And so the additional part of hexagonal architecture is this idea of adaptors. So Alistair Cockkburn has kind of gone back and forth in the name of it from hexagonal architecture to ports and adaptors, back to I think hexagonal is now a common way that people talk about it. So there are two important parts:
There’s the adaptors. The adaptors’ job is to interpret and listen and talk to the outside world and figure out how to translate the outside world into things that happen inside of the hexagon. Those dozen different ways of listening to and getting things from the outside world and translating that into basically a command or query against your domain code. And then the domain code does its job, either does something or maybe returns some information, then the adaptor has to translate that and present it to the outside world as appropriate for that adaptor. Like, why did we build this? Somebody asked us to build this. Why? What problem do we think we’re solving? And being able to do that then in isolation from how it interacts with the outside world, being able to do that is so valuable.
There’s this idea which I thought was really interesting, that this core domain is in a sense, inert. It just sits there, it does nothing on its own. Everything that happens is always triggered by some outside event, because otherwise it doesn’t do anything. So things like: What time is it? What day is it? is an external concern. And so instead of writing in the core part of your code, some little piece that wakes up every 3am to run some process, but it’s not told to do so unless it’s triggered by something in the outside (and there would be an adaptor for that). All this then allows you to easily test it, because an adaptor could just be a test framework. And so this ability to drive that core piece of our application through tests, in the same way that’d be driven by an adaptor, is what’s really magical about it. You just plug in tests. If the tests pass, then when you plug in the adaptor, it just works.
Clare: What about ports, because I know that that’s another term that you mentioned briefly, and I know that as well as the domain in the middle we also have the adaptors, but there’s also this concept of ports. Where do they fit in?
Ted: Right. So, one of the important things about this inside and outside is what’s called the direction of dependencies. So what we want is we want this domain to have no dependencies on the outside world. So that means that dependencies must flow inward. So that’s great for incoming things, right? We just have an adaptor, it gets a message, turns around, takes that message, translates it into some call against some code inside the domain.
At some point though, there’s part of our application that needs to fetch information from the outside world, like – Hey, what’s the current currency translation from pounds to US dollars? – because we want to display it in that format. Well, we could hard code that, but that’s not going to be very useful. And so that’s where the domain needs to initiate some kind of request for information or just sending out information. So when the domain wants to talk to the outside world, it can’t talk directly to it. I can’t have my domain code ever reference the database, because that breaks the direction of dependencies. So we do what is commonly known as dependency inversion, which is saying instead of the domain depending on some concrete thing, like storing stuff in a database or concrete socket or network connection to a currency conversion service, we depend on an interface, and that interface is the port.
So for me as an object-oriented developer, using interfaces to sort of provide these points of abstraction is somewhat natural, but the architecture really shining a bright light on that I think is really interesting, that you don’t talk to the concrete thing; you talk to an abstraction.
Clare: Yeah, and then that allows you to implement things like the repository pattern.
Ted: Right.
Clare: So the repository pattern is where you say – I have a repository for my data, and that repository might be a SQL database, or it might be Raven dB. But my domain logic doesn’t have to care.
Ted: Exactly.
Clare: It can just say – You know what, I’m sending data somewhere, and the interface looks exactly the same to me. Whether it’s SQL or Raven dB, and the port is the thing that handles that.
Ted: Exactly. And so what’s interesting is, what if I’m not ready to do all the stuff to set up a database? I don’t have to deal with the schemas. What if the application is changing quickly? I’m in early days, there’s a lot of movement and changing and refactoring and creating new classes and all that kind of stuff. Once you’ve connected to a database, you’ve taken on a whole load that adds friction. And so what’s interesting is – and I do this all the time – is you can create in-memory repositories. And they’re easy because in Java, you just say it’s a HashMap. You associate the ID with the object itself and boom, you know, 50 lines of code you’ve got an in-memory version of that. And that means you can actually not just write test, so that’s great for testing. Another name for that would be a fake, where you can write to it and then read later from it, which is what’s unique about a fake versus a stub, where it’s only hard coded returns, it sort of doesn’t take in information. But phasers are great for tests. But in-memory repositories, you can use and actually work with the application as if it were storing information in a real database. Of course, when the application ends, the data goes away. But that’s good enough for getting this ability to really work with the application as if it were running without yet committing to database and schemas and all that kind of work.
Clare: Fantastic. Okay. So how about we talk a little bit about domain-driven design, because you mentioned that and you talked about how well that goes with hexagonal architecture. So tell me – what is domain-driven design?
Ted: Domain-driven design to me is – Let’s put the domain first, let’s build from the domain. And so, if you have a very trivial application, it’s probably overkill to think of it as domain-driven design. But what we want to focus on is the modelling of the problem. Well, really, it’s modelling of the solution, but they’re often interchangeable. But what we want to think about is, what is the problem we’re trying to solve and how are we going to solve it? And so it used to be an object-oriented analysis and design (and you can tell how old I am by saying those words together!) – It used to be that you’d look for nouns and you know, all these techniques, that’s really not the way we do it. And this whole idea of object-oriented programming. It’s like, let’s represent the real world in our code. No, unless we’re literally writing a simulation that’s simulating the real world, we want to take the concepts from the real world that are important for what we’re going to do. If we’re talking about inventory, we may have representations of them, but they’re not going to be like the real world. They’re gonna be whatever concept we need.
And so domain-driven design really focuses on what is the domain, so what is the language that we use? Folks might have heard of ubiquitous language, right, this idea that – hey, when I say policy, what do I mean? Well, I worked in insurance software, so policy means something very different to me than if somebody is working in security. And a security policy is a very different kind of policy than an insurance policy. So there’s that level of differentiation. But it’s even more so because even though I’m working on the billing system, this team over here is working on the claim system. How they view the perspective of that policy is different. And this is where we get into what are called bounded contexts, where we can say – Look, we can’t create a whole system that does everything. This is the holy grail that we will never reach. This also goes back to Conway’s Law and and limitations of team size. And so, all across these different things, there’s this constant need to break things down into smaller pieces that we as humans can understand them.
So domain-driven design is really about the modelling of this as a process, and to focus on the domain as opposed to focus on things like the database. So instead of focusing on how are we going to store this in a database, that’s actually like an implementation detail. What’s really important is – what are the rules? What are the things that we need to figure out the relationships and how they work together?
What is the language that we need to use so that it’s consistent everywhere? And so that when I say ‘policy’ we know exactly what we mean in this context.
And the rest of it is sort of two levels of things. A lot of developers focus on the tactical patterns, the entities, the aggregates, value objects, which are very important, but there’s also the strategic aspects of how do we have teams work together? And who’s dependent on what? What is that relationship? Are they distant, and so there has to be a bit more formalisation? And so there are those aspects to it, but it’s just really wanting to promote rich conversations between the development team and the people who are asking for this thing to be done.
Clare: Yeah. So actually, just going back a step. I was just really intrigued a minute ago because you talked about problem and solution. You pressed that really quickly, but I really interested in the distinction between those two words and why you chose one over another. But you said that actually, you kind of hinted that they might be interchangeable. Can you explain that a little bit?
Ted: Yeah, I wish I had a very crystal clear explanation. One of the things that I often see in application development and people saying, hey, we want to store and track information. That’s almost solutioning. One of the things I think is really important to do is ask why, what for? And we ask those questions also to raise levels of abstraction, and that’s what we want. A lot of times we’re presented with solutions rather than problems. Like – What do we need it to do? What do you want it for? Why? – rather than – Here, do it.
Clare: That’s really interesting, because that topic has come up a couple of times. And I think one of the ways that it gets expressed, and maybe the context is slightly different, but we quite often talk about the distinction between outputs and outcomes. People will say, you know, I want this particular graph or I want this particular artefact, but the question should be, well, what is the outcome? Why do you want that particular thing? What are you actually trying to achieve?
Ted: Exactly. And as a teacher, I run into this all the time, and I’ve learned my lesson on that. I’m like – That sounds like an odd thing to ask. I can probably help you with that.
But what are you trying to do, really? And I always think of the five Y’s which is not the best way for doing everything. But this idea of almost being a little bit annoying. It’s like – Well, why? And in a very pleasant, Okay, well why? What do you need that for? And especially, I’m a big sort of user interface, I guess enthusiast is maybe a word for it. I care a lot about the user interface, this is why I think a lot about like, yeah, we can do that. But is that going to be what we want the users to do? I feel like we offload a lot of work onto users.
Clare: Yeah. So I wanted to ask you about the difference between hexagonal architecture and clean architecture. And the reason I specifically wanted to ask that was because when I was first introduced to the concept of clean architecture, I already knew about hexagonal architecture. It was introduced at a high level. I thought, well, that’s basically hexagonal architecture, isn’t it? So that’s fine. I know about that, because I know about hexagonal architecture. But then when I saw how people implemented clean architecture, they had very specific ways of doing things. I began to doubt myself a little are they the same thing? Are they basically the same concept, but they just get they tend to get implemented differently; or are they actually not the same thing? So I’d be really interested to know what your answer is to that question.
Ted: Yeah, so I get asked that question too, and besides hexagonal, I hear about ‘clean’ and I hear about ‘onion’. So one of the obvious differences is the shape because if you look at the diagrams, this is hexagonal, this is clean, and onion, certainly that you could tell by the name. It’s all circles. So circles and hexagons, that’s the difference? Well, it actually is a bit more than that, but they are sort of in fundamental agreement. Let’s not just separate concerns, but let’s focus on the stuff in the middle.
The architecture I grew up with, a vertically stacked architecture is what sometimes called the cake architecture. I get layer on top of layer on top of layer on top of layer. And if you look at what’s at the bottom, the database. Well, that must be the most important we build up from there. Right? And so if nothing else – clean, onion, hexagonal – refocus us on what’s important, or at least what we think should be important, which is the domain at the centre. So that’s definitely consistent across all of them. The idea that there is the outside technical infrastructure, physical, real world on the outside; and inside, it’s completely agnostic, ignorant of anything technical. That’s also the same. Where I think there’s some difference is, honestly if nothing else, it goes back to the diagramming. People like to say I’m a visual learner, I like diagrams. And thing is, I’ve studied how people learn. I’ve read enough and researched enough about how people learn. And this whole idea of learning styles is total bunk.
Clare: Yep!
Ted: If you have working vision, you’re a visual learner. We need to teach things according to what the content is. The best way to learn how to play guitar is to visualise the fretboard, but also you need to listen to it. And so diagramming and visualisation of these things are really important. And what I like about the hexagonal diagramming is that it’s very clear that the adaptors are separate from one another. So my adaptor that’s supporting my phone support, that can actually handle text messages versus a web UI – they’re very different. They’re gonna eventually call the same domain code, but how they interact with the outside world is very different. And they’re completely independent from each other. And so that way, this provides some modularisation and separation that really helps when – hey, we don’t want to use this way of interacting with the outside world anymore, so let’s just delete it, and nothing else should change.
So I think that’s where hexagonal for me is different from clean, is this focus on the adaptors being completely separate, and a bit more focus on testing. So one of the things that’s interesting, I’ve been reading a bunch of books that have come out recently on hexagonal, and to me, it’s like, they get to chapter 14, and then they start talking about testing. And for me, it’s like, can we start a chapter one with testing? When I write my book, that’s the way it’s going to start. And so to me this idea of the tests being an adaptor in themselves, I think, is really critical.
[music]
While I’ve got your attention, let me tell you a bit about Made Tech. After 21 years in the industry, I’m quite choosy about who I work for. Made Tech are software delivery experts with high technical standards. We work almost exclusively with the public sector. We have an open-source employee handbook on GitHub, which I love. We have unlimited annual leave. But what I love most about Made Tech is the people. They’ve got such passion for making a difference, and they really care foreach other. Our Twitter handle is Made Tech. That’s M A D E T E C H. We have free books available on our website at https://madetech.com/resources/books. We’re currently recruiting in London, Bristol, South Wales, and the North of England via our Manchester office. If you go to https://madetech.com/careers, you can find more about that.
[music]
Clare: Before the break, we were talking about how hexagonal architecture allows you to create clear separation between different adaptors in your diagrams. It also makes it easy to focus on testing, and provides clarity over the fact that your tests are just another adaptor.
I think the first thing that I read about hexagonal architecture, was on Alistair Cockburn’s site. And there was a diagram which I’ve seen in a couple of places that had colour coding. I think it used yellow, red and blue. And you can see the hexagon, you can see the ports and the adaptors. And there was a very clear analogy with plugs. You know, I know I mean the concept of ports and adaptors, you imagine things plugging into things. And it very much brings to mind the idea of plug and play. So that’s often how I think of it – the idea that you can plug something, and you can get another thing and plug that in, and get a different thing and plug that in. And it will just work because of that separation of concerns.
Ted: Yeah, and it’s funny, so a lot of people talk about especially on the persistence side, it’s like, hey, this gives me the flexibility to swap out databases. And while if it’s a big monolith, it’s probably not going to happen. And I have no problem with monoliths. I love monoliths and I think microservices is overused. On the other hand, if you have a smaller service, dare I say microservice, you might actually want to switch out the database. You might be in a cloud environment and the database you’re using is too expensive and you found a way to use a different one that’s cheaper. So databases everybody likes to focus on, but there’s lots of other services that you connect to from your service. And so being able to switch not just changing code, but even just changing configuration. Change one property and boom, now it’s talking to a completely different service. And I had to change none of the code in my core domain to do that, is really, yeah I love that.
Clare: The obvious use case that I’ve come across recently is I enjoy developing small iOS apps and I have a little puzzle game that I’m developing specifically in Xcode using Swift, which means currently it’s tied to iOS. But I don’t want that to always be the case; I would like to also be able to deploy it to Android. So I’ve written the code in such a way that the logic is completely separate from the UI. And I should be able to adapt it for other devices and other platforms. And the core logic, the core domain will be completely unaffected. It doesn’t care. It just says – here, look, here’s some text, display it somewhere. I don’t care. I don’t care how you do it, just do it!
Ted: Yeah, and that’s kind of the core power of hexagonal architecture. To me hexagonal is really strict. In your core domain, you cannot even use framework. Like there should be no framework at all. It’s like – what, I can’t even have annotations? No, absolutely not! It must be completely free of anything frameworks. What about libraries? Well, that’s tricky, depends, but as long as the direction of dependencies is okay, as far as I’m concerned, you can use libraries in the domain. But framework, since the direction is often from them to you, that is off the table for your core domain. And then you could take that core and throw away all the adaptors and attach completely new ones and the hard work of the domain stuff is done.
Clare: Absolutely. So another thing that I made a note of that I wanted to ask you is if you’re deliberately building a system using hexagonal architecture, do you use the terminology of ports and adaptors? Do the words port or adaptor appear in your code that you’re explicitly saying – this is a port, this is an adaptor?
Ted: Yeah. So generally, in the naming of packages, I will have a package name for my domain called ‘domain’. I will have sort of a parent package for all my adaptors that are called ‘adaptor’. There’s this direction of flow of information through hexagonal and it’s basically left to right. So stuff comes in from the left, triggers things in the domain and if the domain needs to initiate things, it goes out to the right. Alistair originally called these ‘driving and driven’ or ‘primary and secondar’y. I found those terminologies to be confusing and so I just call it ‘inbound and outbound’. Much more clear. And so, the parent adaptor package then is subdivided into these inbound adaptors and these outbound adaptors. And then inside there is a specific concrete one. This one’s the web. This one’s the WebSocket messaging. And then there’s the outbound ones, which is, you know, third party servers or whatever. So that’s where the names come up, because that’s how the application is organised. The classes themselves won’t generally have those names because the ports are just interfaces. So they’re just named as interfaces and they don’t need anything else. And the package name tells it that it’s a port so I will put it in a separate package for ports. So you can say – Oh, these are the sort of the exit points, the outbound ports, and then adaptors in hexagonal architecture aren’t a specific class. It’s not like I have one class that’s an adaptor. I may have a primary class in the adaptor, which is often called a controller but the adaptor is actually the whole package. So they come up in the names of packages but not the classes.
Clare: And one of the things that can be confusing, because the terminology that I’m familiar with is ‘primary and secondary’; You’re using ‘inbound and outbound’ which I agree is much better because it’s so much easier to understand what you’re talking about. But also when I asked you about the difference between adaptors and ports, when you were explaining ports, you were also using this concept that the domain might want to kind of fetch information from the outside world, which also calls to mind the concept of outbound. So that can be confusing, the difference between primary and secondary feels like inbound and outbound, but sometimes the difference between adaptor and port also feels like inbound and outbound.
Ted: Yeah, so there’s a difference between the way I implement hexagonal architecture… and I don’t use ports on the inbound side. Lots of people do, because to me, this is all driven by testing. So I need a port as an interface because of the dependency inversion. I can’t have my core code depend on something concrete, so I need an interface and that’s where the port comes in on the outbound side. On the inbound side, the dependency of direction that I can have the outside code depend on this concrete inbound thing. That’s okay. And so I don’t feel like I need to have an interface there, just have an interface. I don’t need a port there, just to have a port. So for me, ports are always outbound. Now when the domain needs to request information, it’s initiating that, and so to me, that’s still outbound. So to me, any communication to the outside world that is initiated by the domain is, by definition, outbound.
Now, I mentioned domain, but there’s actually two layers inside the hexagon. So generally, people talk about the core domain and the application layer. I don’t like the term ‘application layer’ because it’s like – oh, we should have the application do that. Well, the core domain is part of the application. So it feels weird to talk about that as a separate layer, sometimes referred to as the ‘feature layer’. And this is something that I struggled with for years, literally, trying to figure out. What’s the difference between these two things? I’ve been teaching this stuff for years. It only really clicked within the past six to nine months, it finally clicked that the difference is domain not only doesn’t talk to anything technical, but isn’t even aware that there’s a technical to be known about. Let’s say I’m working on an application where balance has dropped below a certain amount that I need to send out a notification. The domain doesn’t even know that there’s a notification service. It’s not even aware of it. It just says – Hey, something happened! It’s then the application layer that has to say – Oh, as a result of this thing, saying ‘balance too low’ I now need to send a notification through this notification service. Now at that layer, it has the concept of a notification port, but it doesn’t know the concrete implementation. The domain itself has no idea that there is even the existence of the port. That difference and layers is really subtle, but…
So, everybody says – How do I learn this stuff? Well, you could take a training class, that’s great, I offer those, but you’re not going to really learn unless you do it. And unless you engage, and you see – Oh, what do I do? What decision do I make here? Let me try it one way, or let me try and another way, that’s really where you start absorbing and really understanding it.
Clare: The way that I found that helped me to understand it was to always think of ports as interfaces. And it does make sense to me to think that the domain might have an interface. And I think of that as being a contract with the outside world. The domain is saying to the outside world, this is the functionality that I agree to provide. And if I change my implementation, you don’t care. I’ve just told you that this is what you’re going to be able to get from me. And so for instance, your primary adaptor might be your UI, and your UI needs to fetch data to display and it knows that it can go to this endpoint to get this data and it doesn’t care how the domain is going to provide that.
The thing that helped me to understand it was when I thought of it as – Okay, so your primary port, your inbound port is a contract. Your domain is promising to fulfil the terms of that contract, and your outbound port, your secondary port, is an interface that is going to be implemented by your secondary adaptors, your outbound adaptor. So your database for instance, when we were talking about the repository pattern – and at first I found it confusing because the direction of the interfaces and the implementations is going from left to right – so effectively, there’s an interface onto your domain. And then there’s another interface on to your outbound adaptors. Your secondary adaptors are implementing your secondary port but your domain is implementing your primary port. And then you’ve got your primary adaptors, your inbound adaptors, which is like all the stuff at the top in the old model, when you think about layers, the stuff that’s closest to the user.
Ted: Yeah, and I think there’s a danger at least for me, there’s a danger to interpret port always as an interface, because for me, the inbound port, there’s an interface there. All classes have an interface. They don’t have to be the technical interface, like in the Java language, a technical actual interface. They can be a class, but it is an interface because it’s methods that adaptor can call from the inbound direction for the outbound ports because of the pendency direction. They have to be interfaces. And you’re right. I like to think they’re facades, as well as being just interfaces. Often we say, here’s this third party service, whether it’s a database or whether it’s an external information provider or whatever. And we say what is its structure and basically say, well, whatever it does, I’ll just sort of duplicate that and create an interface like know your opportunity at the port is to create a façade. What would you like? What would your domain code like to call? How would it like to be structured? and it’s speaking the language of the domain, because that port is part of the domain and so you get to use that and then leave it to the detail in the adaptor to adapt from your nice facade interface to the ugliness of that third party implementation or API or whatever.
Clare: Brilliant. Okay, so I’m just going to ask you one more question about hexagonal architecture, which is that I happen to know that you’ve been working on a diagramming app, but that’s all I know. And I’m really intrigued. So can you tell me a little bit more about that? That’s specifically focused around hexagonal architecture?
Ted: Yeah. So as I mentioned – to me, the diagramming is so important, which is why I get really frustrated when I see write ups about it that don’t use the diagrams. To me, the diagrams are so helpful to help you visualise what goes where. So one of the things that I struggled with is creating diagrams for this stuff, especially hexagons, is very tedious. And I’m a pointy topped hexagon guy. You know, hexagons, you can either have a flat top or a pointy top. I like pointy tops for various reasons. They’re much more symmetrical left-right.
Clare: Just a minute – Sorry, the mathematician in me is not having that! They’re both symmetrical left-right!
Ted: Well, they’re both symmetrical but what you get is when you divide a flat top in half, you get half of the top side on one side. And I want a clear separation either on the left side or on the right side. I want that clear…
Clare: Okay, I’ll take that!
Ted: So the symmetry is there, okay. But these are hard to draw. So the hexagon is hard enough to draw. And then I generally draw my adaptors as boxes. And to get those boxes aligned means I have to rotate them 30 or 60 degrees. And so it’s been really frustrating to do this using the drawing tool, especially for drawing sequence diagrams. Nobody wants to draw these by hand. Because when you change them, you don’t want to drag and drop and move things around and then have to adjust them, that’s just painful.
Clare: Yes, absolutely.
Ted: And so I’m inspired by tools like plant UML web sequence diagrams. So there you describe it as text, you say the typical – Alice talks to Bob, and then Bob talks to Jane, and then Jane sends back information back to Bob, and then Bob talks to Zulu. And you just described this as text with little dashes and arrows and things like that.
Clare: So it’s basically a diagram as code.
Ted: Exactly.
Clare: And you can also presumably, then use source control. You can track changes.
Ted: Exactly! And because the description is separate from its presentation, you can do things there. You can change its layout, change its look, but for me, I’m much more interested in the concise way of doing it, the easy editing, and some of those other features of merging and collaborating on that.
And so I’m working on creating a tool that will allow me to describe the hexagonal architecture. Here I have, this object comes in to the adaptor, it gets transformed to this other value object that then gets sent into this application layer thing that thenmcalls this thing in the domain, and then domain returns… and so on, and be able tomdescribe that as text and have it display a diagram.
Clare: But it seems to me that if you specifically use a hexagon – the six sided shape – thenmthat works well when you’re talking about the abstract concept of hexagonalmarchitecture, and describing the idea of it. But if you’re modelling a particular actualmsystem, there aren’t necessarily going to be six sides to your hexagon. You might have a nine-sided hexagon – which I know isn’t a thing, I’m deliberately joking – But, if you’re modelling an actual system, it’s not always going to be six, is it?
Ted: Well, I mean, you don’t have to adhere to one adaptor per flat surface. You can say I’m going to divide this flat surface into three and boom, now you’ve got nine available. And honestly, if you’ve got more than nine adaptors on your inbound side,mI think even that is probably too many, depends on the system. But also a lot of times you’re not looking at the entire system using the hexagonal diagram. Often you’re focusing on some of the primary things. Or for the types of diagrams I’m thinking of, I’m focused on a use case. One scenario: What things does it touch? What changes as it goes through these different layers, and what gets called and what does it look like when you faked out a database? What does it look like when you’ve stubbed out an external service and be able to swap these? And eventually, I hire somebody to do sort of a more animation motion graphic kind of thing. Because it’s dynamic, the information is flowing, and how to show that sort of change over time is really interesting to me. But right now, I just want to make it – because my presentations that I use both in presentations and in my training, I’ve got, you know, 60, 70 of these diagrams that I had to create by hand. And now it’s like – Oh, I don’t like the look of this anymore. I want to change you know, it’s like, that’s just gonna be not fun!
Clare: Yeah. I get that! Okay, thank you so much. We are out of time. So I’m going to move on to the questions that I always ask at the end. The first one is just a silly little game that we play really: Can you tell me something about you that’s true, and something about you that’s not true, but don’t tell me which is which?
Ted: Okay, so one thing is I’ve run and completed a full marathon. The other is I sold patented technology that Microsoft uses in their Bing search engine.
Clare: Mmm, okay! So where can people find you, and do you have anything coming up that you would like to plug?
Ted: So I am known as JitterTed on most of the social media. So Twitter is my main place that I hang out and chat. I have my YouTube which is also JitterTed, and you can go to ted.dev – my main site that has my blog, but it’s in great need of fixing up – like all of us! But I got to get with it. So that’s where people can find me. I’m mainly on Twitter, if you want to get ahold of me, just find me on Twitter.
Clare: And why ‘Jitter’?
Ted: So back when I was dating the person who became my wife, she had guinea pigs. And guinea pigs do this thing called popcorning, where they sort of pop, they sort of jump all at once. And we came up with this nickname for them called jitter pig. And so it’s like I was looking for some unique name. I was like – how about Jitter Ted? And that also works well because I like coffee. So it’s a multipurpose name!
Clare: I think I interrupted you, because I also asked you whether you had anything coming up that you would like to plug.
Ted: I have nothing specific coming up. I guess the only thing that’s coming up is all the courses that currently do are live in-person interactive, but I am transforming those into self-paced classes along with learning ensembles added on to really get people into learning, because that’s where the learning happens.
Clare: And then the very last thing to end on a high – What is the best thing that’s happened to you in the last month or so?
Ted: So I was working on a game called JitterTed’s TDD game for a couple years, and I finally released it in December, at least the print and play version. So there’s still a physical version that I’m working on getting manufactured, but after much pushing by fans, it’s like – When are you releasing it? – because I’ve done some play testing a couple of years ago when we could actually be in person with people, and people liked it! And so it’s actually a kind of a fun game and you can buy it, and if you go to ‘TDD.cards’ that’ll lead you to the site. So releasing it was both a big relief and also kind of reinspired me to get it published as a physical game.
Clare: Yeah, that’s exciting! I like that. Fantastic. Well, thank you so much for talking to me.
Ted: Thank you for having me.
Clare: It was a pleasure.
[music]
As always, to help you digest what you’ve just heard, I’m going to attempt to summarise it.
Hexagonal architecture uses the hexagon shape to make us focus on inside and outside. It helps us to think about where to put all the stuff the business cares about the domain logic, and that’s what goes in the middle. Because of this focus on domain, it means that hexagonal architecture fits really well with domain driven design. The key point is testability. What you want to do is separate your domain logic from everything else so that you can easily test it. And hexagonal architecture gives you a way of describing that, as it puts the domain in the middle.
Hexagonal architecture also uses the terminology of adaptors which allow us to listen and talk to the outside world. They translate the outside world into things that happen inside the hexagon, and they allow the outside world to trigger events in the domain. Sometimes a domain needs to request or send information from or to the outside world, and that’s what the ports are for. Ports also allow us to inject our dependencies, also known as dependency inversion, and allow you to switch out different implementations. For instance, enabling what’s known as the repository pattern, which allows you to switch out between different databases. Originally, when Alistair Cockburn came up with the concept of hexagonal architecture, he used the terminology of ‘primary and secondary’. This is where information is flowing from left to right. What you have on the left are the primary adaptors and ports; on the right, are the secondary adaptors and ports. But better words for this are ‘inbound’ on the left and ‘outbound’ on the right. You don’t necessarily need an explicit primary or inbound port. This can be implicit via whatever the interfaces into the domain.
Hexagonal architecture has a lot in common with clean architecture. It has the same idea of having the domain in the middle. The difference is really in the diagramming. The hexagon makes it clear that the adaptors are separate from one another. Also hexagonal architecture has a little bit more focus on testing and making your system testable. Okay, stick around for extra content.
While you’re pondering which of Ted’s answers was true, and which was false, here’s the true answer from Cat Small’s episode on inspirational stories: “The true one is that I biked 90 miles in a day.”
In December 2021 we published an episode on microservices with Sam Newman where we held a prize draw for free copies of Sam’s book “Building Microservices”. Thank you to all the people who entered, and congratulations to Anna, Matthew and Andrew who have all received copies of the book.
Before we go, working in the public sector means that at Made Tech we really care about making a difference. So every other episode in our ‘Making Life Better’ segment, we share suggestions for small things we can do to make the world a better place. I have Alex Herbert here with me, who is a Senior Engineer at Made Tech, and she is going to tell us about a book that she recommends. So Alex, can you tell me what the book is and why you recommend it?
Alex: Absolutely. So, here at Made Tech we take diversity, inclusion and equality seriously. So many people in business have recommended to me the book “Moving Diversity Forward” by Verna Myers, a Harvard-educated former lawyer who is now the president of her own consultancy firm. She has set a consulting firm up based on her own experiences being a black woman trying to break into and indeed working in the legal profession, which is largely dominated by white men. She started her consultancy firm to try to draw on her own experiences and help other people and other companies to increase diversity and inclusion from hiring level to the retention level, which is equally if not more important. She approached it in quite simplified language as well. She equated to being like a dance, which is kind of a good metaphor of explaining concepts to people who have never faced racialized diversity, which I understood as well and I’m tragically white! She writes specifically about race, and specifically the divide between black people and white people. Although she does acknowledge a lot of false understanding in between traditional majorities in the world of business and other underrepresented groups. So she briefly touches on gay people in the legal profession, and how a lot of gay men might remain closeted and hide their sexuality at work in order to still kind of fit in with what they feel is the company culture. She touches on how there are different implicit expectations for people of Asian descent or people of Mexican descent. So there’s kind of a mix but the focus of it is largely based on our own experiences of breaking into a white industry as a black person, or into a very male dominated industry as a woman, and the entire intersectionality of all the big things that converge into very specific challenges that may go unnoticed.
Clare: What would you say was the biggest takeaway that you took from reading the book?
Alex: So honestly, there is such a good amount of information in there. I think that I only previously considered diversity and inclusion, kind of – as long as you get the people in, it’s going to be ok from a hiring point of view. But very early on, she dispels that myth, and shows that retention is just as big of a problem. If your entire leadership team is white men, and they realise that they have a problem by not having enough black people in the company in high paid roles and senior roles, and they push to hire more people in order to increase their diversity ratios. But then, all of a sudden, six months, eight months, twelve months down the line, those black people leave company for that opportunity and the left scratching their heads, not understanding why. And it’s because the company culture that they fostered from the start – believing themselves – Oh, it’s simply just a meritocracy – without fully understanding the issues that people of different minorities face.
Clare: Well, that’s fantastic. Thank you very much for telling us about that.
Alex: You’re very welcome. Can I just say also, if you want to check out some of Verna Myers’ content, she does have some YouTube videos available and Tik Tok. They are well worth listening to.
Clare: Brilliant. We’ll put a link in the description. Thank you.
Working in the public sector means that at Made Tech, we really care about making a difference. For this final, Making Life Better segment, myself and my colleagues will be sharing suggestions for small things we can do to make the world a better place.
And that’s the end of another episode. If you’re enjoying the podcast, please do leave us ratings and reviews because it pushes us up the directories and makes it easier for other people to find us.
I’ve got a few talks coming up. You can see the details on my events page on medium, which is linked to from my Twitter profile. And you can find that at @claresudbery, which is probably not spelled the way that you think. There’s no I in Clare and Sudbery is spelled E R Y at the end, the same as surgery or carvery.
You can find Made Tech on Twitter at M A D E T E C H. Do come and say hello. We’re very interested to hear your feedback and any suggestions you have for any content for future episodes, or just to come and have a chat.
Thank you to Rose, our editor; Gina Cady, our podcast co-ordinator; Fiona Egan, our transcriber; Richard Murray for the music (there’s a link in the description); and the rest of our internal Made Tech team – Kyle Chapman, Jack Harrison, Karsyn Robb and Laura Plaga. Also in the description is a link for subscribing to our newsletter. We publish new episodes every fortnight on Tuesday mornings.
Thank you for listening and goodbye.
[Music Outro]
[Recording Ends]
Back to the episode
