Update README.md

README.md

@@ -112,7 +112,7 @@ Also here I used cqrs to decompose my features into small parts that makes our a
 - Easy to maintain and add features to. Changes only affect one command or query, avoiding breaking changes or creating side effects.
 - It gives us better separation of concerns and cross cutting concern (with help of mediatr behavior pipelines), instead of bloated service classes doing many things.
 
-Using the CQRS pattern, we cut each business functionality into vertical slices, for each of these slices we [group classes](http://www.kamilgrzybek.com/design/feature-folders) specific to that feature together (command, handlers, infrastructure, repository, controllers, ...). In Our CQRS pattern each command/query handler is a separate slice. This is where you can reduce coupling between layers. Each handler can be a separated code unit, even copy/pasted. Thanks to that, we can tune down the specific method to not follow general conventions (e.g. use custom SQL query or even different storage). In a traditional layered architecture, when we change the core generic mechanism in one layer, it can impact all methods.
+Using the CQRS pattern, we cut each business functionality into vertical slices, for each of these slices we [technical folders structure](http://www.kamilgrzybek.com/design/feature-folders) specific to that feature together (command, handlers, infrastructure, repository, controllers, ...). In Our CQRS pattern each command/query handler is a separate slice. This is where you can reduce coupling between layers. Each handler can be a separated code unit, even copy/pasted. Thanks to that, we can tune down the specific method to not follow general conventions (e.g. use custom SQL query or even different storage). In a traditional layered architecture, when we change the core generic mechanism in one layer, it can impact all methods.
 
 ## How to Run