An interview with Michael Plöd
  • April 16th, 2019

Michael Plöd, Author of Hands-on Domain-driven Design - by example

1 H 1 MIN
In this Episode

Michael Plöd is the author of the Leanpub book Hands-on Domain-driven Design - by example: Domain-driven Design practically explained with a massive case study. In this interview, Leanpub co-founder Len Epp talks with Michael about his background and how he got interested in technology, the German hardcore punk scene in the 90s and the fanzine website Michael co-founded at the time, domain-driven design in the enterprise, his book, and at the end, they talk a little bit about his experience as a self-published author.

This interview was recorded on March 26, 2019.

The full audio for the interview is here. You can subscribe to the Frontmatter podcast in iTunes or add the podcast URL directly.

This interview has been edited for conciseness and clarity.


Hands-on Domain-driven Design - by example: Domain-driven Design practically explained with a massive case study by Michael Plöd

Len: Hi, I'm Len Epp from Leanpub, and in this episode of the Frontmatter Podcast, I'll be interviewing Michael Plöd.

Based in Nuremberg, Michael is currently working as a fellow for the technology and software development consulting firm, INNOQ. Michael is an award-winning conference speaker, and he has over 15 years of consulting experience in areas like domain driven design. You can follow him on Twitter @bitboss.

Michael is the author of the Leanpub book Hands-on Domain-driven Design - by example: Domain-driven Design practically explained with a massive case study. In the book, Michael explains domain-driven design, exploring a concept in each chapter from a theoretical level, coupled with a practical example and exercises derived from a sophisticated and comprehensive case study.

In this interview, we're going to talk about Michael's background and career, his professional interests, his book, and at the end, we'll talk a little bit about his experience as a self-published author.

So thank you Michael, for taking some time out from your evening to be on this episode of the Frontmatter Podcast.

Michael: Thank you for having me and thanks for the invitation.

Len: I always like to start these interviews by asking people for their origin story, so I was wondering if you could talk a little bit about where you grew up, and how you became interested in technology?

Michael: I actually grew up in a mid-sized town called Regensburg, which is in Bavaria, in Germany. I basically spent all of my childhood there, went to school there, and I even studied information technology with a business focus in Regensburg. After that, I wanted to leave Regensburg.

So I went to London as a trainee for a bank, and worked there a little bit. Then I went back to Frankfurt and worked there for a bank. But sooner or later I realized that I'm more interested in doing consulting. So I tried a consulting company, and I worked as a consultant in IT on quite a few projects.

My interest in technology, pretty much originated back as a kid. I was always fascinated with computers. A friend of my father's worked at the university, and when we visited him at his office, I always wanted to see the big computers. And back in the day, a data center was basically a huge room, filled with one computer, which probably had a very small amount of the computing size, compared to an iPhone nowadays. I was always totally fascinated by those things.

Sometime after that, my parents got me a Commodore C64, and I was totally blown away by it. I first started off with computer games - what would you do as a young kid growing up? You're fascinated with games and stuff. But sooner or later, I got some magazines and I saw some listings with programs. So I started programming a little bit as a kid. I think that the first thing was a little game that I wrote in BASIC, where you had to answer some questions - just a totally simple quiz. That's how the ball got rolling.

So when I was about to study after school, I had two things I considered. One option was to become a brewing master for beer in Bavaria. And the other one was information technology. So I checked out both things, and I decided to go for IT, because I wasn't so much into chemistry and stuff like that.

So, here I am now as an IT guy. It's a retty typical story, I would say.

Len: Thank you very much for that story. So many people that I interview, because so many Leanpub authors are technical people, have a story about their first encounter with a computer. I've interviewed people from across the decades, and it's always so wonderful to hear about that first experience. And particularly the experience of getting a paper magazine, and using that as your entry into programming.

Before I ask you some questions about that -one of the things I noted from your profiles online, is that you are a fan of heavy metal music.

Michael: Absolutely.

Len: This is a bit of digression. But as I understand it, you founded a music magazine called Allschools?

Michael: Yes..

Len: Can you talk a bit about how that came about?

Michael: The fun thing is, I started it over 20 years ago. I think it's now 22 years ago? I started it with a friend of mine, called Jochen Mader. Jochen has always been an IT guy. We were members of the German hardcore punk scene back in the day. It was a quite interesting time, because many bands, and especially in that area in Germany - many bands started to pop up. There was a lot about veganism, a lot of political stuff. It was a very do it yourself driven scene. Everyone was doing a little bit.

Some folks were starting bands, others started record labels, and others started merchandising companies, or were printing t-shirts or flyers, or something. It was on a total underground, DIY level. And we thought, "Hey, what can we do? Nobody wants us in a band, because we totally suck as musicians." And so we were like, "Hey, we're both technical guys, let's start an online fanzine." Back in the days, there were a lot of print fanzines. And we were like, "Let's start something online."

