What is Software Architecture?

0:00 hey everybody it's derek martin from codepinion.com what is software architecture well to me it's about decision making more specifically decisions you make usually early on and how the impact decisions you can make in the future it's about giving yourself options but being aware of the price or the cost that you have to pay to get those options i'm gonna explain a little bit more of this and give three concrete examples this video is brought to you by event store db the stream database built from the ground up for event sourcing cqrs and event driven microservices for more on event store db check out the link in the description so i mentioned options and costs and really what i'm referring to here is you don't want to be developing a system that is so rigid that you can't change it in any way because of new

0:46 requirements or something changing with the model you want to be able to evolve your system and not have to pay an incredibly high price because you need to entirely rewrite things you want to give yourself options to be able to do those things at not a high price but that means that you do have to pay a price initially kind of as you're building a system and make decisions that give you those options so i'm not talking about what ifs or what if this happens and we need to figure out this use case or trying to come up with all these different edge cases that you can build it into the system that's not what i'm referring to i'm also not referring to building a rules engine or some crazy configuration to make it more configurable no i'm talking about fundamentally your architecture and how you develop your system that allows you to do different

1:32 things over time giving changing requirements so as usual this usually comes down and how i think about things as coupling and cohesion and coupling cohesion to me are kind of the yin yang of software design where he's trying to increase cohesion and lower coupling so let's just kind of go over the two things so coupling what am i talking about it's the degrees of interdependence between two software modules so you could think of this as boundaries as classes as functions just the interdependence between two different things in cohesion we're talking about the degree of which two elements two things inside a module belong together so if you want more specific information on coupling and cohesion check out the links in the description where i talk about informational versus functional cohesion and effort and effort coupling

2:19 so i'm gonna give three concrete examples a decisions that you can make that are relatively low cost that give you options and all three of these are directly related to coupling and cohesion so the first is defining logical boundaries grouping different pieces of behavior and functionality of what your system provides and grouping them together not being a free-for-all of what i'm kind of illustrating here with the different boxes and different colors is that each different piece of functionality shouldn't be intertwined with other pieces of functionality that's not related now i'm going to get to coupling in a second here but the first thing is understanding what your system does in building boundaries based on what that functionality is i have videos i've done in the past that explain how not

3:04 all things are created equals in terms of entities where i usually give the example if you're talking about like a product in a warehouse you may think oh there's a product entity and it needs to live in a catalog service and that's the only place that a product lives no that's not really the case that concept of a product can live within multiple different logical boundaries because there's different pieces of functionality that relate to each other when we're talking about a product in a warehouse the warehousing portion has a concept of a product sales has the concept of a product and those are completely two different logical boundaries so grouping these pieces of functionality into their own boundary can be really difficult especially if you have an existing system but you can look at carving off pieces one at a time to define these logical boundaries if

3:49 you're starting green field or a brand new project defining boundaries can be really difficult especially if you really don't understand the domain but even though you may not get it completely correct you're still better off defining some type of boundary for pieces of functionality so the second concrete thing now comes to communication related to coupling obviously if we were thinking about kind of all these different logical boundaries you would assume that they need to communicate in some way just like we have we were talking about high degree of coupling if you're building a monolith or say a turd pile or distributed turpile as i call them you have a high degree of coupling because this boundary or this piece of functionality needs to interact with this boundary or another piece of functionality over here needs to get data etc so what you end up having

4:34 whether it's a monolith or a distributed monolith where you have a lot of interdependence between various boundaries or features etc this becomes a nightmare this is a nightmare of coupling that's really hard to manage so we've defined kind of the cohesion side of breaking this apart in grouping things of pieces of functionality but then how do we have those logical boundaries communicate with each other to deal with different things like business processes and workflows that are kind of feature related so the second concrete thing you can do is to remove tight coupling that kind of crosses a logical boundary line you don't want to have one logical boundary required to make a call to another logical boundary whether this is in process or rpc we want to remove that

