I was just telling Tim here how excited I am about this talk. I love this project. It's a project I've always said is one of the projects that I feel I've been waiting for for 10 years, and I just discovered it, and it's amazing. So, I'm super excited to hear about its use in the wild, in a real case. So, Tim, please take it away. Oh, thanks very much. It's actually a perfect handover to what I was going to say, because what I want to start with is that I think there are lots of... there's a large body of work at the moment from people like Oliver and Kora who've done architectural deep dives on Spring Modulith. My session is more about when we started working with Spring Modulith. There weren't really people talking about it yet, so it's kind of in some ways our blooper reel of, Hey, these are the mistakes that we made. Kind of go forth, make your own mistakes, don't repeat our mistakes. So, who am I? I'm Tim. I'm an

engineering lead at km. The only reason that that is relevant in any way, mean or form, is that means I have hierarchical responsibilities, which means that I occasionally get to go walk past a pull request. But for the most part, I lead it to the rest of the engineering team to provide a bit of context. We are the IT partner to security services within km. What they do is secure km operations from ground, so our access cards, all the way to cybersecurity, and maybe some things in between, which are maybe a little bit less obvious. And that's kind of where we're going to dive into in this session, is the work we do for the intelligence team. And in a sentence, what they do is on-ground and in-security assessments. So what does that mean? So a couple of examples here. Should we even fly? Is the airspace safe? Are we flying over a war zone? Are we flying between two countries that are at war? When we land in a station, is that station safe? Once we're

In the station, we need to also look at it and say, can we get our crew to a hotel? Once they're at a hotel, we need to do an assessment and go, are the crew allowed to leave? Are they allowed to leave by themselves? There's a whole chain of operations, and this is just one part of that chain. Something else that happens out there in the world: protests. Protests happen on a daily basis. Singularly, protests aren't of interest normally. What would happen is we would look at a protest, go, that's not particularly relevant. Obviously, if there is a trend of protests, we look at that and go, maybe we need to do an assessment on where we're flying to, kind of upgrade this. But just to give an example, if there is a protest and we have a specific location, we might flag that one and go, we need to look at this because that's right next to one of our crew hotels. That doesn't automatically mean that we're going to stop people staying at that hotel. We then just need to have

an assessment and go well. What country are we in? What is the reality going on there? Do we think this has a chance ATT turning violent? We have to do all of this, and we have to assess it and just kind of work out is a security. What is the security assessment? Is it low risk? Is it high risk? How do we proceed just a moment uh for me so to speak about the Intelligence Officers who do this type of work. Um when they look at look at these events that are happening all around the World. They really have to put on their km glasses. They have to look and go how does this affect what we are doing with KM. Um so they really have to frame those things and make sure that they understand what the relevance is to km. Um and I also have this mental model of these guys just kind of plugged into the internet reading as much news as they can. And I have this kind of this feeling that that' be really great in a pub quiz for current affairs type stuff.

not so sold on how good their knowledge on popular music and things like that would be though. So how can we help these guys? Um, there's a lot of mundane things that they do that we just want to see if we can automate away. We don't have any intention to try to replace intelligence officers. There are way too many contexts that go on in the world for us to even be considering that. It's really, there are a lot of reports that they need to do on a daily basis um to just kind of make sure that our operations are safe. So really for us, if we can work out just 5-10% little increments to their process, that's great. The other thing is, as I said, it's very context-driven, the work that they do. So how much of a framework can we provide them to just be that little bit more effective in their work? Um, and we are slowly making some headway there. Uh, one of the intelligence analysts had a complaint the other day, and they said the security officers are

now getting through their work much more efficiently, which means I now have more work on my plate, so I'm quite happy with that type of complaint, to be honest. So, the slides up to here were kind of just setting the context for why we are talking about Modulith. When I started working at KM about 18 months ago, my boss said to me, Hey, we have some projects that we would like you to look after. Most of them we think are going okay, but there's this one project, which is a rewrite of a legacy project, and we're just getting signals that things are not going well there. So, I spent about a month, two months working with the team, having a look, just kind of finding my feet a bit, went back to my boss, and I said to him, I have good news, I have bad news. The bad news, the sorry, the good news is that you were right. The bad news is you didn't know how right you were. I don't think this