So we kicked that off. The funny thing is, Jochen is now also a regular conference speaker. He works for a company called Instana, who are very active in the cloud space, with their monitoring and analytics stuff. We're still good friends.

He left the magazine quite a few years ago. But I'm still active as a programmer for it - the old guy in the background - and there is now quite a few folks in their 20s who write articles. I'm happy to provide a platform for them to get started in that area.

Len: It's such a great story. It's the kind of thing we take for granted now, but 22 years ago, having a site like that was an innovation and an achievement.

Michael: Yeah.

Len: And very, very early.

Michael: I think if you look at the German area now, I think we should be one of the oldest ones that are still active right now.

Len: One of the things I really enjoy about doing this podcast, is interviewing authors from all over the world. I get to ask them about some of the things about where they're from. You're the first author from Nuremberg that I've interviewed, and I wanted to ask you a little bit about it. What's the tech and startup scene like there?

Michael: In Nuremberg, there's many bigger corporations. There's many big companies out there, like large enterprises, and stuff like that. And quite a big public sector. There's an agency in Nuremberg which is doing a lot in IT, and some mid-sized companies. And, yes, there are a couple of startups, but I wouldn't consider Nuremberg to be a big startup city or something like that. It's more, I would say, a very classical IT scene there.

At INNOQ, we are running the software architecture Nuremberg meetup, which is doing pretty well. But it's a typical, classical software architecture kind of thing.

Of course, we do modern stuff like microservices, and the current trends. But our audience is mostly folks from those corporations and enterprises.

Len: I'm curious. I used to be an investment banker, I was based in London, and did some work on deals in Germany. So I spent some time a little bit northwest of you in Frankfurt.

And one of the curious features of working with people in big companies in Germany was the constraints compared to other places. Is that true? I mean, you're a consultant, but you work for a big company. Are you sort of forced to sort of leave the office at 5:30, or can you stay longer? I guess I'm asking you - what's typical for someone working in a classical IT company in Germany? Are they regimented like that?

Michael: I think it depends. I am in a very lucky position - my employer is a very freedom-loving company. So I can basically do whatever I want, as long as it's in reason. But when I consult, I have companies like that. Yes, of course you see some constraints, depending - like hardware that they are allowed to use. And of course, there is something like a worker's council that takes a look, if folks work more than 10 hours a day, or something like that.

But I would say, most of the stuff is within good reason. Yes, of course there are companies that are more regulated. Yes, there are some companies that have a very exciting environment, I think. It always depends. Also, especially in the big corporations, and which kind of environment you work in -

For instance, I consulted for an incubator in an insurance company a couple of years ago. They had a totally awesome environment, within this large enterprise - and that was totally great. Of course, other areas are not so great. But that's the life in a corporate enterprise.

I saw it in London as well, I've worked in London, as I said earlier. I have a very strong banking background, as well. The difference is not that huge. Yes, there are nuances where the difference is. But, I wouldn't say that's a huge difference.

Len: And so you moved to London. What prompted that? Was it an easy decision, or did someone pull you there? Was it a place you wanted to go?

Michael: It was part of a training/trainee program that I did at a German bank. The first placement was in London. I heard that, and I thought, "Hey, that's great. I have never been to London before, but I only heard good things." I was in Regensburg for 25 years. Like, "Check this out." I mean, you can't lose with such a decision, you can only win - checking out new places. So I loved London, and I still love the city.

Len: If I can ask specifically, where did you live when you were there, what neighborhood?

Michael: My first apartment was a bank apartment in Westminster. And after that, I moved to Islington. I actually preferred Islington. I was near Angel Station.

Len: I actually lived on City Road, right near Angel Station, for a couple of years, when I was working in the city myself. Being walking distance from the City was a key feature of living in that awesome neighborhood.

Michael: Yeah, absolutely. It's a really good neighborhood over there. And since I love a lot of electro clubs and underground clubs, I always checked out the Electrowerkz, and stuff like that. I was in walking distance, I totally enjoyed that.

Len: I think I remember that place.

Michael: It was a crazy place, that.

Len: What's the view, in that context - I'm always curious, because I got to go to London from Canada relatively easily. I got to study in the UK relatively easily. I imagine that when you went to London, it was relatively easy.

But that might not be the case going forward. I don't want to ask you to generalize to like, "What's the German view of Brexit?" But given that you've had this experience of living in the UK and being able to move and work there easily, what's your view of what's going on there right now?

