Update 2024-10-25-vsa.md

_posts/2024-10-25-vsa.md

@@ -69,39 +69,42 @@ Wrapping up, the problems stated above aren't problems with Layered / Onion arch
 Quoting from the book "A Philosophy Of Software Design" section 4.6:
 
 > Unfortunately, the value of deep classes is not widely appreciated today. The conventional wisdom in programming is that classes should be small, not deep... developers are encouraged to minimize the amount of functionality in each new class: if you want more functionality, introduce more classes... result in classes that are individually simple, but it increases the complexity of the overall system. Small classes don't contribute much functionality, so there have to be a lot of them, each with its own interface. These interfaces accumulate to create tremendous complexity at the system level.
-> 
-> ...
->
-> The most important issue in designing classes and other modules is to make them deep, so that they have simple interfaces for the common use cases, yet still provide significant functionality.
 
 ## How VSA solves these problems
 
-VSA is really not a new idea, but an application of the KISS (Keep it Simple Silly) principle. I'm not explaining how VSA works here because there are already many good articles online, and instead I'll only highlight some key pointers about how VSA solves the above problems.
+VSA is really not a new idea, but an application of the KISS (Keep it Simple Silly) principle. I'm not explaining how VSA works here because there are already many good articles online ([example](https://www.milanjovanovic.tech/blog/vertical-slice-architecture#what-is-vertical-slice-architecture)), and instead I'll only highlight some key pointers about how VSA solves the above problems.
 
 1. Quoting from a [practitioner](https://www.reddit.com/r/dotnet/comments/lw13r2/comment/gpeuc0l):
 
     > You can build onion in each slice or for lower levels (domain persistence, accessors) as it fits... start simple and don't over engineer it.
 
     It's crucial to note that the success of this approach still depends on Software Engineers having good understanding of software engineering principles and applying it appropriately; VSA is not an excuse for poor code organization.
 
-2. Avoid code sharing by default. This change in mentality affects the quality of shared methods: When code sharing is heavily encouraged, there's greater tendency to modify code to make it reusable even though the usage isn't too similar. When code sharing is avoided by default, the tendency is to only share code when the callers are really using it for the same purpose, so you don't end up with shared code that looks like the above example.
+2. Avoid code sharing by default.
 
-    So, for example, you might end up having a folder structure looking like this:
+    a. This change in mentality affects the quality of shared methods: When code sharing is heavily encouraged, there's greater tendency to modify code to make it reusable even though the usage isn't too similar. When code sharing is avoided by default, the tendency is to only share code when the callers are really using it for the same purpose, so you don't end up with shared code that looks like the above example.
 
-    ```text
-    Users
-    |-> Create
-        |-> Endpoint
-        |-> AwsClient
-    |-> Update
-        |-> Endpoint
+        So, for example, you might end up having a folder structure looking like this:
+
+        ```text
+        Users
+        |-> Create
+            |-> Endpoint
+            |-> AwsClient
+        |-> Update
+            |-> Endpoint
+            |-> AwsClient
         |-> AwsClient
-    |-> AwsClient
-    ```
+        ```
+
+        Having 3 `AwsClient` files is intentional: Instead of having a mega `AwsClient` file that contains all the methods for operations related to Amazon Web Services, the `Users/Create/AwsClient` file only contains the operation that's used by `Users/Create/Endpoint`, similarly for `Users/Update/AwsClient`. There might be shared code used by both `Users/AwsClient`, so a possible implementation is to have `Users/Create/AwsClient` and `Users/Update/AwsClient` inherit from `Users/AwsClient`. As more features are added into the codebase, the functionality in `Users/AwsClient` might be reused, so the relevant code will be "promoted" into a higher level `AwsClient` file.
+
+        So, keep code local as far as possible, and only "promote" them to higher levels when there are real instances of code reuse.
+
+   b. Quoting from the book "A Philosophy Of Software Design" section 4.6 again:
 
-    Having 3 `AwsClient` files is intentional: Instead of having a mega `AwsClient` file that contains all the methods for operations related to Amazon Web Services, the `Users/Create/AwsClient` file only contains the operation that's used by `Users/Create/Endpoint`, similarly for `Users/Update/AwsClient`. There might be shared code used by both `Users/AwsClient`, so a possible implementation is to have `Users/Create/AwsClient` and `Users/Update/AwsClient` inherit from `Users/AwsClient`. As more features are added into the codebase, the functionality in `Users/AwsClient` might be reused, so the relevant code will be "promoted" into a higher level `AwsClient` file.
+       > The most important issue in designing classes and other modules is to make them deep, so that they have simple interfaces for the common use cases, yet still provide significant functionality.
 
-    So, keep code local as far as possible, and only "promote" them to higher levels when there are real instances of code reuse.
 
 ## Further Readings