Design Principles and Standards in Software Architecture by Andy Schwam || C# Corner Conference

My name is Andy Schwamm

I'm the AVP of Enterprise Architecture in an insurance company in the Philadelphia area

I'm a 10-time Microsoft MVP for developer technologies. I'm also a conference organizer

I organized a conference called Tech Bash. You can check it out at techbash.com

And then here's some other ways you can find me, right? On Twitter, I'm Schwammie

GitHub, you can see my repost, Schwami, LinkedIn, Andrew Schwamm. I have a blog

Schwami says, all this good stuff, right? In addition, I do live streaming Wednesdays at noon

noon Eastern time. And that's probably something, you know, we're an international audience here

today, but noon Eastern time, you can find me on Twitch, Mixer, and YouTube, where I build software

with all kinds of stuff that we're talking about here today with good architecture practices and

with DevOps and everything else and web application design and things like that

Another shameless plug I'm going to throw in real quick is I'm also a host of the Dev Talk Show

The Dev Talk Show is also on Wednesdays, Wednesdays at 8.30 p.m. Eastern

where Chris Gomez, Rich Ross, and myself, we talk about all kinds of things for software developers

We talk about architecture. We talk about design. We do live demos of writing code. We have guests. Mahesh was a guest recently, and that was great. And we talk about all kinds of things. And so if you're really interested in the whole spectrum of software development, it's a great show to check out, again, on Twitch, Mixer, and YouTube, slash the Dev Talk Show

And that's all my plugs for myself. And now looking forward to talking to you guys about design principles

So I want to start out by talking about why we need design principles

So spoiler alert here, really, this is the most important part of the whole thing

Understanding why is critical. There is lots of different design principles you can choose or not choose

But understanding why is a really important factor. And not only is it important that as an architect you understand why, but it's really important that you make sure your teams understand the why

Because if your teams understand the why, instead of you just saying, hey, this is what you need to do, really focus on building up that understanding with them

OK, and when they understand the why and when everyone embraces it, you really follow these principles

You really think about these principles and you really focus on them and take it in

So it's really important. So why? Well, building software is hard. This is not a simple thing to do. It is not a simple thing to do

And in the beginning, and we were talking about this earlier, if we don't build software correctly

we can overcomplicate it and we can make it even harder and we can make it even harder to work with

It's hard enough when we do it right, let's face it. But if we start off incorrectly and we build

poorly designed software, it's hard to work with. Maintaining and changing poorly designed software

is costly. And when I say costly, I don't just mean money. I mean, yes, I mean money

But I also mean costly in terms of time and in terms of missed opportunities

If you're fixing your software, if you're spending too much time maintaining your software, you're not adding the things that the business units or the business side of the software are looking for

We're not adding new features, right? We're not giving the customers what the customers need because we're busy working on it

So building software is hard. Changing software is hard. And if we design it poorly, we have fragile code

And fragile code leads to bugs. And bugs can be costly. Again, time, money, missed opportunities

And it's really important to focus on that and to embrace that and think about that

Changing bad code is really hard. We want to design quality software

And my mouse didn't even switch. Here we go. Switch. Come on

Oh, I know why. Because I had animations in here and I'm not used to having it. So it's going down the different items

Okay, so what do we want here? This is what we want to talk about. What do we want? Well, I know I want code that is less error-prone

I want code that is easier to maintain. I want code that is easier to read, less breakable, more reusable, and more decoupled, right

And if we follow good design principles, we can get to this place, right

So now we understand a little bit about why. We understand about what we want to get. And we're going to talk about some design principles

First, though, I find it interesting. A lot of times we misuse terminology. Right

And it's really great to have a ubiquitous language. So we're all talking about the same thing

So we're all using the same words for the same things. And sometimes design principles is one of those things where we talk about the wrong thing

Sometimes people use terms like standards or architectures or implementations and all these different words and principles sort of interchangeably