codebase is something that we can actually save. I think we have to start from scratch. Long conversation with my boss, who fortunately is fairly technical, and came to the same conclusion. We can't do anything with this. We actually have to just rewrite this. That's an easier conversation than going to your business, who's now just paid for two years of development, and said going to them and say like, Uh, sorry guys, we now have to start from scratch again because none of these best practices were put in place. So, they weren't particularly happy with that, but at the end of the day, they understood that, Well, this is something that we need to do. So, what did we do? We tell that big lie that all software developers do. We promise we'll be better than the guys that were before for us, but we don't. We do this, and it's never from a malicious perspective. It's always from that insane confidence that software engineers have that we were better than the guy before us, like, We can do it better. So, how did we go about doing

that well. I mean, you just write code that isn't bad, right? Or at least you do all of the put all of the best practices in place to make writing code, make writing bad code hard. Um, so the default standard for us with Spring Boot. I really wanted to go Kotlin, but the rest of the development team was more familiar with Java, so that was kind of the route we went. Kotlin because we wanted to do automated releases and Java for Google Java format because we didn't want to argue about back shed about formatting. So, Cloud and the quality gates that it provided were hugely beneficial for us because one of the things that happened with the previous code base was that the team kind of got into this death spiral of pressure, and they could never really escape from it. So, Dev team, the business analysts, everybody just kind of got into this thing of being under pressure because the development work was so unpredictable. So, we really needed to have a conversation with the entire

team and go. How do we want to be perceived, and can we? How do we want to be perceived externally, and how do we want to perceive ourselves? Because we can put all of the best tooling in place, but if we don't stop ourselves internally and go, That code that we're committing is just not up to standard, then, you know, we're never going to make any success. But these are all the standard things that everybody should be doing. There's nothing unusual or nothing really that goes back to that big promise about governance that we made to business around about this time. Modulith went GA, and there was a statement in their release notes that said, Supports the verification of such modular arrangements. For me, this is a hugely important thing because, as engineers, we all want to use architectures, be it the onion architecture, layer architecture, hexagonal architecture, whichever. We all want to use some kind of architecture, but when we actually try and apply that architecture, when that architecture meets the code, there's always that

little nuance in our code B that we don't know how to do, so we can get to a point where we actually go look at this and go, We can, we are applying this architecture, and now we are saying that you don't conform to that. Your build is failing. That is a huge, huge key for what we were trying to get at. I'm just going to go through the standard example from the modu website, just for people who may not be intimately familiar. So, we have here two modules: we have the inventory module and the order module. The inventory module uses the really standard Java access modifiers. So, Inventory management is public; that internal class uses the default access modifier. That means it's not accessible outside of the inventory module, but this is pretty standard Java stuff at this point. The order package is kind of getting closer to what we think of as a more complex example. So, at the root folder, we've got aut management, which would be our API level. The interesting thing here is that it doesn't matter what this order

internal class. What its access modifier is, it can be public, but because it is an internal or a subpackage moduli, will just fail when you try to access it. It just will say, No, that's not part of our standard definition. You're not allowed to do this, which is great because, like, that's how we don't write bad code maliciously. Well, that's this is the wrong conference for that. Um, it shouldn't be. It's never an intentional thing. Somebody normally links to something unintentionally, and this stops that unintentional moment from happening. One of the things that came up when we first started using modulith was people saying, But we've already solved this problem. You know, if I use Gradle or if I use Maven, I can take those modules, and I can do a multimodule project, and then I can just, you know, I can keep things segregated into my layers that way. And yes, you can do that, but it, I mean, it does feel like an abuse of your bold system to try to use it to apply

architectural constraints. Other thing I would say is that that internal system that we talked about, or that internal package, that would not, you don't get that check by doing this. The modu of project comes with some really standard defaults. You know, the root layer of your module is the API of the Expos exposed layer. Everything underneath it is internal and not exposed. That doesn't mean you can't imply something like the lay architecture to it, but it just means that you now need to add some extra annotations. So, if you wanted to do that approach, you would have these named interface annotations which will then be applied on the package info class, package, yeah, package info class. And those would allow you to do that type of stuff. Although I do feel that the moment you start going down that road, you kind of, you take the road that we took, which was we kind of started bike shedding on architecture. Because once you start looking at moduli, you have this possibility of diving really deeply down this hole. So, there's a great project.