Michael: I can't talk such a lot about the English folks and their motivation. But my personal view is that this is utter nonsense. I think, the more that people collaborate and they work together, that they see different views, the more they grow from it. I think separation has served no one. I don't know one case in history where it served anyone, I think. The most successful societies have always been the ones that were open to other ideas.

I don't think that this is a good idea, and I think especially people who live in the bigger cities, like London, Manchester and so on - they see the benefits from such a collaboration and stuff. They strongly voted against it. I mean, I wish the British all the best, I really love that country, and I love the folks living there. And I think they can hopefully sort that out in a reasonable way. But it's pretty crazy what's going on right now, from my personal outside perspective of course.

It's their choice. I mean, they have the freedom to do that. It's part of democracy, yeah? You need to accept decisions, even if you don't like them. But let's see, let's hope all of us on the European continent can sort that out in a way that's acceptable. But I think it's sad, it's totally sad. Let's see.

Len: I share the same feelings, particularly as someone who benefited from moving to someone else's country.

I've been sympathetic to the view that people have - so I moved to London, I went to The University of Oxford, I became an investment banker. Not everybody gets to have that kind of experience - like you also moved to London to be a banker. There is a sense, particularly in places where people are economically deprived - they see foreigners coming into the country and making money and getting ahead, and ssee themselves falling behind. And it's very, very easy to think, "Oh, if it only weren't for those people, I'd be better off myself." Whether we agree with that view as a kind of socioeconomic theory, it's very commonsense to see -

Michael: I think it also has to do with a big difference between rich and poor, that we now have - and that's also not a very good thing. I think that needs to be addressed in one way or another. I'm not a big specialist in those things. I often refrain from offering simplified solutions, because reality is always complex - and it should be dealt with by folks who know what they are doing.

Len: On that note, thank you for the opportunity for a good segue.

Speaking of complexity and things that you know what you're doing, you're an expert in domain-driven design, and you've written a book about it. I wanted to ask you a little bit about that. What is domain-driven design?

Michael: Domain-driven design is an approach to develop software that reflects the heart of a business domain. It's a way that we write and we structure our software, that the business domain is the heart of this, so that it reflects - the rules.

For instance, in the investment banking when you do - let's say, some trading. Or you have certain rules for how you want to charge real estate, or something like that, when you do a financing on them.

I would say, domain-driven design has a very holistic approach to that. So it's not only about design patterns, how you write code - it's actually not at all about technologies. It's more about dynamics between various stakeholders.

How do developers and architects talk to domain experts? How can we crunch the knowledge together with them? How can we learn about them? What about the language?

There is a very central thing where you pick a design , which is a shared language that the main experts from the business speak, and also the developers speak. "How do we get there?" There's a couple of techniques, ideas and so on.

Another author, Alberto Brandolini, who published theEventStorming book on Leanpub - he is a total specialist, for instance, in the domain-driven design community, especially for that knowledge crunching.

Len: I've got a few questions about some of these key concepts, including ubiquitous language and things like context maps.

But before we move on, just to sort of drill right down. As Marc Andreessen said years and years ago now, software is eating the world. And so the way software is made, is actually the way our world is made. This is actually one of the themes of our podcast. Fortunately at Leanpub, we get thinkers like you and like Alberto Brandolini, coming up, who are saying, "We need to really think deeply about this."

I know it's part of your everyday world. But to the rest of us, it often seems a bit distant. How is this software really being made? "Can you just like let the computer guys take care of it?" Is something that a lot of people have as an attitude. But actually, the way software is built, the theories around it, are driving the way our world works now.

Given that sort of framing, can you explain what a business domain is? Maybe by giving us an example?

Michael: My book is based on a big case study around financing for retail mortgage loans. So if you buy an apartment or a house for your family, you need a loan from the bank. And one of the business domains, is, for instance, mortgage loan lending. How do you apply for credit, how does the bank charge your application?

Maybe they get a code from a credit agency that has information about your creditworthiness. How do they make the decision to grant the credit? What regulatory requirements do they have to meet, and stuff like that? That is basically a business domain. It's basically a kind of a problem that we want to solve with IT.

I want to grab one of your sentences there. "Let the IT folks do that. Let's give them the thing and let's do it." I think that doesn't work anyway. I think most products in today's world - as you said, software is eating the world - are digital. I don't think many business folks can resort to that attitude, and think they can produce successful products in the future, with that kind of attitude.

I think they have to think in terms of IT products, digital products. In Germany there's this term of digitalisering - making everything digital. I'm not a very big fan of that term, but the general idea is that everyone needs to understand that most of the stuff that we produce nowadays is basically IT.