And they're not really. I mean, there are different things. So design principles are not implementations. Right

And design principles are not patterns either. OK. You may use patterns to implement design principles

But design principles aren't really specific about how you achieve the goal of the principle

Design principles are guidelines to have a good design. And when we look at the design principles, it will all make sense

But I will show examples of many of these of how you can achieve the goal

I might show a pattern that you might use or something like that. But the pattern is different than the principle

The principle isn't specific to how you solve the problem. Oh, and I talked to that, so there we go

Okay. There are lots of design principles. We're going to focus on a few. Now, I don't like to use the word easy and hard, but I don't have another word to replace it right now

So some of these concepts are easier to understand. And they're great for, you know, really working with your junior developers, your mid-level developers

You really want to focus on these with people that have some less experience

Some of these design principles really take time to master. And you have to sort of study them

You have to sort of practice and work with them a while. So we're going to go through a variety of them

And the first one we're going to talk about is, again, we're starting with the ones that are somewhat easier to grasp, I think

The first one is separation of concerns. A separation of concerns pretty much says don't mix things up

Don't mix things up that don't belong together. Don't mix up things that don't belong together

So what does that mean? Well you know there some examples we can use here You know a simple example with separation of concerns is that the UI and the database logic should be separated And that may seem obvious to us you know but it not always obvious

It's really easy to bleed some of these things together, believe it or not. Now, I've seen some really bad examples of what you should not do

For instance, I've seen a database where in the columns of the database where you'd expect to see just the data

there was HTML, right? You know, brackets, divs, and all kinds of things in there

with CSS in the data. And so when you query the data

you could easily display it in the UI because it had the UI right there

And someone thought that was a good idea at one point. The problem with that is how do I change the data

without running the risk of messing up the UI part? And how do I change the UI

without really dealing with all the data? As a matter of fact, if we change the data in this case, if we change the data, we have to add the UI into it right there

And it's really just sloppy and really just messy. So we don't want to do that

Another example of separation of concerns is the MVC pattern. And I'm pretty sure Joe's going to

be talking about that one later today. MVC pattern is really just designed around separation of

concerns separate the model which is the business logic and the data access and

all that kind of stuff the view is the UI the controller is the I should say

like the orchestration the sort of glue that makes it all run together to handle

the requests I'm not going to get into the details of MVC but the point is it's a whole pattern very much focused on separation of concerns so it's really

important to look at separation of concerns. Now the next one we want to talk about is DRY

There's lots of acronyms in here. DRY stands for don't repeat yourself

Now this one is something I think one of the few design

patterns that I feel like we're taught really early on in our software development experience

Don't repeat yourself. Repeating code all over your application is problematic. We know that. We don't want to change code when we want to make a change

We don't want to have to go looking in 15 different places and looking for it all over the place

It makes our applications harder to manage. And there's lots of ways to deal with dry

Certainly we can extract code out, put it into different methods and different classes and things like that to avoid repeating it

But this is, again, is one of those ones that I think we're sort of taught early on in our software development experience

So that's a good one. Next is another acronym, YAGNI. You ain't going to need it. Don't add complexity that you may not need to your applications. Skip the wouldn't it be cool features. Keep your architecture design simple

Now, this isn't as easy as it might seem, you know, and so easily I can just state don't add complexity that you may not need

But as architectures, we have to make tough decisions. As architects, we have to make tough decisions sometimes

We know that there are more features coming down the road and we think, well, if we're designing the first feature, if I do it in a maybe a more complex way than I need today, it will support the features we need in the future

And that's sometimes a good idea and sometimes a bad idea. And so this is where experience as an architect comes in handy

You really want to focus on trying to not build things we don't need

And that sort of goes along with the MVP, minimum viable product concept, goes along with agile and all those kind of things

But we really want to be careful to not build our applications more complicated than they need to be

And that brings us to KISS. Keep it simple, stupid. Now, of course, I didn't write that acronym