called J molecules, which you can actually start using to say, I want to do layout architecture, annotate your classes or your package info files, and you can really, really strictly say where classes should be, where what a module should be, and you can have great arguments, which is what we did for about two months, was trying to decide how this perfect architecture for our application should be. What I would say is until you actually understand what modulith is trying to do, that you stick with the default, because once you start going down this thing, you can just go into a rabbit hole, which is what we ended up doing. So, this is an example from our code base. What this is really trying to do is it's a feature flagging. It's feature flagging, so there are two fields in a database table, the key and the value. The value is Boolean, and all we're trying to see is, is it enabled or disabled? If you have a mental model of what that looks like and you look at the architecture that we came up

with here I think you can agree that's an overkill because we came up with an architecture, and we decided this should be applied to everything, but is that really necessary? If you're doing something like feature flagging, do we need something like this? I'd argue that you don't. We could have even this for me is fairly conservative because we still have our DTO, we still have our converters. That would be much better in my opinion, and that would have been much more pragmatic. We are still using modulith here because it, uh, we still using modulith. The other things are all internal. We're only exposing two classes. Why not, um, and just because we like to structure things into packages. Majority of people would do something like this. I would as well probably, but why not? So again, this is one of those moments where we really dived in without understanding modulus, and I think that conceptually the idea here is great because we had our providers, and we really wanted to make sure, like, even within that provider that the

client and service modules would only interact with each other via the APIs. I think conceptually that's a good idea. The problem was, or is, that Modulith doesn't support nested modules. So then we kind of were going on our own way and running into our own little problems with Modulith because we were trying to break our own, we were trying to make our own path. We probably should have just compromised and done something a little bit simpler, which wouldn't have been as kind of aesthetic as we wanted it to be, but would have still served the same purpose. Having said that, I now see in Spring Modu 1.3 they do provide, they do support nested modules. So we could kind of get closer to what we originally came up with. Taking a step back from Modulith for a moment, one of the things that I thought was really important in this journey because adopting Moduli was just part of the equation. The other part was how do we make sure that the team is all on the

same page. Um, I didn't really speak about it much, but you sure saw the map that I showed earlier. Our team was distributed. We have developers in, I think it was five different countries, um, from a developing team of about five or six people. So, nobody was really in the same place. Um, one of the things that really pushed us towards adopting o adrs was that we wanted to go towards continuous releases. And one of the things that you want to do when you're going towards continuous releases is have those, uh, semantic release notes. And we wanted to do that using kitland. One of the developers came up to me and he said, Yeah, hey, he has this pull request. Um, it means that we can use, we can go towards, we can use semantic releases and kind of move towards those automatic automated releases that we wanted. I looked at it and I was like, Yep, absolutely. Let's do that. We committed that, we pushed those changes, merged them in, and then developers buold started breaking. That was hand up. Yep, we shouldn't have done.

that because I mean if you haven't used kodin before, it's not particularly nice. It just, you're trying to push your change because we use pre-commit hooks as well, trying to push your change, and all of a sudden, your commit breaks. What's commit? I don't understand what's going on. So that was one of those moments for us where we were, we looked at it, and we were like, okay, that was a mistake. We really need to record what we are doing as a team and kind of make sure that everybody's on the same page before we proceed. As I said earlier, uh, when you adopt modulith, you kind of get introduced to some other libraries that I was not available. Um, art art unit is something that has, is stands alone, and modulith is actually uses it to enforce the majority of its rules. Um, you don't need to use mod modu fuse art unit. I think it's a great, uh, a great library on in its own right. Um, but this is for me was one of