Len: And particularly, one of the inspirations behind domain-driven design, is the idea of - you have these great graphics about it, kind of Venn diagram, where you try and find an efficient way of having an overlap between the business domain expert, the person who's an expert in mortgage lending, and then the IT team, that actually has to build the product. And part of the inspiration behind domain-driven design is the idea that these people should have some overlapping knowledge and even contact with each other.

Which is something that to an outsider, might sound totally reasonable. But to insiders, it can sometimes seem alien and strange and a big enterprise. Because, for example, there might be-- I forget what the term is, but there's a requirements engineering team or something like that?

Michael: Yes.

Len: That's in between these two groups, and those people wouldn't have a job if they couldn't keep the two groups apart. Or they might see it that way, so things like this that seem, described at a high level, as very commonsense - bu can actually be kind of like an existential crisis within an organization.

Michael: Yes, absolutely. I think the requirements engineering teams, their classic job is - talk to the business folks, and translate that stuff to IT slang. I always refer to the term, "IT slang." That's like the technical blabbering from the IT folks.

I think this leads to a couple of problems, especially if you have a very strong curtain, like an iron curtain between those two parts of an organization. Because sooner or later, the requirements engineering folks will have their own business strategy going forward. And I think they are very helpful, yes. They are necessary. They do a good job and they add a lot of value. But I think there needs to be a direct communication between technical people and domain experts.

Len: And why is it conventional to want to keep the domain experts and the IT people apart?

Michael: There is no really good reason for doing that. I think it's habit in a lot of organizations, that this is happening. It has grown to be convenient for many folks. "Hey, let IT handle that." "Oh, the business people. It's so hard to deal with them. Please write down the requirements." And attitudes like that.

It has worked in a couple of organizations, especially when they didn't need a high pace in terms of new product development, product updates. But nowadays, speed is everything. The ones that move faster are probably the ones that learn faster and that gain a bigger market share.

Len: The question of language is one that came up often - when I was researching for this interview, I know there's this specific concept of ubiquitous language.

I just wanted to bring up one of your great jokes in a talk that you gave, I think, late last year. Where you talk about how, if you've got an image of a room and there's, say, a window, a domain expert in rooms might call it a "window." But then a technical person might call it like a "transparency pane."

Michael: Transparency creation device, or something like that.

Len: And you can just imagine a couch would be a sort of resting device, or something like that.

One of the things that just makes it so hard for people to talk to each other, is that they don't have a shared language. And part of domain-driven design is establishing a shared, ubiquitous language. I was wondering if you could talk a little bit about how you actually accomplish that? How do you get people to talk on the same terms?

Michael: I think it has to do a lot with empathy, actually. And empathy going both ways.

So on the one hand, the IT folks go ahead and toss away all their like graphical UML whatnot tooling that they usually use for modeling or analyzing things. And the business folks go ahead and say, "Okay, let's talk to IT. Let's get the ball rolling, and let's talk."

I think it's a lot about this common ground, so that everyone meets at eye-level. Of course the IT folks are better at abstracting things, structuring things. But it would be very short-sighted to ignore the knowledge from the business folks, and the experience that they have.

Len: I wanted to ask you how you go about establishing a ubiquitous language between the people with the business domain expertise and the IT side of things?

Michael: I think a lot of it has to do with empathy, and empathy going both ways. So on the one hand, we have the domain experts that need to be willing to talk to IT people. On the other hand, we have the IT folks that ditch a lot of their technical slang and the technical tooling. I've witnessed a couple of times that there was a knowledge crunching meeting - and someone was starting up huge an enterprise-scale UML modeling tool.

And the business folks came in, and the IT people said, "Let's draw an activity diagram or a use case diagram." And the business folks were like, "What? Never heard of that." "What, you have never heard about that?" This doesn't work.

There are a couple of techniques now in the domain-driven design community. They all revolve around knowledge crunching. Most of them actually are workshop methods like eventstorming, domain storytelling, example mapping, user story mapping, or impact mapping, or something like that. And they all are inclusive workshops. Everyone can participate in them.

And it's mostly about, not technical workshops; you work a lot with flip charts, with post-its, sticky notes and stuff like that. And they create a common ground for communication.

Yes, there is no formal model coming out of them, but there is a lot of learning happening in them. And this learning, this exploration then feeds into a common and a shared language. Which is then the base for a domain model, which is represented in code and documentation and graphics and stuff like that.

Len: You mentioned event storming. I'm not sure I understand exactly how that works. But, I should. It sort of comes from brainstorming, right? And the idea is that you're looking at a past event, and kind of breaking down what happened, and what you can do to improve things going forward.?