I'm not calling anybody stupid except myself because I've broken this plenty of times

Just as I've broken, by the way, I should say, there's nothing in this presentation

There are no points that I'm making here today that I haven't broken these rules in any time

in my career. I have. We all have, and that's okay. Being becoming an architect is about growth

It's about learning and doing more and doing things better all the time. By no means, when

you watch these presentations from myself and from the future architects that are going to speak

today, don't think, well, God, these guys never made mistakes. They all know this stuff, and I

don't know this stuff. Well, everyone had to learn it the first time. Anyway, let's get back to Keep

The best design is often a simple design. And just because you can make things more complicated doesn't mean you should

As an architect and as a developer, I'm more impressed by simple solutions

Looking at something, when someone can do something really simply, it's like, wow, that's great

You know, I wrote that with 10 lines of code and I had this whole big thing around and

someone said, you know, there's a feature built in. All you have to do is use this one line and beautiful, right

And that's keeping things simple and focusing on the easy ways to get things done

Now, one line of code isn't always the best way to go. And key here to think about is sometimes more lines of code is better than less lines of code

And sometimes less lines of code is better than more lines of code. You know, just because you can write a whole page as a single link statement doesn't mean you should

You really want to focus on what's going to be maintainable, what's going to be manageable

and what's going to be understandable and readable. There are all these factors that go into our code

And that brings us to dry, which is don't repeat yourself. Repeating code all over your application is problematic

And, of course, repeating slides over is problematic, too. And so that was my very lame sort of dad joke there that I have dry in there twice

I know. I know. This is the kind of humor you're going to get with me today. But I hope you can hang in there and appreciate that terrible joke

So let's move on to the solid principles of object-oriented and agile design

Now, this is where I think we're stepping things up a little bit, and it does get a little bit more complicated

And, by the way, I'm trying to monitor questions in case there's any. I do see some questions, you know, does that correspond to dependency separation

I don't recall when that question came in, but we're going to be talking about some of that stuff in the next couple of slides

So hopefully we get a good answer to that. And then if not, we can come back and answer that question

I am trying to monitor the questions, but it's kind of hard with all the screens. So I'm going to do my best

So these solid principles are what I would say sort of more complicated

Now, some of them are easier to grasp, and you really want to get more junior developers on board with them early

Some of them, again, some of these are a little bit more complicated. Now, these solid principles of object-oriented and agile design, these were basically made popular and famous by Robert Morton, well-known as Uncle Bob, Uncle Bob Morton

And if you not familiar with Uncle Bob I suggest you Google him or Bing him or whatever it is that you do and check out some of the things that he says because he says some really good smart stuff He a leader in our industry specifically when it comes to principles and patterns and things like that And so about the solid principles and he didn write each of the principles but sort of you know kind of put them together into this solid principle thing

So what Uncle Bob says is poor dependency management leads to code that is hard to change, fragile, and non-reusable

Okay? And that's not what we want. Okay? Now, on the other hand, when dependencies are well-managed

the code remains flexible, robust, and reusable. When the dependencies are well-managed

the code remains flexible, robust, and reusable. Now, that's what we said earlier. That's a lot of

what we're looking for. And so these principles are things that I just focus on day in and day

out while writing software. I am just so in love with these solid principles. And many developers

are. I really see it becoming so popular now. Dependency management is the key to the clean

design. So every time I try to go to the next slide, it doesn't work. Here we go. The first

solid is an acronym, S-O-L-I-D, and the first one is the single responsibility principle

which you might see referred to as SRP, another acronym. Now, the single responsibility principle

says that a class should have one and only one reason to change

Think about that for a second. A class should have one and only one reason to change

Now, when I first learned the single responsibility principle, when I first heard of it

I think I took a slightly different interpretation, like many people do, that says a class should only do one thing

But that's not really what it says. Now, those two things are close. but that's not exactly the same

