CDOBC Lesson 3: Separation of Concerns

[Music] well welcome welcome to the composable dxp with uniform boot camp course lesson number three separation of concerns today presented by tim bennicks he's the principal developer advocate at uniform if you want to learn more about him we will have a great interview with him in the introduction section of this bootcamp on headlesscreator.com so just go there and check it out now with that said i'm going to bring tim in tim welcome i'm going to let you get started if anybody has any questions of the live audience type him in the comments and i'll ask him tell your sir all right thank you very much so today we will be talking about the separation of concerns and that's a term that keeps coming back i guess for my whole career i've been talking about this stuff from being a front-end developer or maybe somebody who works on teams and things like that it's it keeps coming back and so in computer science separation of concerns is a design principle for separating a computer program into distinct sections such that each section addresses a separate concern and so this is the opposite of the spaquetti code you might have heard about back in the day and so today i want to talk about this and how that actually works in general but then also how it applies to dxps and to being composable and so let's talk about separation of concerns with a bit of a real life example that will hopefully make it a bit more tangible so not super cody and techy but imagine you have a hospital right there's lots of different disciplines and departments in a hospital if they didn't have separation of concerns everybody would do everything but a nurse cannot do what a doctor does and a doctor cannot do what a cleaner does and a cafeteria person cannot do what the doctor does but they all have their own amazing skill set and so you have to separate the concerns and then hopefully get an organization that is scalable and easy to oversee because you know who does what and when and how and where and part of that separation of concerns you has something we call cohesion and coupling and basically what you're trying to do with separation of concerns is try to reduce the coupling and try to increase the cohesion so let's have a little talk about what these two terms actually are and pay attention those will be important words to remember for later on in the boot camp so um when we look at cohesion is well look at this lovely image here i love this one because basically is this is separation of concerns because the forks and the spoons and all the other things they are actually um separated but they are also chunked up together in things that um are similar right and that's what cohesion actually is right so cohesion is a measure of how related individual items in a group are kind of like how they are related to one another because if you go without cohesion and you just have everything separated out because you know separation of concerns it can be quite messy so think about code for let's say calculations right you might have a function for um plus and you might have a function for minus and you might have a function for other calculus things well wouldn't it be easier if you grab this function you put them in a class right and then that class becomes your math class and then you can reuse it everywhere so you have actually put things together and you made them a bit more cohesive and then you use that as something um in your system and so now let's talk about coupling and you can see this i love this image right this is a a pretty tightly coupled system and i also love that there's an air fan in this on the side that is completely futile because that's obviously not going to do anything but aside from the image let's have a little um think about what coupling actually means right so coupling is a measure of dependence between two or more components tight coupling is bad and loose coupling is good and of course in the context that we're talking about now because loose coupling is great but if it's too loosely coupled like what we said if all the forks are on their own and all the spoons are on their own it's really hard to actually deal with everything right so you kind of have to find your way balance between the most loose coupled stuff you can get with the most amount of cohesion that you can get and that's what we're looking at and this applies to hospitals like we just talked about but also to code and to the xps and many other things right and so why is this actually so important it's kind of an interesting story right but how do how why is it so important why is it applied and so well what you want to look at is um if you remember the the the disconnected uh sandwich from the last two episodes um this is again one of those right so what all of this separation of concerns gives you is actually having better clarity right it's easier to understand what's going on when everything is neatly organized this is kind of obvious i guess but all of those are honestly open doors but when you put them all together it's like ah that separation of concerns that's why i want it right because reusability becomes much easier because it becomes easier to extend or to fix or change when things are better organized right and you can also test things much better right because when everything is isolated um you know what one chunk will do and if you don't have that chunk and you're gonna have to test something else you just mock or fake that other chunk and then you don't have to have that in your whole system of testing no you just say okay i'm gonna test one out of eight things so the other seven i'll just fake them to make sure that they exist in the software but they always give the same output let's say and so that one thing you want to test doesn't now break due to all these other seven things doing stuff so it gives you much more much easier way to to test things and if you want to create new features or scale things up or change things up it's much faster in development if you just have a nice overview and organizational as well right if everything is neatly separated it's so much easier to actually have a good overview of what does what and when does it and how does it do it and well that was not english but i guess you get the gist and so there's a couple of important things of why this is so important and so now let's get to um the meat and potatoes of this talk we're talking about dxps here right and so how does this separation of concerns actually align with dxps well um building a technical stack from composable products doesn't actually mean that you end up with a composable architecture there is kind of a big trap here that you can fall into when you think everything is composable and then actually you put everything together and you built your architecture and suddenly it's no longer composable because you didn't separate the concerns well and we'll talk about how that works in a sec right so in the traditional monolithical systems of year like the the old old school stuff basically is it's basically a collection of capabilities from a single vendor that are by design interconnected and indivisible right so traditional systems have interconnectivity because you have to be able to log into one system and deal with all of them at the same time and you're not able to just remove one thing or if you don't need all of it don't take these it's the whole goal of this monolith to do everything for you and there's lots of amazing use cases why you would want this but the moment that you don't want it that you actually want to choose yourself what to do suddenly it's actually pretty annoying that it's interconnected and indivisible because you might want to take something out and suddenly something else breaks and and a monolith that's a feature that's fine because you're not going to take it out anyways but when you go composable you will and so it comes down to the fact if you buy a bunch of composable products it gives you the potential to have them connected but out of the box they are not connected at all you actually have to compose them together and that's actually pretty tricky so basically you are the composer right and making integrations is actually pretty hard especially to make sure that they are loosely coupled in a cohesive way and so if you want to compose things really well and easily you require an integration that is easy but making an easy integration is basically the hardest thing to do and so there's kind of this complex system going around and because of all of these things generally what you get and this might be a little bit of a new term it certainly is to me you are actually creating a composable monolith now right because it's actually a collection of capabilities that you select from multiple vendors but they are suddenly also interconnected because you have chosen to do it a certain way because of early stage decisions or maybe not having an overview of everything and you just have to build it and then this kind of stuff happens and if this happens they will also not be divisible they will be indivisible and you see all the locks appear and if you have this how are you going to change your front end or how are you going to change your commerce engine if they are connected to everything so you have possibly now created something worse for composability than the monolith is because in a monolith you can point the finger to one company and say that's broken fix it in this case who do you point the finger to you connected them on their own they work fine right and so you have to do everything you can to make separation of concerns a thing and not create a composable monolith because it will be harder for you to move forward now and so it's almost like okay let's let's do legos right because it's also nice and composable but then you use super glue to glue them together so i will hereby propose to you the new brand image of the composable monolith with le glue and this literally a bucket of glue um next to legos right and you don't want to be gluing legos and i know lego glue actually exists for the more professional lego builders i know but the image still works right and so what is truly compulsive