Michael: Exactly. Lets say you want to create a product or you want to file a car claim for car insurance over a smartphone. Everyone in the room - you want to explore that business domain, so everyone in the room knows that the last thing that happens in this is that someone has filed the complaint successfully. From there, you can move along, "Hey, what do we do we need for a successful complaint?" "Oh, someone must have uploaded a photo. They need to upload the police report, and they need to provide insurance number of the counter party" - and things like that.

You explore that, and you put those events on a modeling space, which is a huge roll of paper on a wall. You start exploring things based on stuff that happened. That's a totally simple concept, and it often ignites a lot of discussion, and also exploration. "Oh, I never thought about that special case like this." And, "Hey, that's a very interesting insight there, we never saw that." It's a really efficient way of crunching down knowledge about business rules and domains and problems.

Len: You've got a really interesting example of that, that you talk about in this talk I referenced earlier that I saw on YouTube, where, if you give the people whose goal is to convert people, control of what a sign-up form looks like, it'll be really simple, because they'll want to ask as few things as you can. It will be as low-touch as possible, to get people through.

But if you ask - particularly in the institutions that it sounds like you've done a lot of work with, like financial institutions - the risk guys, if they could make that form - that form would be 100 pages long.

Michael: 10 pages, yeah.

Len: And is it in discussions like this, where you bring those two groups together, that people can finally see, "Oh, now I understand why the requirements have been coming down to me this way, or why there's - "

Michael: That's an option, yes. It's a lot about power dynamics in organizations. So, who can have an influence on whom? Who can denote the application form is not just five fields which are totally optimized for conversion rates? But that it's actually 40 fields that are driven by regulatory requirements and the risk demands, in order to drive the credit risk of the bank down?

Len: That reminds me actually. So I wanted to ask you about context maps. Because I think people coming to something like this from an IT perspective. or from a sort of stereotypical IT perspective, might not appreciate actually the complexity that a context map is meant to capture.

You just reminded me of something, I believe it was Gregor Hohpe, who wrote about riding the elevator.

I don't know if it was him, because I interviewed him for this podcast, and there was someone else I interviewed who was also a chief software architect, for a giant financial institution. But they talked about how somebody's got to be able to be Geordi La Forge, and have that role where they can understand what's going on in engineering, but they've got to be able to ride the elevator to go talk to Captain Picard, and actually communicate to him what's important, and priorities and things like that.

I was wondering if you could talk a little bit about how you would - in a practical sense - go about creating a context map that includes the politics, like you're just bringing up?

Who's influential? If you're undergoing the exercise of creating a context map in domain-driven design, do you actually like have an org chart and draw connections between people and areas of influence, and things like that?

Michael: I usually don't address that from an org chart perspective. Well, me personally. Other folks might do that.

I think it depends on what your starting point is. One starting point - and this is a very classical domain term, this is something that's also part of the existing literature - is that you map an existing system or an existing application landscape with this. Then I obviously look at the stakeholders that are around on the software. I look at the integration between teams and systems. And then I pick the folks whom I want to talk to.

I personally think that you can also use the context map in a greenfield approach, when you want to create something new. Who can raise requirements? Or who do we want to just tell, "Hey, you just take what you get, and that must be sufficient for your product. You can't raise any, any bigger requirements, because we want to be able to move fast. And if we have an endless governance going around, we will have a perfect governance, but we will be slow." That's a typical "it depends" kind of thing.

I rarely consult org charts, but they can be a valuable thing. Maybe I'm doing it wrong by not consulting them. I don't know? But, I think those power dynamics are something that are especially interesting, if I take Gregor's amazing analogy with the elevator - which I totally like. They are very interesting for the upper levels of the organization and of the skyscraper that he's talking about.

I think Gregor talked about how, if you're able to make the folks in the penthouse and the upper floors interested in some details from the engine room, from the machine room - then you're doing a good job as an architect. I think that's his quote, as far as I know.

Len: And what is domain storytelling? I found that concept really fascinating.

Michael: Domain storytelling is also a knowledge-crunching technique, which revolves around sentences - subject, predicate, object. An applicant fills out a loan application form. If you draw those sentences in a pictographic language, in comparison to event storming, domain storytelling - it's forward-oriented. It's not backward oriented with the events in the past tense, it's mostly forward-oriented in the present tense.

Someone hands in something. Someone files a report or something like that. And with the pictographic language, you visualize stories that are happening in a business domain. This is a very helpful thing. I very often actually combine event story and domain storytelling together. I start off with event storming - and after that, the knowledge that has been gathered in the two or four or six hours of the workshop. I consolidate that with domain storytelling, so that everyone has a visualization of what we have just discussed. It's a very interesting thing, coming very strongly from the German domain-driven design community. from [?] a company called "WPS." I think that's a very interesting concept, and I really like working with that a lot.