Okay. One reason to change. Okay. Because when we change code, we run the risk of breaking it

Okay. When we change code, we run the risk of breaking it

And we run the risk of breaking all the code that calls that, that calls that

and it kind of cascades down. And so it is clearly simpler to have classes and methods that do one thing

Okay. That do one thing. However, they should only have one reason to change

And what does that part mean? One reason to change sounds kind of tricky. Now, I will go into examples for these

and I'll show you what we mean by one reason to change. But by following the single responsibility principle

we write code that is easier to test because it only does one thing, right

It only has one reason to change. It's easier to read, it's easier to maintain

That also means we introduce less side effects. we sort of automatically get separation of concerns, right

Because the code's only doing one thing. And on top of that, one of the bonuses

that I always like to mention to people is you have very little merge conflicts in source code, right

Because if you have small classes and they're only doing one thing

you don't have a lot of developers in there at the same time working on different things

So that's an added bonus. Let's take a look at the single responsibility principle

and we'll really focus on the single thing to do and the single reason to change

So I have some samples. Let me see if I can get that going there

Okay, now just a warning about my samples here. These are not necessarily

this is not a program that compiles. These are just some samples that I have. They're C Sharp files, but they don't actually compile

So there might even be a mistake in there or something like that. Don't panic on that

This is not a project or a solution. My samples, and I should say

I should take a minute here to say my samples are in C sharp, but these design principles, all these design principles

don't just apply to C sharp or even just a.net, or these can be applied across all kinds of software development

Whether you're writing JavaScript, whether you're doing different languages altogether, you can use these single responsibility principles all over the place

I try to apply them to SQL when I can. and I try to apply them all over the place

Now, I do see a question from Andrew. It says, doesn't one reason to change almost mean one method per class

Almost, but we'll talk about that a little bit. I think it's a really good question

and these are some of the first questions we ask as we're learning about this. You can take it to that extreme and have one method per class

and that would be sure. I don't think we need to go that far with it

and I've even seen Uncle Bob talk about that we don't really need to

If you want to, I don't think there's anything wrong with going further to the extreme

I like to be pragmatic with how I apply these principles and how I think about them

and how we apply them and how I ask teams to apply them because certainly having one method per class really does start to get a little crazy

but sometimes it's a great idea. Let's take a look, though, first at what is not the single responsibility

And so you can see I have this little class here called not single responsibility. These files, by the way, are in my GitHub repo

On GitHub, I'm Schwami. And you can see, I think it's called design principle samples or something like that

Anyway, so this is code that looks very much like code that I've written over my career

and maybe code that you've written. And at times, I would think this was great code

So I've kind of moved on, and I don't love this code so much anymore

But what happened? My light just went out. That's interesting. Let's see what happened with the light

Okay. So the first thing is I have this join method. Let's imagine this is part of a bigger application where you're trying to join

become a member of some kind of website, something like that. Now, so the method takes a username and a password

And what do I do next? And I think it's really important to see the bad examples and it really helps tell the

tale of what we should be doing. So what do I do next? I'm going to do some validation

Now keep in mind this validation is incredibly poor validation. It's just here for showing some examples

I don't think we would really have something that says the username must be five characters

to be valid, but let's just play along with my silly examples here

So I'm saying that I have to have a username that's five characters and the username has

to be an email address and my lame way to determine that in this simple example is

oh, hey, there's an at symbol. It's an email address. Cool. And then, and this is where

it gets even really bad, my password validation says that the password has to be five characters

or more to be a valid password. Yeah, pretty lame. But that's okay. I've got validation

logic in my join method. And then I go in and say, let's check to see if the member already exists

OK, and maybe I call this members members data access thing and find out if the user exists

And if not you know I move on and I add the user and then I go on to even more which is like oh let go down here and let build a message an email message and format it Now this isn exactly robust formatting but here it is