those things that were really cool was as part of our architecture ADR. We said we didn't want user-named interfaces because we set it as a code SM using AR unit. We could then write a CL, write a test that said, Hey, as per our ADR, we don't allow the usage of named interfaces. Here's another example of something that we could do with AR unit. When we did this rewrite, there was still the front end of the application. The back end of the application was rewritten, but we had to keep API compatibility. So that means some of our codebase needed to be migrated to the new codebase to be API compatible, but we also wanted to limit the amount of impact that the old Legacy classes had on our new codebase. Um, yeah, that happened because that was a hard conceptually. It was a great idea, but it was really hard to actually do this within a reasonable time constraint. I did recently discover that Arch unit has something called a freezing Arch rule. So what this sh, what this does is the first time

you run this test. It will write to a text file all of the violations that have happened in that test. You then commit that file as part of your repository. It means that the next time that test runs, it looks at the record that it has and goes, Okay, these are the current violations of that test. But if a new violation is added, then that test will fail. And then if you have less and less violations, obviously the violations text file will shrink and shrink. And that way you can at least make sure that you're not expanding those lists of violations and hopefully you can work towards getting them a bit smaller. So one of the unexpected things for me about using Modulith was the Spring application events. So before using Modulith, we didn't really use application events or I've never really used application events other than for things like on Startup, on core Spring events. Never

really for into module communication. Once you really like dive into, once you really dive into, um, modulith, it doesn't force you to do this type of stuff, but it really just kind of puts you on a bit of a slope where at some point you just fall into using events, and you're not entirely sure how you ended up there. The one thing that we missed out here when doing this was that we were so focused on the architectural stuff that modulith could give to us that we, uh, we missed out what that annotation wasn't there. That annotation isn't just a marker for the fact that you're using modulith; it adds async and transactional there as well. So, what this means is if you're using that annotation, that if your JVM dies and you are using the registry broker, that when your JVM starts up again, you can actually save those events. That is a miss from our perspective, and that's something we need to go add in because it's there; why not use

it this is another one of those uh ones for the Boer real for for us was we have to download events from multiple s uh Source providers and we have this mechanism where we uh trigger a download event and then all of the different providers then go okay my specific implementation of downloading something I will go do that and this is a little bit of a copy from our old code base um but as we kind of copied it across we were we were like we're using events now let's make this an event before that every event provider just had the at scheduled annotation off it went when we tested this locally everything worked fine we pushed it into test everything worked fine when we deployed this to production we had some duplicate events I'm like that's a bit odd what's going on here we just assumed it was something weird when we deployed maybe one of the old systems hadn't gone down properly maybe the data migration wasn't great we weren't sure so we just kind of brushed it off um next day came back into work we had a

couple more duplicate so at this point we like something's not right here and uh started looking through the log files and saw this scheduled event trigger download event me message coming up milliseconds apart that's a bit odd go look into the logs a little bit closer could see that they were coming from the different hosts so it's like okay so our scheduling our schedule locking isn't working here what's the deal and then you realize yourself 10 minutes ago was it because all of this all this method is doing is triggering a download event that lock is only ever going to be milliseconds long so yes we locked this method but we were locking it for milliseconds and if those those two nodes were just milliseconds off then they would start then they they would independently trigger um their own event downloads for the different providers not sure if that constitutes a on line fix or one annotation value fix um the funny part about this was the workaround fix for production was we just decreased from two nodes until one node until we

could deploy this um if it's stupid and it works. I don't know if it's stupid um so one of the questions here um implicit in the name so is modular months. It's the PTO of this um and the question is if we look at our application um could we split it apart into microservices. I played around with this a little bit uh I just uh in a v in a variety of different ways. So I just took one of our modules and deleted it curious to see what happened. Firstly the tests failed which makes a bit of sense um but once I actually deleted the test as well the rest of the application just continued working. So that is quite nice to to see those safeguards there but it also does give me the confidence that to say that we could very easily take those event providers and split them out into different microservices if you want to because conceptually all that those event providers are doing for us is that they are downloading events from external uh downloading events from external.

providers, and they're either going to be putting them into a queue or putting them into a database. There's a different part of that system that is preventing presenting it to the users. So, yep, we could conceptually do that, but probably not going to do that because the juice isn't really worth the squeeze at the moment. The extra added infrastructure costs for doing that, we just don't see the benefit right now. But it is nice to know that we can. So, I mean, I don't, I won't really speak about that too much because I think that's fairly self-evident in the changes that we, the reduction in codebase that we got, going down from 183 database tables code. I know, I know also that the code coverage value is now higher. I think at this point, it's a bit of a game for the developers to see if they can get up to 90%, whereas previously it was a real struggle for the guys to even get to stay at