Len: One concept that I confess ultimately alluded me when I was researching for this, was the bounded context.

I was wondering if you could talk a little bit about that? In the style of your book, from a sort of theoretical level - and then with a practical example of what a bounded context is.

Michael: I think if the bounded context wouldn't exist - I wouldn't have my book right now, and we wouldn't be talking. I think actually, domain-driven design is a really old thing. It's 15 years old now. So it's a very, very old theory in the IT space - which is quite rare, because it's a very fast-paced environment. The bounded context led to domain-driven design being very popular nowadays. Because one trend in IT nowadays are microservices, which are smaller, independent systems.

A team can design it, they can develop it, they can roll it out to production. And that's a very strong trend in IT architecture nowadays. A lot of the folks from the microservices community often refer to the bounded context from domain-during design, with regards to the question, "How do we cut those micro ervices? How do we design them? What's their granularity? What's their size?" A rough rule of thumb is - one bounded context should be one microservice. Basically the bounded context is a decentralization of a domain model.

Back in the day - so 15 years ago, 20 years ago, even 10 years ago - we built very large, very big, very clunky systems. They revolved around a very big central domain model. That had its advantages. It was very consistent. There was not a lot of repetition. "Reuse, don't repeat yourself." Those were the principles that drove those things. Those are the advantages. But the disadvantage is, it makes you slow, because when you change something in the big central thing, everyone else needs to change as well. So you have a lot of coordinated releases.

By breaking down this big domain model into smaller pieces that are highly specialized for certain business capabilities - you decentralize your domain model, basically. And this is what the bounded context is about. The bounded context is, in one sentence - the boundary around the meaning of a model, and the boundary around the ubiquitous language.

So the ubiquitous language is mostly valid. It's a linguistic boundary. It's valid in one bounded context. And this is the key driver for many modern IT trends, such as self-contained systems, microservices and things like that. That's a key driver for the popularity of domain-driven design, all this. And also, the organizational aspects of course, that go hand in hand with it.

Len: Just to think about, if I was like given the task, "Go define a bounded context," would that, for example, be - like, let's say we were doing someone submitting a mortgage application. Would you define a bounded context around say, getting the credit score? And would that be one kind of bounded context, and then another one be the risk assessment?

Michael: What I think is - one bounded context is obviously filling out the form, yeah, because this is a business capability that revolves around many - let's say, e-commerce metrics, such as conversion rates. That's basically a sales funnel - when do they leave the checkout? Stuff like that. It's extremely driven at the consumer. It needs to be blazing fast, it needs to have the best UX. And it's basically - the key domain model in there is the loan application form.

And another thing is, then, the scoring of the whole application. You have a real estate assessment going in. There may be a code from a credit agency about the creditworthiness of the applicants. And there are a couple of rules in there - the arrive points that define some knockout criteria, such as, let's say, the monthly surplus of the household is negative, and no one would grant a credit for such a situation, obviously. And this is a totally different business capability. I would encapsulate that into its own bounded context. Because it lives by its own rules. It has a very sophisticated, very risk driven and not e-commerce driven model.

Len: So I think I'm starting to understand a little bit better. for example, if you're in a team that's working on a product, maybe even a huge one - and you define these bounded contexts, would you then have individual persons or little internal teams go off and work within a bounded context themselves?

Michael: Yes.

Len: So once these bounded contexts have been defined, when people know what they're working on, and they know how it fits in with the other things that other people are working -

Michael: Yeah. I'm very well aware that the real world is not always ideal. But the ideal setting would be - you have one team which is responsible for one bounded context. Because if one team would share two bounded contexts, the team always speaks the same language. So they would grow together from a linguistic perspective.

Len: Oh yeah, that's really interesting.

Michael: Yeah, if you have two teams sitting on one bounded context - this bounded context would drift apart in terms of the language. Those are things you should keep in mind when you do those cuts, I think. You need to consult a couple - or you need to look at it from different perspectives. Like organizational perspectives, quality criteria, domain models, processes and stuff like that.

Len: I think I might have mentioned this in a recent episode. I don't come from a programming background, and one of the interesting experiences I've had, being part of Leanpub is seeing the way terms can become conflated. There's one particular term that we have in Leanpub that has a very specific meaning in our code, but is a normal English word, that also refers to something that we present people with that they can use on Leanpub.

And those two things can actually become confused. In a sense, it kind of leaks out from the programming side into the user side - the use of this term in a way that's very confusing to users. Because it doesn't mean to a user, what it means to someone coding in the Leanpub code base. And so, if I'm sort of trying to communicate to the team, something that's coming from users, using the same term, they often get derailed, because they're like, "Oh you don't understand, in the code it means this."