I put the text of the email message in there. I formatted it and then I'm using this SMTP client and I'm sending it

And I think we can all agree that this class does more than one thing

Right. It does more than one thing. But what about this more than one reason to change

Okay. Well, I might need to change this class because we add an additional validation rule

I might, right? We may say, hey, this password protection policy is pretty weak, admittedly

So let's put some more password protection logic in here. And when we do that, I run the risk

and I really do, as much as this sort of seems like a simple example, I run the risk of breaking

this application when I do that. Let's take a look at a different example. What if the marketing

department comes along and says, hey, Andy, this thanks for joining message here. Well, that's nice

but that's not exactly the message we want. How about we add some style in here and some colors

and we put a little bit more message in here, and we change that. And that's an important thing for

the marketing department. But I come in here and I change that. And what happens when I change that

is I run the risk of breaking a core feature of my application, the join method

So wouldn't it be great if I can get these things separated and split apart? That's what we're talking about with the single responsibility principle

Scanning just questions here. In my opinion, contextual to what class was created

Contextual to what that class was created. Class was created. I think saying that the feature that we're trying to do should be within the context of the particular class

And so we'll talk about that. I think that's what we're going to talk about. But anyway, so let's move on to how we would fix that

Well, how would we fix that? I have another file here basically called single responsibility

And in this case, we start out, we still need that join method, right

You have to have that. And so in this case, the join method has a single responsibility

People say, well, no, it has a bunch of responsibilities. It's doing all this stuff

And I would say, well, no, the join method here has a single responsibility

and its responsibility is to orchestrate the calling of other things. Somewhere along the line, this stuff needs to get put together

needs to be composed into something. And so the join method might call upon a validator class, right

that has a validate method, right, And a membership service that has an add method and a message formatter that has a format message method, et cetera, the notifier

And what do these look like? Now, for simplicity's sake, because I don't want to be clicking around so much during this demo, I've got these classes in here together

Okay. And so in here, I have a membership validator, and it has the validate user

Now, I didn't put the code in here, but it's really going to be that same code, right

we could just come right back to that other class and drop that same code in here, right

It's not necessarily about writing more code. It's about moving that code around to different places, right

I might have a membership service that does the ad. I might have the message formatter, and its job is to just build out that welcome message

and do whatever we want to do in there. Then I might have another class that does notification

Now, let's talk again about single responsibility. This membership class has this add method

Now, we talked about, like, is it one method per class? Not necessarily

I might have a remove method in the membership service. I might have an update method in the membership service

Because they definitely would still sort of have one reason to change, right

We're changing the logic around membership. It's a gray area. This is a very slippery slope

You don't want to add too much stuff. because it starts to get too complicated

And when we look at the amount of dependencies we start to add, right, this single responsibility join method has a bunch of dependencies, right

And if I can keep the dependencies short and my class starts to not look too complicated

I say, well, add and remove are very similar. They're both calling the same repo, maybe, something like that, right

Well, then there's really not much difference between them and my risk is low

But if I start to have lots of methods in these classes, if this membership class all of a sudden becomes something that has so many things, if my message formatter class, this is a better example, maybe I have something called membership message formatting and I put a few messages in there around formatting messages for joining and moving and stuff like that

But maybe I don't have other things that users might get responses to

Maybe I would put those into a different format or class. It's really up to your level of comfort and the level of complexity

And we really want to think about sort of those different things

And I'm just looking at the questions. Let's see. So the question from Tool, sometimes design patterns seem to contradict solid

while sometimes they support it. What is better in the case of conflict

I've read somewhere that no application can be fully solidified. Yeah. Listen, this is a great question

Thanks for asking that question and sharing that with us. Everything, in my opinion, is about balance, right

It's about being pragmatic and not being dogmatic, right? And I'll talk about that a little later when we talk about standards

But we have to make some decisions. And this is where I say, listen, in this case, I'm willing to put a few methods in the same class together. Right. But it's a it's a feel