5:21 tight coupling so concrete thing to number two that you can do to remove that tight coupling is to be more loosely coupled by introducing something like messaging now you may think well i'm completely unfamiliar with this so yes you will have a higher cost in this sense of knowledge gained to implement messaging versus doing everything rpc and having all this tight coupling so but in doing so if you're leveraging something like a messaging library that provides a lot of kind of the messaging patterns check out the link i'll have a description about these things it will save you a lot of time and understanding about how these things work in terms of different patterns that you will use messaging but this allows you to have different logical boundaries not be directly coupled or reliant on other boundaries

6:08 to make calls from one to the other rather you're going to be using messaging removing some temporal coupling that you're going to be using whether it be a message broker or some type of service bus that you're using or just generally cues but using messaging as a way to communicate and deal with workflow from boundary to boundary so how does defining logical boundaries and loosely coupling between them give you options well what you're doing is you're taking a what would be otherwise a very large system that ultimately will turn into a turd pile and you're splitting it up into smaller turd piles with smaller turp piles it's easier to manage it's easier to change the internals or however that particular logical boundary works maybe you want to change the underlying database for one of these logical boundaries it's a little bit

6:54 easier to do when it's kind of compartmentalized to a smaller part of the system rather than the entire thing and with coupling instead of having all this interconnected from this logical boundary to this logical boundary and having all this reliance so that if you change one thing here it affects something else over here you're removing that you're removing that tight coupling and rather you're just leveraging messaging to pass messages to cues or topics to a broker and exchange messages that way if these are physically deployed independently you get now the benefit of that one particular logical boundary that's deployed as a service doesn't necessarily need to be available or online for your entire system to work you're just exchanging messages and each

7:39 service or logical boundary is consuming them at the rate that they consume them they are not dependent on each other being available a venture in architecture and messaging allow your system to be more extensible it allows you to add functionality without affecting other parts of the system so if you need to add some new type of functionality that you find as a logical boundary you can create that separately and then have it be a consumer to different events that it's subscribing to that provides that additional functionality so the last concrete thing you can do is apply cqrs which i always say is a gateway to a lot of options it allows you to do a lot of things at a really low cost now the problem is is that it's still being confused with all kinds of other things there's videos being made just

8:25 recently that i'm hesitant to even comment on that complicate the matter it's really not complicated all it is is separating reads from rights kind of at a application service layer that's it it doesn't mean that you have to be doing event sourcing or have different databases or you have to have a read model that's completely separate database schema it's none of that it's really is just separating reads and writes so whenever you want to perform some type of query which is a read that goes down one path if you have some type of command where you want to change state that's a right it goes down one path it may lead to the exact same underlying database it's not about data storage or the model on how you actually persist it

9:11 it's just the path how you get there initially whether you want to perform a command or a query now because it's so simple it does give you a lot of options it's kind of like a gateway like i said gateway to give you all these different things that you can do simply because you separated reads and writes the problem is is all those options end up being included in the explanation of cqrs because it does let you do so many things so for example this is very common as an illustration of what you'll see and this is applying cqrs but it's doing a lot of extra things because of those options it's giving you so for kind of separating reads and writes maybe a command comes in maybe it's sending that to some command bus that has some command handlers that has a

9:56 domain model maybe we have an aggregate and an aggregate route here and then maybe we're using event sourcing so we're publishing events we're pending events to some event stream in our event store and then asynchronously those are published some of the event bus where we're updating separately through event handler some separate read model and then our query site is using that read model yes this is applying seeker s but it's also using messaging it's also using event sourcing it's doing a bunch of other things potentially domain driven design and the concepts like aggregates and aggregate routes it's doing a bunch of things it's giving us those options but separating just separating reads and writes is what's doing that for us but it doesn't have to be this this is applying those options

10:42 it can really be just as simple to start as this to me software architecture is about making key decisions that give you options in the future options that allow you to evolve your system over time but doing so at the very beginning where the cost is relatively low to add these options things like defining logical boundaries event driven and message driven architectures and cqrs these give you options for the future to evolve your system and as always it's always about cohesion and coupling thank you to all the developer level members on youtube and patreon i really do appreciate your support they get access to a private discord server where you can communicate with other like-minded developers about software architecture and design if you're interested in joining check out the links in the

11:27 description if you found this video helpful please give it a thumbs up if you have any thoughts or questions make sure to leave a comment and please subscribe for more videos on software architecture and design thanks you