 Thank you, so yeah, so my name is Micah WP scholar is how you find me just Google that you'll find me So basically I work at Bluehost and so I'm lucky enough to get to contribute to core Most of the time I spend is contributing to core as well as I work on some internal stuff for Bluehost before that I was Doing a lot of enterprise WordPress Development so That was a lot of fun very interesting was able to you know Flex my architecture and and WordPress muscles I guess So yeah, so we're going to talk about the basic principle software architecture So this the point of this is not to go super deep but also Try to focus on the the key aspects of really thinking through and putting Software together in a way that will make sense and be robust and more forward thinking So if we look at the overall software development life cycle We kind of have these five basic parts right we have the requirements, you know, what is it that we're trying to build? You have the design. How should we build it the implementation where you actually do it? Qa, which of course is checking to make sure you actually did what you wanted to do and then Maintenance is trying to essentially keep it effective keep it long-term effective for the client so most of the time when you work with Agencies or people who are just kind of get stuff out the door a lot of times They just do the things that are on the top they give you the requirements You build the thing and then they maintain it right and so the the whole bottom half sometimes gets skipped over No agencies like to cover their rear so they'll Throw in some qa, you know some basic qa or something But a lot of times the design of you know, how should we build this thing before we actually get started on it? It's overlooked and so really just making space for that That stage is probably one of the biggest things you can do to go in the right direction with designing your systems, right? actually design them so But outside of that taking a look at what are the key things that clients care about? Will help us to kind of focus our efforts in the in the right direction So one of the first things that obviously all clients care about is what things cost, right? If it's too expensive or maybe too cheap They're a little leery about what they're going to do And then they care about the timeline if if they're expecting to get something done in a week They want it done in a week not in a year not in a month But at the same time there are certain things that are definitely going to take longer And then of course the effectiveness right so the effectiveness for the client now All right, is it going to work for them immediately? Is it going to work for them a month from now? You know and then after you leave is someone else going to be able to continue to maintain that effectiveness in the the business be able to Make money continually off of whatever it is that you've built so the first two things the time and the cost are heavily impacted by the points in the design phase or Implementation or delivery phases here in which things happen right so the earlier that a change to the requirements or And sometimes it's not just a change to the requirements. Sometimes it's just identifying that requirement that You know kind of went undetected right it was an unspoken the client assumed something But you know until inquiring minds come along and ask the right questions We don't know about this particular thing and it could heavily impact how we design our software So the earlier in the stage the better so if you can catch it in the design phase You'll be able to Make your change quickly and easily because it's all just on paper. It's just documentation No code has been written. No qa tests have been done But if you detect it during the implementation phase which of course if you've already skipped the design phase and not done that at all You're already behind on the curve right so So if you catch it in the implementation phase It's going to cost more money because you've already written code you have to go back and change it As well as making sure everybody's on the same page about the fact that it changed Maybe you got three developers on the project now not only do you have to have somebody change the code But you have to explain to the other developers why the code change and then at the delivery Obviously that is what it's going to cost the most time and effort to change it and so and Of course really the What we're talking about here is most of these changes Are just going to take lots of time and so that translates not just to Extending the timeline, but also to the cost of the client for all the hours and work that goes into it so So really the the time and cost we kind of understand how that works We understand that we have to catch these things early So that kind of leaves the biggest kind of open-ended thing as the effectiveness, right? What makes something effective? How do we keep it effective? How does that work? So in order for something to be effective first it actually has to solve the problem, right? The client comes they have a problem We have a solution And then once we've put the solution together We want to make sure that it's easy to maintain long-term, right? So if we can create a solution that works today, but you can't actually Make any changes to it in the future that is going to be worth Not a lot to the business because they're going to have to rewrite it and pay more money all over again later to redo it So we want to make sure that we focus not just on the now but on Making sure it's easy to maintain and and to some degree You know we see this a lot in WordPress where somebody Creates a theme or some sort of thing for a client That client is happy, but then they decide that Maybe things aren't performant or it's not exact. They want to make some design changes Problem is that the developer who did it is now busy or off doing other things So they have to find somebody new the new developer says, oh, I can't can't that's that's not why we work how we work We're going to just scrap this and start over so you see it a lot more than Once you start thinking about it where we kind of get something that solves the problem now But it's not easy to maintain other developers don't know what's going on with it You know, they've got so many layers to the system so much complexity that no one else wants to work on it So that's part of the the problem that we have to resolve. So there's an equation It's a real simple equation. You just do it in your head Actually once you get more familiar with this it is something that you can kind of process a little bit in your head But having an equation where you can actually put dollar signs on all of these variables and be able to calculate You know when evaluating two different options What you should actually do or whether one solution is better than another? It's good to have this in your back pocket. So this is a an equation if you want to know where we found it It's a there's this great little book called code simplicity at the end of the slides, which I'll share out after I have a list of books and things that I would highly recommend if you're interested in this topic But essentially what this says is that the desirability of a change is equal to the value of that change now plus the value of that change in the future Divided by the effort of implementation plus the effort of maintenance And the reality is that the effort of implementation is typically pretty low Considering it's the effort of maintaining something long term That is really the determining factor as to whether or not a particular change is a good solution or not so you want to make sure that That as you're making changes you have that focus on Maintainability in the future So practically, how do we focus on that? Maintainability aspect, right? How do we lower that portion of the equation and make all of the changes that we do more desirable? so one thing just to keep in mind this isn't really like a Well, so technical debt is one of those things that you hear about Where essentially technical debt is nothing more than you've taken shortcuts in the code and Ultimately what's happened is? Those shortcuts are costing you in maintenance, right? So those shortcuts are causing complexity in the code Difficulties where when you go to maintain that code you have a hard time reading that code Understanding that code being able to put additional Layers on top of it plug into it those kinds of things so technical debt just like a high credit card APRs will kill you so you want to make sure that for one try not to take those shortcuts try to Focus on those things that will prevent you from incurring technical debt And some of those things are just keeping certain things like this in mind So the law of change basically what this says is that? The longer that your program exists the more likely that any part of it is going to have to change and this is relatively obvious, but When you think about it You know these these are they call them laws because essentially there's really no way around it, right? The longer the program exists the more features the client's going to want the more things are going to be put into it And the more likely you know it's going to change So we also have the law of defect probability. So this is Because of the law of change, right? So we know that things are going to change So this law basically says that the chance of introducing a defect is Proportional to the size of the changes that you make right so when we have an option to Add a feature and we can make a change that's small or we can make a change that kind of affects Multiple files in the code as opposed to just one the chances of defects go up Significantly if you have to touch five files as opposed to touch just one so again as you can see these are Starting to make a little bit more sense as we look at them And then we have the law of simplicity which basically says that the ease of your maintenance is proportional to the simplicity of the individual pieces So the simpler we can make of the individual pieces the more confined we can keep the logic and prevent things from touching multiple files or spanning across Classes all over the place then the easier maintenance will be So when you're designing a system simplicity is key You want to make sure that it's easy to understand easy to modify and then easy to test So those sound simple, but there are some things that will definitely help you do that better So one of these is self-documenting code. I think Most people get the concept of naming things clearly and that kind of thing a lot of times we'll write functions and we'll put a Documentation just above that function in the code that kind of documents what that code does And then what happens is somebody will come and change the code and not update the documentation So what you end up with is documentation that just lies to you And you know, it's it's an easy mistake to make right you forget to update the documentation You make a change you just want to test it make sure it works before you actually go changing documentation So it's easy thing to forget So really the best thing that you can do is make sure that the code itself is Documenting itself as much as possible and the way that you do this is just making sure that instead of using vague or super abbreviated variable names or function Names that you make them maybe a little longer just to make them a little clearer, right? So if you're reading an if statement and it says if false equals stir pause You know dollar sign Post whatever You know, that's hard to read But if if you've created a little function that has a very clear name like if You know if post type is Or something like that and you and you have that function then when you write your if statement now You're saying if this post is of post type It's a little it's a lot easier to read so clear naming Sectioning those things off into small specific functions that you can use In ways that are just very clear and easy to read Because we all know that in six months we're going to have to come back and change this code and if you can't understand it God knows no one else will understand it either so So then this is another big one here is making sure that you limit the cognitive load so this is important because Studies have been done your brain can only hold so much in memory at any given time, right? So we've probably all encountered Software solutions where you end up Starting to dig into a problem and you realize okay, so we have this this thing here I understand this but it's somehow linked to this little function over here So let me look into that but that little function links off to this thing here and that thing there And then those two things happen to link out somewhere else which circles back around here But this one goes off somewhere else And so in the end you're sitting there. You're like, okay, so wait a minute Well, where did we start and so it's really hard to keep track if if you have this wide spanning Array of things right so consolidating the logic Into one place makes it a easier to follow and limits your cognitive load because you can only keep so much in your mind This is why when we do code review They say to limit your code review to 200 lines of code if you get more than 200 lines of code in a code review You're going to get really bad code reviews people are going to miss things I've seen plenty of code reviews come through where somebody just had a die in the in the code And they forgot to take it out, but nobody picked it up because they had submitted a thousand line Change and somebody was just kind of reading through it and it's easy to miss that kind of thing right so if you can limit the cognitive load It'll make it a lot easier to understand the system It'll make it a lot easier for other people to understand the system. Some people are better at having more in their mind of the system than others So we want to make sure that even if we happen to be Have that particular ability that we try to restrict that as much as possible The other thing is making sure that we have clear boundaries, right? So if we have clear boundaries in our system That means that we're not going to have Multiple things that span off into other other classes or other modules or other things like that We'll have clear boundary where this module connects to this module, but only by this one particular function call or simple API And it'll be a lot easier to Mentally track that so that is a big big thing to keep in mind We've all heard this don't repeat yourself so I Like to start with this Latin proverb repetition is the mother of learning Repeating yourself is good when you're learning, right? But every programmer ever will tell you don't repeat yourself So, you know you write code somebody says I see you have the same Conditional here as you have here Why don't you create a function for that conditional and use it in both places? And in certain cases that makes sense, right? But this is there's a myth the myth is that if I was a good coder Then all the code I would write would be dry and there wouldn't be a need for all this Repetition, right? So we all encounter repetition in our code And sometimes we allow it sometimes we don't And in certain cases, it's actually good when we take a look at where this rule essentially came from Back in 1960s, I believe it was the book the pragmatic programmer Is basically where this came from so it says that every piece of knowledge must have a single unambiguous authoritative representation within a system So when we read that we we don't instantly think oh the dry principle, right? It's a very different statement But so I thought a thought a bit about this and I think there's some clear Distinctions to be made when you're thinking about repetition in your code So the first is that the dry principle really applies mostly to the duplication of knowledge So duplication of knowledge is a violation of the dry principle However duplication of code in general meaning well Duplication of code in general is not a violation. So the difference there is that knowledge is essentially data business logic algorithms anything that is essentially related to the business domain is Important business logic that should not be replicated if you think about a shopping cart if you happen to have the Shopping cart page and the checkout page and you have the logic for let's say removing an item from the cart or the You could do that from either page, right? If the code for each Page ran a different function to remove the item you are duplicating the logic for removing an item from the shopping cart and Obviously in doing that the next piece of logic you need to add related to removing an item from the shopping cart a Developer may only do it in one place and then you have different logic happening in two different places So this is very easy to do But it is important to create the distinction that code includes variables code structures and function calls Which it is perfectly fine to duplicate So if you happen to have for example an MVC structure that you use and maybe in one case you have a display for One particular post type and a display for another particular post type a lot of times when you see two post types that are very similar, it's very tempting to merge those data structure or those code structures together Because the logic and everything appears to be the same But so there's kind of two sides to the coin here So the first one is something called premature optimization So this is where you essentially apply the dry principle before you need it And so you assume that there will be a Or assume that there's a duplication of knowledge and that you should Fix it before it happens So that's kind of applies to the Yagney principle you ain't going to need it And then we have essentially the opposite side of this which is where we Apply to our coding structures the dry principle when really They they do have different applications, right? So if you have Kind of this MVC structure or something for two different post types Eventually those post types will get different business logic and now you've automatically coupled all of the code for Both of these post types and now you have to undo that in order to add the features that you need to add so Obviously you want to make sure that you Create that distinction between duplication of knowledge of logic as opposed to coding structures in general and so we see this a lot with Wordpress where we have function calls like register post type You know so that we we will call register post type for obviously multiple post types and that code is very similar But it is very different at the same time because we're creating different post types. They have different requirements So those structures are are different. So, yeah, here's the you ain't going to need it So try not to prematurely optimize your code, but also don't Inadvertently couple things that are that appear to be similar, but are not actually the same And then we have the most misunderstood Solid principle in existence, which is the single responsibility principle Everyone assumes that the single responsibility principle based on its definition Means that You should have a function that does only one thing or a class that does only one thing and while this is true You should limit the scope of your methods or functions the scope of your classes and make sure they're very cohesive So keep cohesiveness is very important when you're coding So you're not entirely wrong if that's what you think about the single responsibility principle of the real Logic behind the single responsibility principle is that a class or module should have only one reason to change and what that means is Let's say you have let's say you have code That is going to render a report So you've got the actual content of the report that could change you've got the actual display or formatting of the report That could change and if you put all that logic together and you generate the content for the report and display it in a particular format all at Same time Then there's two reasons that code could change one could be they want it to look different One could be the content of the report needs to change the formulas the logic that kind of thing And so if you put those two things together Let's say you wanted to you know a new feature came about Oh, we actually need to generate the same report, but in two different formats. Well now you've coupled two things that shouldn't be put together So that is the real application of a single responsibility principle And it doesn't just apply in those types of concepts it also applies to the types of changes that people or departments might request right so if you've got a For example a class that handles logic for Working with the loans for example, so you've got a a bank they have loans they have logic related to the loans or You know you might have a CFO that will make certain decisions you might have CTO that'll make certain decisions And so they'll have it's important to kind of create distinctions as well As to you know who might be requesting a change And usually what departments are making changes will kind of map to things like the formatting of a form of a report or The content of a report So it's just important to kind of think through as you're looking at your code, you know who Are the stakeholders what types of changes or responsibilities do those particular people or departments have And how will that play out in future changes to the code? another key principle is The open-close principle this is something I think wordpress does very well for example with the plug-in system and the Actions and hooks and things that we use in wordpress make it easy for you to at any point in wordpress Kind of run your own code or modify variables and things inside of wordpress Is the open-close principle right so we don't modify wordpress core directly But we can extend wordpress through plug-ins To be able to do very different things with wordpress, and that's part of the beauty and the power of wordpress itself and in reality when we look at the open-close principle if we have a solid architecture where we've created clear boundaries and clear ways of Extending the code We'll be able to have better application of the open and close principle so for example Let's say you've got Let's say most most of the time when you create code you're trying to create clear boundaries between different types of things So you've got for example the UI what the user sees how how things are being displayed You've got the business logic, which is kind of another layer that's often in there. You've got the The data storage and all those different kinds of things and then a lot of times you'll kind of have more vertical Splits as well where you know, maybe you know in a shopping cart you say well, this is all related to products This is all rated to the checkout process. This is all related to You know Something else so we have all these different boundaries and things But you want to make sure that As you're creating the system that it's easy to Extend and there's many ways you can extend code, right? We have classes that can be Extended we have composition where you can take Traits or use functional composition to to add in code to existing classes things like that But then we also have a very easy way to do that in WordPress, which is the hook system So not only does WordPress have its own way of creating hooks Actions and filters, but of course you and your own plugins and things can do that as well and at the same time we can Create modules and things if we use tools like composer we can create entities software entities that we can Use as dependencies and easily extend or leverage those in our code as well so the open-close principle is Something that WordPress does well, and I think that in general as we're thinking about Creating a good system. It's important to keep in mind So we're going to take a closer look here at modularity for a second So we have Again, one of the first things that you should think about is make sure you have clear boundaries So your modules should very clearly You know pertain to a particular aspect so we're talking about cohesion, right? So we want to make sure that we have Cohesion within our modules that we're not putting things that don't go in there that we're splitting them out into the right pieces So we also want to make sure it's decoupled and obviously when we're talking about boundaries The assumption is that it's decoupled, but it's very easy to create tightly coupled modules Even though there's clear boundaries And one of the ways that that can happen Well, I'll get to that in just a second so it's easy to couple things Inadvertently so it's easy to write a module that assumes that other modules will be there And so you want to make sure that you have a very clear and clean API Again that clearly defines those boundaries continuity is just a Reinforcement of kind of the single responsibility principle. So continuity basically means that when you have a module and Someone requests a change Changes that are requested should only impact a small a single module ideally or maybe a couple of adjacent modules in minor ways so What that means is that you've properly mapped the responsibilities of your Code to The reasons why the code might change and so continuity basically says, you know If the CFO asks for this change then we've properly modularized the business logic or the display logic or whatever it is So that it only affects that one particular module that one particular class or whatever it may be and then we have protection and Protection is one of those things where if done incorrectly it actually makes it Less clear what the boundaries are for our module as well as allows you to Even though you've created a module that you seem Seems to have clear boundaries allows those boundary lines to become blurred is if you don't properly protect your your module right so let's say you have a class and It's very common for people when they create classes to Instead of marking particular property properties as protected. They'll just write public, right? And so all the things are public well now instead of having to use the very clear and clean Collection of methods and things for that particular class Which would create clear boundaries prevent a coupling of things that shouldn't be coupled Well now another module can reach directly into your module using the public access that you've left behind And they can do things that they really shouldn't be able to do But because you know as developers we like shortcuts And if it's easier to go straight into it and manipulate it how we want then that's what we'll do So if you don't properly protect your module then that's that's where your boundaries get blurred. That's where coupling kind of sneaks in and Essentially, you're sabotaging your own code. So you want to make sure that you think about, you know, what is the public API? what is the Think what are the things that need to happen behind the scenes and make sure too that we limit as much as possible the public API? Because the larger the public API the more complicated Change would be in the future so and just another oh Yeah, and then of course extensibility talking about the open-closed principle I'm not going into all of the solid principles because I think they're a little some of them are a little deeper I'll probably do a talk later on all of them at some point, but But yeah, so we have extensibility We want to think about making sure that our modules are easy to extend with custom functionality Or maybe even you know hooks filters using some sort of event-based system as well But without changing the actual code itself. And so now we have the reuse release principle Which to me is a very important principle because as software developers one of the things that we do over time that really helps us Get better at what we do get faster at what we do and Continue to I guess further our career is You know we start out building things from scratch we learn how things work We start to write cleaner code We start to realize there's patterns that we use over and over again, and then we realize that We use these certain patterns so much that we could actually abstract them and turn them into modules or turn them into You know different plugins or things and we can reuse them, right? But the reuse of those things is only as valuable as the tracking system in which you put them so For example on wordpress.org. We have a tracking system for plugins. We have plugins. They're all versioned They're all in one location. It's easy to find easy to get a particular version It's easy to update and so that code is very easy to reuse If we have for example github and we put our plugins there That is good It's a good tracking system, but again, it's one of those things where it's more difficult to pull our code in directly from github You know, we're not we're not reusing those things in mass Through github right no no clients going to say oh, I'll just clone that get repo and use your plug-in, right? So a lot of times that we know that's where we we have our testing grounds for plugins that we don't want clients to use But we want developers to use right so it's a good system for that, but it's not good for for the user But really as developers we are users, right? Like we we need to reuse our code and we need to make it easy on ourselves to do that and it's not practical to Have a project that you want to have version controlled and then to try to clone Seven or ten different get repos in that and then you can't track those things because they're sub modules And but you don't like get sub modules so that you have to remove get from those things it gets complicated So that's why we have awesome tools like composer. So if you use PHP, there's composer If you use JavaScript, there's npm node package manager, right? So you can actually From npm Grab any JavaScript module that exists out there. You can pull it into your project It's real easy to do with command line and now your JavaScript's in there and you can start to use it Just like you do that. We have composer all of the things live up on packages.org. They could be registered There's a cool little project called w packages.org where all of the wordpress.org plugins and themes have been Composerified for you and are ready to use and pull into your WordPress projects And likewise you don't it doesn't have to be plugins or themes that you package up It can be individual libraries that you use for example one that I've created is a WordPress post expiration module, right? So a lot of times you have a client and they request that You know, maybe you're creating promotions for them as a post type. They want to be able to expire it Maybe they have ads they want to expire. Maybe they have news articles. They want to expire whatever the case is All I have to do composer require my package add a single line that says Add post type support expiration for particular post type and now That thing will automatically have the user interface for post expiration And we'll automatically have the cron set up to expire those things And I don't have to do anything additional and that automatically give me packaged into a theme packaged into a plug-in So whatever custom theme I'm built thing. I am building for a client. I can easily reuse that and of course everything on Packages or used via composer is also versioned so understanding semantic versioning is very important making sure that you Understand the differences between the Breaking changes non-breaking changes feature additions patches all those kinds of things If you want to learn more about that you can go to simver.org and learn about semantic versioning So you can properly manage things that are tracked in version control So reuse release principle very important But this is kind of my favorite quote So there's this book called clean architecture Robert Martin also known as Uncle Bob has written and His quote is that a good software architect will delay decisions for as long as possible I used to think that software architecture was knowing all the things and making them all work together perfectly and really it's not it's all about Delaying decisions as long as possible and what that really means is let's say you're writing some software You start with the the business logic you start from the inside you work a way out When you're designing business logic, you do not need to know where the data will be stored You do not need to know what the user interface will look like You do not need to know nor do you need to create any of those things You just need to design the business logic and create some basic tests for the business logic And the business logic is anything that Outside of let's say the web or any kind of software Business logic is the thing that is at the core of the business, right? So if you are a bank You extend loans to people You know you create accounts You have all these different things that you do and it doesn't matter whether you have an online system or not Those things are going to happen. That is core business logic Extending beyond that we have use cases So the use cases are the things that apply specifically to an automated system that Operate on that business logic. So being able to create an account online or to request a loan Online those are use cases that interact with the core business logic of The business right so you want to make sure that you Start with the business logic Delay the other decisions about how to create a account online or do these different things within the automated system until the business logic has been sorted out and is Meets requirements, so then you have these use cases and we still don't care about where the data is stored what the User sees when they go to create an account all we care about is that the automated system can handle and manage What's going to happen there and then from there? Finally, we'll start to make decisions about where the data is stored whether or not we use WordPress All of those things are actually irrelevant until you get to the point where you really need to make the decision And that decision may change Later, but again talking about delaying decisions if you make them before You've implemented them. It's going to be a lot easier to do a lot simpler to do And if you've written your code in a way where it will allow you to delay that decision Then you're actually doing it correctly because You are also Causing so if you start with that business logic work out to the use cases work out to the to the interfaces Essentially, you're you're automatically going to properly Set up your dependencies for your software, right? We don't ever want to have the business logic depending on Where the data is stored or how the data is stored? We don't want someone to say well the process of a creating account depends on whether the MySQL database is available If that is the case, then the business logic has a problem, right? But if you start from the inside out and delay all those decisions Then the business logic will never depend on the MySQL database The business logic will never depend on what the user sees or how they interact with the system It will always just work the way that it's supposed to And so these are the resources that I would recommend Sourcemaking.com is a good website Do factory.com JavaScript design patterns There's a great book on PHP design patterns clean code and clean architecture. That's Uncle Bob or Robert Martin Really good books code simplicity. That's the one where that's Formula and a lot of these laws and principles that you saw on some of the slides came from And then refactoring so if you ever do any kind of heavy refactoring or taking legacy systems and converting it into You know more modern structures and proper architecture. That's a good book to read. So Yeah, so that's my talk. I think we got how much time we have for questions Five minutes so Any questions Yeah Makes When you start reading about the startups and how you want to get first to the market and that's the idea they say called fast put to the market and that the user's task Which kind of goes on the opposite direction of what you're saying is there a balance on when you should really cold fast Put on the market or you believe that that's the only right way to do it Um, so yeah, so the question is, you know, when is the right time to code quickly get something to market? So that you from a business perspective can leverage the Yeah Yeah, getting to market first as opposed to doing it right maybe come to market a little later And again, I think it really depends To a certain degree if we look at the competition, right if they're doing the quick and dirty version Then what they're ending up with is a system that works now But it's going to be difficult to maintain and so as a startup if you focus on doing it, right? And the logic is there and the dependencies are set up correctly Then your system is going to be easier to maintain easier to add features long term Which means you could outlast the competition now granted there is a benefit to come into market first But really I think This particular process of starting from the inside and working your way out making those decisions later Can actually give you more flexibility coming to market first Because maybe you realize that there's a new technology is coming out. You don't sure if it's going to work yet You need to give it a month You can delay that decision whereas somebody else is trying to get something out the door They just go with what they know and then it turns out that the technology decision was brilliant one You can transition Or maybe that was flipped around and you need to update to the new technology because you've built your system this way There's not that Dependency that shouldn't be there and it makes it easier to just swap out this technology with this other technology So Personally, I think it makes a lot more sense to start from the inside out build it But but really I would say the rules are It's okay to build it quick and then to build it right But if you if you know you're never going to get around to building it right then just build it right So yeah, it's kind of my my rule of thumb I guess So list those things again one more time So yeah, so the way I would kind of approach and the question is you know, how would you build it's a you said It's a membership type site where you have events you have locations and you have one more thing User profiles right So really if you think about it from a community perspective Let's say you actually physically met up in person or have events, right? Which essentially you would be doing I guess unless they're online events There's there's that that business logic of you know, we have an event You know an event is an entity within the system The event is going to have a date. It's going to have a time It's going to have these things you can create code that just manages that particular entity or Portion of the system, right? So you're going to have that event entity You'll have the location entity. You'll have the user entity and the fact that it's a profile is really more of a data rendering aspect So you'll start with those things and then of course the automatic the the use cases would be updating my password You know creating events in the system online Those are the those are the use cases. They're not core business logic They're related to the automated system. So you start with the the core entity You build out those use cases and then you say, okay I know what a user looks like and what can be done with a user I've created the automated tools that allow me to create a new user delete a user change a password manipulate that particular entity and Then work in your way out from there saying, okay. Well, what is the profile display going to look like? You know create the view or template or whatever for that And then where's that data going to be stored how I'm going to work with it, you know and so, you know wordpress obviously has its own tools and things that you can use for some of that, but again, you should look at WordPress as a technical detail So WordPress just like anything else is not core to the business is not Really specifically related to that particular use case. It may be a tool you use to implement the use case But it's on the outer fringe of the design. So Yeah, so the yeah, so the question is what is the difference between a Between business logic and a use case So business logic is again something that would happen regardless of whether or not we have a Web system or some online tool or software tool so So for a user to exist right users have names You know, you there's certain information that you as an organization care about when it comes to that person So if it's something you write down in a notebook whether or not you had an online system or not It's probably important and something that you should keep track of within the the person or member Entity and then, you know for your events, you know, what are the things that you would be marketing whether or not you had a website So those are the things that that are core business logic And then the things that allow you to work with WordPress to manage those things. Those are use cases so yes being able to log into WordPress and Create a new user that is a use case So the user is the core entity creating that user is something you do through the automated system You know that user would exist regardless in real life, but But the automated system aspect. That's where that use case comes in