It's something that as an architect you grow into and you start to learn where you can slip on one principle and maybe not slip in another

Now, if we had the ultimate time and the ultimate money, we could probably get all these things perfect

But we have a lot of constraints upon us. We have pressure from business and customers that we need to get things done

And so there is a balance that we need to do. Now, Andrew also says you would make interfaces for each and inject based on service provider configuration

So what Andrew is talking about, we're going to come back to that. But if you look at this here where I'm using these objects, right, I'm instantiating objects here

This is not a great design for this. This class demonstrates the single responsibility principle

We will cover what Andrew is talking about with a different principle and we'll come back to that

I'm going to keep going now and keep this thing moving. So let's take a look at the next principle because this is a lot of stuff to cover here

Let's cover the open-closed principle, which says that software entities, classes, modules, functions, et cetera

should be open for extension but closed for modification. Okay? Think about that for a second

software entities should be open for extension but closed for modification

now what does that mean what that means is Open for extension. We need to be able to change our classes. We have to make changes. We have to be able to add features. We have to change things. How can we do that in a way that's safe? We want to make our classes closed for modification. Now, of course, it's never really closed. Anybody can go in there and change it

But when we design it in a way where it's open for extension, we can extend the feature

we can extend the behavior of a class without going in and changing the class

We have to be able to do that. Let's talk about a simple example first

A simple example might be something like a connection string. We don't hardwire, hopefully, we don't hardwire our connection strings into our data access code

We put our connection string out in a config file. That means that our code, our feature, our application in some ways can change without

opening up the class that uses the configuration file and modifying the class

I don't have to recompile it. I don't have to make changes to it. I can change the connection string

That's a simple example of the open-closed principle. Let's look at a more code-based example

I jump to another slide, but that's okay. I'm jumping all over the place

Here we go. Let's take a look at open closed principle. Now I'm going to start off with not open closed principle

And if we look at this, we can look at our little validation type of thing that we had

from before. I have validate user. This time it takes an account

I switched it and the account just has a username and a password. And here's that same logic we saw before. Okay

Username, password, et cetera. And so we come along and we want to say, well, I want to add another rule

I want to add some real password validation to this, let's say, or who knows what we want to add to this

The only way I can change this now is I have to come in here and I have to make changes in here

I have to do this and I have to move things around and make changes or whatever it is I want to do

And what happens is I run risks of breaking other things. Right. I don't want to break other things. Right

Now, in this case, you could argue that that's not such a big deal. Right

This is what we talked about at the beginning, finding and using good design principles from day one

On day one, you might look at this and go, oh, come on. It's not that big a deal

I can come here and change this. But we don't know where this application is going

We don't know how complex it's going to go. And so by following good design principles from day one, we can get this right

It's also good practice to do things on the easier examples so we're ready for the harder examples

Let's take a look at an open example of this. In an open example, I have this membership validator, open membership, and it has the same method called validate root user

But in this case, when I declare my open membership validator, when I define it, I pass in a list of rules

I pass in a list of rules. And then the validate method, all it has to do is loop through each one of the rules, loop through them, and call their validate method

Simple as can be. And here's an example of the rules. I might have an abstract class or something like that, or an interface that has a validate method

There's a lot of ways you can do this. And then I might have a username length rule

And here's that username rule. Simple as that in its own little validate method

I might have the password length rule. Same little logic in its own validate method

Okay. And then all I do is when I set up my validator, I pass in the list of rules, as many as I want to do

and I can just call it. Now, if you want to change a rule, I'm open for extension

I can create as many rules as I want. I run no risk of breaking the additional rules the existing rules This is open for extension And wow it says I have 13 minutes And I thought I had a 45 presentation

So we're going to rock through this stuff. I thought I had a little bit more time

Let's keep rolling here. So let's look at the Liskov substitution principle

which says that functions that use pointers or references to base classes