And it's like, "No, I perfectly understand that in the code it means that. But I'm telling you that the same word also has this other meaning." I mean, obviously I make my mistakes in in interpretation as well. Because there's this inherent problem with the conflation of terms.

S what you said about how, of the same team is working on two bounded contexts at the same time, their language will actually end up being confused potentially, because they are themselves conflating different activities in their own work.

Just before I move onto the next part of the interview, you mentioned there's no such thing as an ideal world. That reminded me of this delightful phrase about programming, that I think it might be from the same friend you mentioned earlier - which that a programmer should be like a werewolf, afraid of silver bullets.

Michael: Yeah, that's a quote from Jochen Mader, who founded the music magazine with me. He wrote that on Twitter, and I really like that attitude, because there are no silver bullets. It's all trade-offs - never become a blind guru for something. It doesn't make sense. Always find suitable solutions that help you and your customers. You're not getting paid for applying everything blindly, for instance, a domain-driven design book or some other programming book. You're paid to solve problems, and that should be your priority. I always use that term as a disclaimer in every single one of my conference talks. That nothing I'm telling the folks is a silver bullet.

Len: I think it's such a great thing. It works from all sorts of perspectives, including. I guess one might say, from the stereotypical C-suite perspective, where it's kind of like - I brought this up earlier, and you mentioned it too - but why can't the computer guys just solve that problem and tie it off with a little bow and make it go away?

It's because the world doesn't work like that. It just doesn't.

Moving onto the next part of the interview, I wanted to ask you about your book, and the process of being an author. Why did you choose to write on Leanpub?

Michael: It goes back to the music background, to a certain degree. I basically grew up in a very do-it-yourself driven community as a kid, and this is something that I still value a lot. By publishing or by choosing self-publishing, I can work on my own rules. I can write the book the way that I want it. I can adjust the schedule the way that I want it. And, so basically - it helped me really well.

Last year, I wasn't so much into writing and if I'm very honest, I prefer doing conference talks over writing, because I don't consider myself to be the best writer around. And so I always need to push myself to writing, and the working mode, with self-publishing, really helped me.

At the end of the year, I actually had my stuff together, and I knew what I really wanted this book to be. It went totally fast after that. Basically the self-publishing thing helped me a lot with my way of working.

On the other hand, I also have to say, I wrote a very specialized book. My book is not meant to be a bestseller which is standing in any airport or any big bookstore or something like that. So if I would go to a classic publishing company, it would be sold online anyways.

And so I thought that this is basically a very modern and a very good way to publish nowadays.

And also from a royalties perspective, it is absolutely attractive, I must say. I'm not writing the book for the royalties, to be honest. It's more a thing that I thought, "I need to have a book out." And it's a topic I'm passionate about, but on the other hand - when you as an author get paid a fair deal, and you can dynamically adjust the pricing the way you want it, you can release it the way you want it, you don't have to discuss your marketing or anything with folks from a big company. That's the way of working that I just prefer.

Len: And you're publishing your book in stages, which is really interesting. You've projected them out very explicitly, including the fact that you're going to be raising your prices over time.

Michael: Yes.

Len: Did you come up with that model on your own? Did you borrow it from somewhere else?

Michael: There was a lot of, I think, logical thinking. I put myself into a reader or a customer perspective there, with regards to that, first of all. And also Jurgen Appelo, who's a well-known author around management stuff. He once wrote a blog why he's not publishing on Leanpub, or something like that, because he doesn't believe that people read incomplete books. And I thought, "Jurgen has a certain point here. I wouldn't want to read a chapter which is in itself, incomplete, and I need to re-read it again and again and again in order to get the updates." So from that perspective, I thought, "Yeah, that's totally valid from a customer perspective, from a reader perspective."

I chose to publish complete chapters that are edited, that are spell-checked, and that are content-complete - and were only some smaller refinements or something like that come in. Like a typo that I saw, or some smaller adjustments only.

My approach to that is, if you buy the book now, and I have a traffic accident and I die tomorrow - you would still have something that is worth the price and that is consistent as a product.

And when I do the next release, it contains more. But it's always a consistent product that I am releasing.

The more the product grows, the more expensive it gets. I value the readers that stepped in early, and that put their trust in me at an early stage. So they get it cheaper. The others that follow after that, they have to pay a little bit more. But I think with the variable pricing on Leanpub, you still have a very fair choice.

Len: Just to explain to people listening who might have not quite caught that. One of the features of buying a Leanpub book is that you get all the future updates for free, so when we talk about the price going up over time as chapters are added, that doesn't mean that you have to pay more for the new chapters.

What Michael's saying is that - and this is actually something that quite a few Leanpub authors have done - you reward someone for being an early adopter of your book by having the price be lower when you first publish it. And then they get all the future chapters for free.