56% um for me the real takeaways here were that if you do start looking at Spring moduli, stick with the defaults until you've kind of earned the right to play with, to stick with the defaults until you've understood the project enough to work out what you should be doing. Like, don't come in with preconceived ideas of, Okay, cool, I'm going to use modulith, and then I'm going to use ports and adapters architecture, because probably you don't need to do that. Probably the default implementation is just good enough. Once you've worked with it for a little bit of time, look at it and go, Actually, this isn't good enough. Maybe I need to do XY Z, but give it the chance to kind of bed into how you work. The other thing that I thought was quite interesting was that I asked one of my developers just before this session, So, we've been using modulith for a bit of time now. What are your thoughts about it? Like, um, what are your

Reflections and his response was, Well, I'm not really using it much at the moment, so I can't give you too much insight. And I thought that was interesting because he had still been committing and working on the code base that week. But what he was meaning is that he hadn't been writing any modulith rules. It had become part of the workflow so much that we weren't violating rules anymore 'cause you just kind of understood how you should be writing code. So we didn't run into modulus, and we also weren't really writing any of the kind of Aruna type rules either. So I thought that was really cool in that it just became part of the workflow. It didn't slow anybody down. It just worked. So um, this is our journey so far with modulith. I think it's been a huge benefit for our development process. Obviously, I cannot speak to what this graph is going to or how this is going.

to look in the next couple of years, um, but I have confidence that it gives us the tools to continue in this direction. Um, and closing remark would be, I, this has been our blooper reel, kind of like the mistakes we've made, and I'm really curious to see how other people can build upon this body of knowledge and kind of go out there, make their own mistakes, and then share them back with the community so that we can just grow how we should be applying this out in the field. That was wonderful. I really enjoyed that. It's amazing what kind of difference it made looking at this. What's the score? And I have to give you the prize today for the best subtitles. There's so much humor in them. Thank you so much, Tim. Any questions for Tim? Ask them now. Nothing here. Okay, yeah, of course. Okay, thank you. About how long did it take? About how long did it take for you to get the development team to buy in to the modulith concept? I, uh, I think that was one of the difficulties, is that

because I'm an engineering lead, I'm not always with the team, so it was something I really battled with, and I think it was part of why we started what I termed AR architecture shedding, was because they were still trying to find their feet. So in some ways, I think probably took like a good three or four months for people to really buy in, um, and but at that point we'd kind of spent a lot of time spinning our wheels with preconceived notions on, Hey, you know, we've always done, I've always done layered architecture. Now how do I apply layered architecture? And so I would say a good three to four months, and then we kind of embedded these ways of working in. So I would say that was probably how long it took us. Um, is there a project where you would say, Don't start with modulith? No, I mean, I think initially when the modular project started, it was aimed at more Green Field type things, and we kind of uh shoehorn G Fields cuz

we did a rewrite, but I know that Oliver's been doing a lot of work on making this so that you can retrofit it to Legacy code bases. And I think things like the freezing architecture test from the art unit guys means that you don't have to be perfect. You can go like, These are our violations right now. We just need to get better. So, I think I'm sure there are some examples where you shouldn't, but for me, if you can just go and try to see how you can make things better slowly along the way, amazing. Well, thank you so much. Thank you, thank you. So, if there's no more questions, one last chance. All right, no more questions. So then, we'll see you and the folks on the live stream. We'll see you back at 20 minutes past the hour.

Spring Modulith And I: An Apprenticeship In Team Building (SpringOne 2024)

Spring is the most popular application development framework for Java™. 
Millions of developers use Spring to build simple, truly portable, fast and flexible JVM-based systems and applications.
Learn more about Spring at http://www.spring.io

Spring Modulith And I: An Apprenticeship In Team Building (SpringOne 2024)

Spring Modulith And I: An Apprenticeship In Team Building (SpringOne 2024)

스크립트