must be able to use objects of derived classes without knowing it

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it

You want to think about in your inheritance model, for example, we were always told to say, use an is a relationship

The class that I'm creating is a base class. It is one

But we really want to think about it differently. We want to think about, is it substitutable for it

And the classic example here of this is, and I'm going to move a little quicker through these

is the Liskov substitution principle here, which says we have a rectangle, which has a height and a width

and we have a square. And if I was focused on geometry, I would know that a square is a rectangle

It is, right? It is a rectangle in the world of geometry

But in terms of software, it is not because I might call down here and say, right, if I inherit rectangle into square, I can set the height and I can set the width

And quite frankly, this just introduces problems. Could it work? Yeah. You can be careful and you can set the height to be 100 and you can set the width to be 100

There's a lot of ways you can sort of fake your way into making this right. But the bottom line is it's not right

I can't use a square in the same way I could use a rectangle. So that's a quick one. I'm going to move past that and keep going because that's a, you know, I can sort of move on from that easy one there

Next is the interface segregation principle. And I think I can do this one pretty quickly, too

Clients should not be forced to depend upon interfaces that they don't need, that they don't use

What does that mean? Clients should not be forced to depend upon interfaces that they don't use

when we build our interfaces, here's an example of one. I might have a generic repository, and I have this IRepository interface

that my repository is going to implement. And if I build out my interface, I might have things like a find method

I might have a get method. And I might have an add, update, and delete method

Okay, sure. And I've written repositories like that many times with interfaces like that

But then you go and you say, hey, but some of the teams that are using that repository

they are read-only, right? They don't even change the data. So why should they have to implement I repository when they don't need add, update, or delete

So what if we have an I read-only repository, which has the find and the get

Okay, and you can break this down even more. You could have a find, I find

You could have an I get if you want. There's a lot of ways you can break these things down, right

But I'm showing a good example here. And then I might have this writable repository, and that one has add, update, or delete

Now, if I wanted to, and I don't have to, I could even say that the I writable repository

implements the read-only repository, because usually when you do writing, you're also doing reading

But you don't have to. I could take that off and then say you could do them any way you want

There's a lot of ways you could put this stuff together and compose these things

That is a quick example of the interface segregation principle. And last of the solid principles is the D right where it solid the dependency inversion principle And this dependency inversion principle says that high modules should not depend on low modules

Both should depend on abstractions. And it says abstractions should not depend on details

Details should depend on abstractions. Okay. So let's take a look at that, right

What that really means is we want to put the abstraction in the middle

If I look at my examples here, I have this earlier dependency inversion

Earlier here, we had this join method that had these dependencies. Now, in these cases, I'm implementing this class, this join method in this class

with a hard dependency on the membership validator, on all these things, on the message formatter

on the notification notifier. Why is that a problem? Well, the notifier may have a dependency

on something like SMTP mail, right? My membership service may have a dependency

on entity framework or something like that, right? Because this is hard coded

This is the way it's built. But if I want to have a way that I can, the problem with this now is if I change any of these things

I have to recompile everything, right? And maybe in a perfect world, we take these membership validators

and these services and all these things, and not only put them in different classes, but put them into different projects

Now, we put them in different projects, they get compiled separately. So let's say I take the interfaces of all these things

and I put them in their own DLL, and I put the implementation in separate DLLs

and now this implementation of this join method uses the interfaces, and now it's sort of like the interfaces in the middle

So here's my IA membership validator, my IA membership service, et cetera

We go down a line, and here's my version of join using dependency inversion

In this case, it's using interfaces, okay? And this project, the thing that my class here is in

doesn't care if I recompile or change the implementation of my SMTP mail to some other type of mail

whatever it is, it doesn't care about that because I put the interface in the middle

And those are the solid principles very quick at the end. And I hope I have a couple minutes here to talk very briefly about standards

And I can do this really quickly. Naveen earlier was talking about the role of an architect and how important standards are

