Software Architecture vs. Code • Simon Brown • GOTO 2014

Who am I I'm the author of this book called Software Architect for developers it's a it's an I kind of do a friendly accessible guide to software architecture if you read a lot of the classic architecture books they're written by friends very very smart people but they quite dry quite academic so I wanted to write a book which you know hit home with developers for those of you who are coming to my workshop on Friday I will give you a free copy this book as a bribery for coming on I'm a software developer but over the past couple of years I've been helping teams understand what software architects it's all about and particularly how we can bounce agility and upfront thinking but I do write code as well so don't worry this is going to get all scary and fluffy and conceptual and really what I'm interested here is the intersection between software architecture and code so as I said I want to see these things as one in the same thing now you're recognized from my accent I'm not local I'm actually from Jersey that is Jersey not Joisey which exit doesn't work on me so this is Jersey in the Channel Islands and I moved back to Jersey about five years ago after working for London for 12 years Jersey is fantastic it's a small island surrounded by sea and there's lots of things you can do and when I was a kid I used to go fishing and I used to wake up on a Sunday morning attach my fishing rod to the crossbar of my bicycle cycled to a local pier and go fishing and sometimes I even caught some fish I wasn't that successful when I moved back to Jersey five years ago I actually moved back to Jersey one month before my family and I had some free time and I figured why get back into fishing again so I did I went to the fishing shop bought a rod and when I was in the fishing shop I saw these little tiny plastic fish and they're called lures and I said to the guy behind the counter what do you use these things for and he said we can catch sea bass oh that sounds fun I never never caught a sea bass before so we had this chat and he explained how to do it and I thought yeah I'll buy some and I went bass fishing a lot and I caught nothing right I would go out you know every other day every other evening different piers different beaches absolutely zip the next season comes along the next summer exactly the same thing happens I catch absolutely zero and at this point I'm trying to get it really early go out fishing really late you know I'm spending a lot of time doing this and I'm getting absolutely no results we'll come back to this later we're leaving in suspense so software architecture software architecture is often really overrated okay it's nothing more than just looking at the structure and vision of your software system but lots of people think architectures about this now grandiose visions conceptual abstractions and that sort of thing it's not it's just how we see the structure of our system in terms of modules services components layers and how we create that vision so how do we get to a structure and how do we share this vision with the rest of the team so I'm particularly interested in communication of architectures as a way to create a shared common understanding that a team can work from show of hands who uses UML here on a regular basis as part of the job so I know and someone else right that's it two people I've been quite fortunate to do a lot of travelling recently I've been to the US few times I've traveled to 20 plus countries around Europe Dubai China most people don't use your milk in my experience ok so I've asked this question a lot now UML is kind of the one true standard way that we've got to describe software and yet look we're not using it so that is a problem so how do we communicate our software systems well I guess we use no UML right sequel no sequel UML everything else just boxes and lines pictures boxes lines pictures are fine but the boxes and lines need to make sense and I run training courses and stuff around Europe and one of the things I've discovered is that people feel find this really hard to do they find it really hard to visualize and share and communicate their software systems and I can now say this with some confidence because part of my training course is to give groups the set of requirements it's a really simple financial risk system and the requirements very very simple we have two data systems trades things the bank sells with other banks reference data for the other banks we pull this a together we merge it together we perform some calculations we produce an Excel report there's also the ability to modify some parameters in the calculations that's it that's essentially all the system does and we get people up in groups and we get them to design a solution and the output from this exercise is to draw some pictures this is a type of thing we get right just shopping list of technologies people have decided what which technologies they're going to use but not why we get lots of boxes and no line style diagrams you know this is a three tier or three layer Microsoft solution says ISP don't network at the top there's a web app but nobody's using it people give us a functional view you know what's a functional view it's just a list of things different colors I don't know why people have different pens who knows this is my all-time favorite this central spine shows the core of the system to source data systems importing step calculation step reporting step distribute the report nice car crash this thing's like London Heathrow Chicago it's a big centralized connection point for some reason don't know why this is just a mess different colors style shapes this box here says UI upside down why this diagram describes all of your software systems that you're working on today look business logic in the middle we have a system here that does business logic how super awesome is that this picture tells you nothing then we got the logical view the logical views basically anything that doesn't include technology choices I've discovered people are really scared to mix technologies on these pictures and then we get things like the ho Co the homeless old C sharp object you know just a bunch of C sharp things floating around next to a database that doesn't make any sense this one's kind of big and complex when I was a kid had these storybooks you'd start from page one and choose your own adventure by turning to different pages in the book this one's the same you start at the top go down make choices eventually you die end up in the trap it's all bad I've got millions of these photos kicking around my laptop I ask groups sorry no no no I just take photos of them IIT see these being created so I ask people what they find challenge about this exercise and they say well we don't know what to draw we don't know how to draw it right well this is what UML's all about but um I was hugely fallen out of fashion I mean to people out of a know 50 60 only using UML you ask people why and they say well um else too complex is too low-level I don't know it my team doesn't know it or they say we're agile we don't do UML because we're agile and we do TDD instead you know TDD seems to be a substitute for architecture in many people's minds is this really true no you know for me TDD you have to do TDD within a set of boundaries and frameworks and architecture provides those boundaries and frameworks so this whole diagramming thing it's really hard to show everything on a single picture and when you read these classic architecture books they'll often talk about views and viewpoints and perspectives so this is Philip krypton's Rupp forth the four plus one model logical view development view press this view physical view use cases tie the whole thing together lots of other models and techniques show exactly the same kind of thing but they're all different and the naming well the naming often doesn't make much sense so I've been in meetings where architects have argued the difference between a conceptual view the logical view these sound like the same thing to me but I'm probably bit stupid to understand it if I'm a developer writing lines of code is that the development of you or the implementation view or maybe it's the design view but hang on a second if I'm writing lines of code if I'm physically creating files maybe that's the physical view but now that doesn't make any sense because the physical view is the infrastructure but we're all using virtual infrastructure now so do we have a virtual physical view the whole thing doesn't make any sense the key thing that a lot of these mechanisms and techniques share is that they separate the design the logical type views from the code and 70 white getters you know here's our software system in the middle and we will view it from different angles and different views depending on our interests and in order to document and communicate your systems you have to understand this kind of stuff and this makes my head hurt right I have two kids and they love eating ice cream and they do it really fast and what happens when I eat ice cream really fast you get brain freeze now if you go to Wikipedia there are some ways to prevent brain freeze you either drink a hot drink beforehand does that work well no because my kids don't drink drink hot drinks the easiest way to prevent brain freeze is to stop eating ice cream this font is horrible this gives me a headache the only way to avoid that headache is to not look at this font these models of how we break down software system they make my head hurt we could look at different views in isolation to try to understand them or we could just do something different right let's not use as models we could cheat right forget all this complex views stuff why don't we just cheat if the purpose if the goal is to create some pictures to communicate our software system what why don't we just look for examples and use those as a basis how do we do this we go to Google right so if you do a search for software architecture diagram on Google you get stuff like this page after page after page of block diagram nicely colored of course cool so what we'll do is we'll take some of these and base our examples on them and then what happens you get stuff like this right so take this one here in the middle we know that layering is apparently important so let's have a diagram that shows the layers some stuff never quite fits in horizontal layers so let's have these vertical layers and they're good because they stack the diagram together stop it wobbling provide some rigidity why the different layers different colors I don't know but at least they gradient shaded this is good for PowerPoint acronyms all sorts of stuff here and these patterns are repeated over and over again do you guys see these kicking around your organization's enterprise architects love this stuff so we can cheat right so back to my fishing story I'm getting completely fed up of getting up really early in the morning spending lots of time chucking plastic fish in the sea and getting nowhere so I thought well I'm going to cheat how do you cheat when you go fishing well you can either chuck dynamite in let's be excessive or you can buy a boat so I bought a boat now you're probably thinking yeah 30 40 foot long nice cabin maybe a little galley I should probably caveat what I mean by boats what I really mean is kayak two of them bright yellow and plastic and this is nice because you know Jersey's very pretty place and you can go and Bob around the island and just drop your fishing rod over the side and hopefully catch some fish and I did right so I caught my first sea bass on my kayak but the thing is even my kids can catch fish off my kayak all we do is we paddle out a bit we drop some feathers the side we do this for a bit and then Mack will pop out I love this photo look my oldest here is caught the fish he's really happy my wife's really chuffed and my little son in the middle is crapping himself because he's had to bet about to have a bunch of fish dumped on his lap portable thing kind of feels I'm fulfilling though right I've caught some fish but I've not done it it feels like I've cheated we'll pick this up again later code let's attack this from the other perspective right so what happens if we think about code well what's our purpose these pictures the purpose of these pictures we're trying to draw is is to answer a couple of basic questions if we're doing upfront design it's this question we're trying to get to the bottom of you know is this what we are going to build if we're retrospectively documenting a system then it's this question did we build it that way is that what we coded and really the code is the single point of truth but the code is the embodiment of the architecture now let's imagine we have a huge enterprise system 250,000 classes are we going to draw a diagram with 250,000 boxes on hell no right because you'll never ever get to the end of it so what we do on these diagrams is we talk about abstractions and abstractions are a way to you know clump stuff together and prevent a simplified view of the world in this case our software system and what do we do this is because abstractions last reason about a big and/or complex system like they essentially allow us to remove some information remove some noise routes of detail and this raises a bunch of rather interesting and tricky questions when we're drawing these pictures of abstractions do those abstractions map into the code right so if we draw something there's a layer or a module or a component can we see those concepts in the code base and the answer is often not really because if you take Java if you take c-sharp it doesn't have a component keyword it doesn't have a layer keyword doesn't have a service keyword because we're thinking in terms of classes namespaces packages when we write in code and these concepts are different from ones on the pictures sharp hands who uses a layered architecture here wow that's tiny what's everybody else doing decoding the traditional way iid did the store yesterday in London and everybody put the hands up when they said that work one else and if they were doing lace that's one surprise so she's your typical layered architecture right so presentation layer business layer data layer put some boxes in the layers why them all up that's how a lot of people approach software design and software development perceived wisdom why that's what the books tell us to do this is chapter one from a spring book you know structure apps in this way presentation tier business dear data tier blah blah blah you turn over the page it describes the different layers the purpose of them this line is quite interesting spring aims to decouple architectural layers so that each layer can be modified as far as possible without impacting other layers this is basically just about isolating an impact impact of change if you download tutorials for the spring framework for example this is your sample code base domain package repository package service package kind of sound like layers you're going to stack overflow how do i structure my codebase people give you the same sort of advice exactly the same in the.net world perceived wisdom this is the way we should do stuff right so back to my fishing story I still want to catch a sea bass by standing on Jersey and not bobbing around you know around it in a kayak so I try again and I go and you know try some different things and I've talked to a few people and they say things like well you should go fishing at low tide and unlike me if I go fishing at low tide there's no water by definition so how is that going to work and then I go no you're fishing in the wrong place what so it's kind of challenging all this perceived wisdom I built up over the years so I thought I'm gonna have to go by book so I went to the fishing shop and I bought a book on bass fishing and this book's like 20 years old it's got some fascinating stories in it now the thing about bass fishing is that it's very secretive nobody is actually going to tell you the answers and their secrets particularly if you ask them for spots to go fishing and this is great book and it's got lots of tips and techniques but they're kind of abstract they don't really tell you what to do if this book was written by Yoda it would basically say this finds the fish and you will catch them well thanks right you have to find the fish to catch them yeah I get that but it does challenge some of my perceived wisdom it makes me think about different places to go fishing different times of the day different techniques you know actually having a method to my madness of just chucking stuff in the scene hoping for the best you know throwing my little fishes at rocks for example again will Park this and come back to later this is your typical layered architecture except it's not because that happens right so we all know that layered architectures tend to get corrupted very very easily so the way we implement layered architectures is you know each of these is a different package or namespace and in order to call stuff in different packages and namespaces that stuff has to be public and once something's public it can be called from anywhere so these architectures tend to get corrupted quite easily and this is what ultimately ends up in those horrible big balls of mud now there are different ways we can structure our software systems we can use hexagons and onions and clean architecture and stuff like that these are all different ways to structure our system and think about our system but essentially they're still layered right we can redraw our layered architecture like circle six stuff inside it stuff still has to be public we can still corrupt it so maybe layers are bad here maybe layers should be considered harmful some of you might find that controversial some of you might be going yeah I hate layers it's an appalling way to build software I'm not going to answer that then let you mull it over in your heads but I will ask those this question these layers we've got in our software are they our significant building blocks or are our significant building blocks something else so in other words a layers just an implementation detail that we're looking at too closely there's a guy called George Fairbanks he's written this book here just enough so for architecture brilliant book definitely recommend it and he identifies this thing this book called the model code gap and essentially it says your architect models are going to show different things than your code and really what this is talking about is you know you view your architecture differently from your code and a lot of this comes down to how you organize your code base and therefore hey reflect that organization on to architecture pictures and in George's book you run through a whole bunch of different types of ways of modeling systems and they all essentially do the same thing they split out they break out the code model from the rest of the world design views logical views module views and whatever so how do we shrink this model code gap well the obvious answer is merge two things together right most of the model in the code we tried this 1012 years ago model-driven architecture it's awful it didn't work you know putting lots of lots of information into into um our model pressing a button getting code out right so let's dump that and let's flick this on its head and what George says in his book is that you can use an architectural e-everything coding style in other words you drop hints in your code base to reflect your architectural construct you have a component you have a service you have a layer you make sure those things end in the word component service layer you have a packaging Convention which says all of the stuff related to a single service is in this package in this namespace Zen when you do this Wow tiny number of people yeah again that's my experience of kind of consulting around Europe nobody does this perhaps we're looking at this the wrong way perhaps these models that we're talking about we shouldn't be drawing them by hand maybe we should be automatically generating these pictures but we can't right it's 2014 and there are a bunch of tools out there that can draw architecture pictures but they don't work they fundamentally don't work why because they see the things we do as developers they see packages namespaces classes interfaces they don't know what a layer is they don't know what a services are component a module they see the same basic constructs and therefore that's what they reflect on the diagrams structure 101 Latics and depend sonar etc etc etc they all give you package dependency diagrams class dependency diagrams they show you stuff like this you know if you've got a big ball of mud these pictures are just going to be horrible you know you've got a mess you don't need a tool to tell you that so something else to think about is maybe the languages were using are not suitable for the types of systems were building today maybe we need a language with you know components services layer as first-class citizens or maybe not how do we mostly see weld but how do we merge architecture and code make them one the same well any models we do produce should reflect the code the two things should match up ideally one-to-one and the way to do this is to make sure you get your abstractions correct now UML gives you two things UML gives you a standard set of abstractions classes components packages use case bubbles that kind of thing and the standard set of boxes and lines notation to describe it whenever I see people using UML guess what they do they abuse the abstractions and the typical example is we have a class on the class diagram it represents a system or a message bus or something all they abuse the notation I've seen people drawing boxes and lines diagrams with a goomar class diagram and they just take out all the compartments to make it look like an empty box so I using an expensive tool identity care age or pictures so my workshop on Friday is about drawing pictures but I don't care how you draw pictures I care about abstractions and the way I think the software system is very simple so my software systems are made up of what I call containers containers just something like a web app a web server an application server a database file system mobile device a browser a windows service that kind of thing it's an executable thing somewhere that we can put code or data I'm a big fan of breaking my systems up in terms of components so my containers contain components now I grant you this is a hugely overloaded word what's going to mean bunch of stuff related cohesive encapsulated with a nice clean interface on top because I mostly build systems in Java and.net my components are made up or built up of classes these might be functions might be database tables depending on your technology of choice it's a simple tree structure software system made up of a bunch of containers each of which has components those things are made of classes right with this in mind with this set of abstractions in mind we can then draw pictures at different levels in turn we can have a system context view of the world which shows your system in the middle stuff around it within zoom into your system and we show the containers that gives you the high level shape of the system within zoom into those containers in turn and we see components this is normally where I stop but you'll see that the number four up here you can go down to classes if you want to you can start diagramming out classes you have the internals of components but I don't normally do that it's normally too much detail an example with some monkeys this is a system that I built is called tech drive storage a it's just a content aggregator for the local tech community in Jersey this is my tech drive system these are my key types users these are my system dependencies a zoom in to the monkey I blow them up this is my containers picture it shows my webserver my standalone process and my databases where I'm storing data again it's just a high-level shape of the system Izu min to one of these boxes we see components inside it you know we've got like a Twitter connected components here and a github connector and a newsfeed connector and this is how I decompose my software system and these diagrams are essentially like Maps so if you go to Google go to Google Maps and you do search for Jersey for me it gives me this it might give you New Jersey but that's a different story and it gives you a zoomed in view of Jersey and this is great because it tells you you know where the roads are where the airport is where the beaches are all that kind of stuff but if you don't know where Jersey is you need to zoom out a few levels and eventually you get to that we chose you where Jersey is in conjunction with the rest of Europe the diagrams should also be like Maps you know sometimes we want the zoomed in view of the world sometimes we want to zoom out and see the system as a whole now this is just the way that I think about software systems it's not necessarily about creating a standard but what I want to do is give you some other ideas here some other ways to think about your systems in your head and what this model I've just presented does is it basically puts the static structure of the system right at the core from the code in classes although out through components containers and the system and once you understand your static structure of your system other stuff falls into place really easily around it you know your your runtime you'll behave your models if you want to draw them are simply collaborations across components your deployment mapping is basically containers onto infrastructure and so on and so forth and what this basically does is it says look who's the major stakeholder for this stuff we're doing for me it's us as developers the reason I document software systems is for developers it's because either I want something I can maintain in the future or I want to set the scene now here's a blank sheet of paper this is kind of what we're going to build this is how envisions that we're going to build it and my C formal is basically just putting the static structure at the center and admitting that developers are the key stakeholders with this in mind you can then you know ask this question we have these diagrams we have these models does it map to the code does it reflect the code and if we do have diagrams can here and if we do have architecture models and they don't reflect the code the diagrams are basically pointless we're just deceiving ourselves we've created like an alternate reality about how we think the system should look but it doesn't now I just briefly presented you some diagrams that I drew based upon a real system that I built so we can ask the question my diagrams did they reflect the code and vice versa and the answer is you can go look this up yourself because it's on github the answers yes hooray I'm super awesome right I've got a nice clean mapping between my code in my architecture the case of there's a there's a tweet component here and I've got this nice convention that says you know there's a whole bunch of components all nicely neatly packaged how cool am i this is epic apart from being a bit of a smartass now this is a more interesting question to ask me did it start out like this or did I manufacture this situation and the answer is not really so I drew these diagrams for my training course in my book and I did have this nice concept in my head of you know they're a bunch of components in my system but when I looked to the code it didn't match so even I was creating this fantasy about what I thought my system would look like why because I did exactly whatever he asked us I used layers so this is built in Java I had a services layer and a data access layer so I had this concept of a tweet service which basically stores tweets in a database and there was a tweet service which gave you access that information interface because I'm writing everything in spring and Java see after an interface for everything and a default implementation with a bit of business logic delegating down to a tweet data access object implementation right standard layered architecture standard implementation so what I've created and built a layered architecture in my head I'm thinking well this is a single component and as I said before you know this stuff has to be public which means anyone can call it so it's easy easily corruptible and a component is really these two things kind of jam together in a really horrible way two options obviously one change the pictures didn't like that didn't reflect my nice idealistic view I had in my head option to refactor so now the code looks like this so essentially I've merged the layers I have a nice tweet component interface with a bunch of really really simple operations there's an implementation which isn't essentially this thing and there's my tweets data access object which is essentially this thing that's public these two things a package protected so you can't see them we have a nice encapsulation here this is cool originally I had this tweet data access object in here as well it's not used so I binned it I throw it away some people when you show them this picture they go well Simon what you've done now is you've not created a layered architecture and therefore you can't change your database to be something else the I can I still have layers but they're internal layers so this whole thing about you know our layer is significant or are the implementation details here my layerings an internal implementation detail I can still switch out my data access because I've got a way to essentially isolate change in this one class but the people who love testing and TDD go this is really bad because you can't mock out that thing now but there's no interface used to mock and there's no way for you to inject your data access object to this because it's all wrapped up in a package there are some workarounds here right we could create another parallel package structure in a separate source code repository create some abstract stuff make an injection point here we can have some workarounds to you know inject a mock implementation of my data access object I can't be bothered by too much hard work so a screw and it's not going to unit test the whole thing all right so just don't do unit testing who's seen all the stuff about unit testing at the moment unit testing being considered wasteful right so this is gonna be a quick quick educational thing there's a great paper by a guy called Jim Killeen and he basically says most of what we do in terms of unit testing is complete utter waste the whole point of unit testing and mocking and that kind of thing was you know if you look about 10 years databases for slow infrastructure is slow so therefore let's put in injection points we can mock stuff out and then we can write unit tests against local storage in memory storage that kind of thing and we can speed up the feedback cycles it's an interesting paper I don't agree with all of it you might not agree with all of it either something else Jim says is that if we've got a system with a bunch of tests maybe we've got a horrible design and maybe our developers don't really appreciate how to design software well which is an interesting way to think about this DHH the rails guy he jumped on this is that yeah unit testing awful so DHH created Ruby on Rails really simple way to build data-driven web apps a lot of that stuff is done for you love the plumbing it's done for you in order to make your Ruby or rails code testable you have to start chopping stuff up with interfaces injection points that kind of thing and in this blog post DHH says yeah this is this is basically damaging our design it's damaging the clean design that rails gives you and he says you should not let tests drive your design is just crazy and again you may agree or disagree with this but you've got a point right there are some really interesting points being made here what's the purpose of layering well it's to make sure that changes are essentially isolated so if we want to reach out our database we do it one place if you want to switch out our integration with an Excel system we do it in one place and maybe we should see this separately from our tests maybe we should be thinking more about our design so with my tech tribe site there's a bunch of stuff that just does not get unit tests anymore and instead what I do is I do component testing right I can PI test that component as a single thing including spitting up Mongo's chucking stuff into and then bringing it down again and it's super quick so I can do true component testing on a bunch of stuff in my codebase now that's not applicable for everything now if I'm dealing with asynchronous systems or email or systems outside of my hands component testing integration testing is kind of hard to do so you still want to do unit tests and mocks but maybe we should be unit testing or testing our structural elements maybe that's something that we want to be striving for instead of just blindly unit testing everything and that's exactly what this is all about you know don't blindly copy what everyone is doing the whole layered architecture thing the whole doing TDD and unit testing and mocking why do we do that maybe we should question the value that these things are giving us back to my fishing I tried and I tried and I tried after reading this book and eventually I call to see bass by standing on Jersey and not bobbing around around the island and this is amazing because finally all of this practice all of these different things I was experimenting with finally came together somehow magically luckily I did see people fishing you know when I'm driving around Jersey I saw people bass fishing and I kind of try and copy what they were doing just chucking these things and see reading them back in and that sort of thing you have to experiment you have to change what you're doing if you repeat the same thing over and over again you'll get the same result and the systems that we build are all different so maybe that technique we followed last time is not applicable for this thing we're building this time so you need to think about what you're doing and you need to understand why you're doing it and once you understand something you can teach it to others so of course the first thing that happens when I went home with my stories and my photos of my sea bass is my family goes cool can we come fishing to my tile no this can be another three years of pain so now I can see some hath fish as well just a point about fishing if you ever take your wife out fishing make sure she doesn't fall off a rock this is a this is two weeks ago in Jersey my seven year old finally caught two fish on his own by casting out reeling in he's going daddy daddy a quarter fish is fishing rods doing this bouncing round daddy daddy I really have caught a fishy I was out running over to him trying to trying to pick this thing up and he's really scared holding it it's a brilliant sauce portable this spot for me catching fish the point of all this is that a good architecture enables agility so this is something they're all striving for we're looking for you know software systems that are easy to maintain flex change enhance and this is really the goal but in order to do this we need to think about the design we need to build adaptability and agility in and of course there are different size of architectures right we've got the big monolithic balls of might here easy to build quick to build bit of a pain to maintain on the other ends of spectra we got micro services and service based architectures you know lots of individual loosely collaborating things gives you lots of flexibility lots of agility because we can change any of these services independently provided certain constraints are met a bit more complex to implement design you can have collaboration to worry about that kind of thing I'm looking forward to Rachel lacox talk later I think she's going to demystify something as mike rizzo sister and kind of you got something in the middle you know you can still have a monolithic deployment unit with a nice neat structure inside it now components module services layers whatever you want to call them we have to think about this you have to get it right and that gives you ability and the structure of your software system and therefore the decomposition strategy you use to get there are really really important and there are lots and lots of different ways we can decompose our software systems and what I will suggest is maybe layers aren't the best option always are there are other things we can do here agile approaches talk about retrospectives and inspecting and adapting if we want to build an agile architecture we need to apply this same mantra to our system how do we inspect a system how do we look at a system or we can draw some pictures we can create some models and those models as I said they have to match the code otherwise it's pointless once you understand your system then you can adapt it right people say that architecture refactoring is really hard to do it's not if you understand what you have truly what you have anyone's and where you want to get to it's a simple transformation process is simple refactoring and this is why we should think about how to line the software architectural view of the world and the code because it allows us to make these transformations much more easily and a simple explicit mapping between the diagrams and the code really really helps is it easier to explain it's easier to do architecture refactorings it's just easier to work with and until we do find that one true Silver Bullet we have to think so that's the thing I'd really urge you to do you know don't blindly adopt that layered architecture think about other ways you can structure your software systems think about other ways you can decompose maybe into components maybe to services maybe to modules and think about how to relate these things to the code and my final point is very very simple if your software system is hard to work with change it this is entirely within your hands thank you very much you

Channel: GOTO Conferences

Views: 40,989

Rating: 4.4835167 out of 5

Keywords: Software (Industry), Software Architecture, Architecture (Industry), Data (Website Category), Videos for Developers, GOTO, GOTOcon, GOTO Conference

Id: 9noJwoIivV8

Length: 41min 55sec (2515 seconds)

Published: Mon Aug 11 2014