But when the book is complete, then if someone's buying it for the first time, the price might be higher for them than it would have been if they'd bought it earlier on in the process.

With respect to what you're talking about, about publishing incomplete chapters - that's a very good point, and it's something that Leanpub authors tend to not do.

They more or less adopt the same approach that you do. Which is like - after you've got enough complete chapters, publish your first version of your book. And then when you publish new versions, aside from typo corrections and stuff like that - I mean, you can publish 100 new versions of a Leanpub book in a day without bothering anybody, just sort of in the background doing the gardening or whatever.

But when you do a new release, a sort of formal release - that's when you've added like one or more new complete chapters - when you're a reader, when you want to get on board, is more or less contingent on some combination of your taste and your needs.

For example, if your boss has given you some task and you really need to learn something new - if a book is 30% complete, you're like, "Bring it on. I want it right now. I don't want to wait for this random author's random publishing schedule, until it's 100% complete. I want as much information as I can get right now. People like that are happy to jump on board early on in the process.

My second last question is - is interacting with readers important to you? Is that something that you've been doing a lot? With people emailing you with typo suggestions and things like that?

Michael: I didn't get a lot of feedback in terms of typos. But I actually built up an audience throughout the last one and a half years, very proactively. I think I had a very high number of readers who registered on Leanpub, who said they would buy the book. I started advertising for the book over a year ago. I worked towards building up an audience, and I'm very interactive with the biggest part of my audience on Twitter. Actually, today it's probably my most important channel for the interaction. And some folks write emails, others drop me a tweet.

That's the way I work, and I'm always happy for feedback. No book in this world is perfect. No author is perfect. We all have our very own perspective. I'm always curious in hearing other perspectives. Maybe I didn't see something or learn something though my consulting so far, but some other person has. It's something that I'm always very interested in.

Len: My last question, and the one I usually use to close out the podcast is, if there was one thing we could build for you, or one thing we could fix for you on Leanpub - what would you ask us to do?

Michael: Since I'm currently on the very old contract, and I signed up before the subscription thing - the templates for printing are kind of limited. But I think there is a solution for that. Other than that, I think tracking where sales are coming from, that's something I would be very interested in.

I posted a question on that in the forum a couple of days ago. So when you run AdWords campaigns, when you buy a slot on the shelf - how do you measure that? I think you can't see that right now. That would be very interesting from a marketing perspective - how, where you spend your marketing money for the books.

In terms of editing with the Markdown software, I'm totally happy. But I'm not doing any crazy stuff there. For me personally, it totally works out. But the tracking of purchases, where they are coming from - how you steer your marketing, that's something I would be very interested to see more sophisticated features.

Len: Thank you very much for that suggestion.

Michael: For instance, adding Google tag manager tags to successful checkout - when you run an AdWords campaigns. For the tag manager of Google, when you write an AdWords campaign - you could inject a little snippet to the checkout page, so that you see, "This purchase came from an ad."

Len: Right.

Michael: Or something like that. That purchase came from the Shelf. I didn't buy a Shelf spot yet, because my book is not complete yet - and I may reserve that at a later stage. But I will be very interested in seeing, is that a successful measure for me, or is it not? Or are Google Ads a good investment? Or is the Shelf better? I mean, everything is possible.

Len: Thanks very much for that. We've had a couple of other requests along those lines recently. And for anyone listening - if you're a Google Analytics expert, please go on the Leanpub Authors Forum and answer Michael's question. Updating Google Analytics is something that is on our plan of things to do. And improving analytics generally, and just sort of transparency. Because there's all kinds of like hardnosed reasons to do that.

Being a self-published author, you're running a business, you've got a product. But also, there's something around motivation that everyone knows analytics helps with as well, right? And there's simple curiosity and engagement, and knowing where to put your attention. Or, knowing about new avenues for attention is something that we want to have - we do want Leanpub to be more of an environment with things like that going on in it, that help you basically reach more readers and sell more books.

Well, thank you very much Michael, for taking the time to do this interview and for using Leanpub as the platform for your book. Best of luck, it's been a success so far, and I'm sure it will be going forward.

Michael: That exceeded all my expectations. Thank you very much for having me.

Len: Thanks.

And thanks as always to all of you for listening to this episode of the Frontmatter podcast. I hope you enjoyed it. If you like what you heard, please subscribe to us in iTunes, if you haven't done so already - and leave a review, it really does help. And if you'd like to become a Leanpub author yourself - either writing a book or creating a course, please go to Thanks.

Podcast info & credits
  • Published on April 16th, 2019
  • Interview by Len Epp on March 26th, 2019
  • Transcribed by Alys McDonough