It's really important to have standards to help solve problems, to help with collaboration

When you have great standards, and we're sort of shifting gears here, although following

good design principles can be one of your standards. The standards are great

It gives developers things to work on when they're doing code reviews. It gives them sort of a framework for code reviews and things like that

It can be super helpful for collaboration and team flexibility and onboarding

If you have a standard and you can hand a document to someone or point them in the right direction of the standards, then it's easy for onboarding

And it's great for saying, hey, we need some help on team A over here

Can somebody from team B come over? They're going to be able to look at that code within certain aspects of it

Not crazy, but they can look at aspects of that and say, yeah, I'm comfortable in this place because we have good standards

And the code looks similar. Okay. It looks similar. So I said earlier, be pragmatic

Don't be dogmatic. Think about standards that are reasonable for your developers

Don't be an ivory tower architect. Don be up there saying oh all developers you must do it in such a way right Explain to them why right Find standards that help them do their jobs and that make their jobs easier for them

and give them the room to be able to be creative still, right? And don't come up with principles

that are so rich and so hard that there's no room for flexibility

And I'm going to go right down this one. And also important to know your team, right

What do they need? What kind of help do they need? What will get in the way

Leave room for improvisation and innovation. And remember, what would you want

if you were the developer? Would you want the architect telling you how to write every line of code

Absolutely not. I know I would, right? I want to have standards that make sense

and you also want to think about how you would enforce your standards. We're going to skip that

We're going to come to a couple of quick examples, and I'm going to go through these. We have samples

Here's an example of a standard that we have. We don't say you have to write every line of code

We have some naming conventions. We have policies that say you must have code reviews

You might want to have solution project organizations. We're going to use a certain folder structure

for how we organize our files. That makes it really easy for when developers are swapping teams to come in and go, oh, I know where that stuff's going to be

I understand that. You might have a standard for logging, right? That's an important standard

I'm not telling you how to write every line of code, but I'm saying you need to log your exceptions into a central repository or we can find that information later

And then here's an example, a specific example of how I would write a standard. And I want you to just show, and this will be where I'll wrap up the standards

this will show sort of the sort of flexible approach and the way we try to approach it

We say, and this is down here at the bottom, for data access, we will use an ORM as a first choice

As a first choice. I don't say you have to use an ORM because if I do that, developers will come to me and say

yeah, but it's too slow. I have to use the stored procedure for something

And we have a standard that says I have to use an ORM. And my standard says use an ORM as a first choice

And this is a standard that works for my team, knowing the kind of code we write

It might not work for you. Don't use a standard because Andy says to use a standard

Use a standard. Find a standard that works for you. We say use an ORM as a first choice

And then if for some reason that's not working, go to the stored procedure, right

Maybe you need to do bulk inserts or something like that. That's where a stored procedure would be much better than an ORM, okay

And then the next line says, when using an ORM, your first choice will be Entity Framework

We choose a framework like that because our developers are familiar with it

Sure, some developers may know other ORMs and they may like another ORM

But what I say to them is, it's just not that big enough a reason to allow people to just use whatever ORM they want

The ORMs are generally pretty good. Entity Framework is a good ORM. And I need that ability to be able to have people come on and learn quickly

And if they have to keep learning new RMS all the time, it adds complexity

So, again, I'm choosing libraries. I'm choosing frameworks as part of my standards

And, again, it says first choice entity framework. It means if there's a reason, if there's a real good reason why you can't use it, come to me

Let's talk about it. Let's use the other one. And now I think that brings me back to just that wrap-up slide

I don't know if we're going to talk or not, but this is just in case people want to remember how to contact me

Thank you. Sorry I was going really fast at the end. I think we're a little short on time. But I am I see Magnus joining in. Hello, Magnus. I see Mahesh. Mahesh is on mute

Thanks. I hope that was fun. I hope you enjoyed that. I had a good time