The first thing to remember is:

“There is no one perfect architecture for all applications”

How you choose an architectural pattern is not the first thing, but rather what problem you want to solve with your architecture. Taking the time to understand the problem you are trying to solve will help you focus on the features of the architectural pattern that really work. Follow these steps to ensure that your architecture is effective:

  1. Grasp the current state of the code base
  2. Identify the problem you want to solve or the code you want to optimize
  3. Evaluate different architectural patterns
  4. Try out some of these patterns to see if they fit before making your choice
  5. Define an architectural baseline for your application and establish relevant boundaries
  6. Go back and see if your architecture effectively addresses the identified problems
  7. Keep up with The Times, iterate and refine your architecture

Location problem

Generally good architectural design practices address two main problems: slow development efficiency and weak code quality. Inefficient low quality results when you encounter the following:

  1. I can have trouble reading the code in the code base
  2. I sometimes make changes to the code that bug the original functionality
  3. My application runtime is very fragile
  4. My code is hard to reuse
  5. My changes will result in massive code refactoring
  6. My colleagues have a hard time co-developing in parallel
  7. I can’t write unit tests for code
  8. My team had a hard time breaking down a requirement into small work items
  9. My application takes a long time to compile

The root causes of these problems are usually two: strong coupling and large types. Strong coupling refers to a large amount of highly dependent code in the code base. Variables, types and objects are directly connected and accessed without protocols and interfaces. As a result, all dependencies depend on each other. A large type is a class, structure, protocol, or enumeration that has a very long interface definition (properties and methods). It is much easier for developers to add methods to an existing class than to create a new one.

In addition, a good architecture can help us decouple, increase the flexibility and agility of our applications. This allows us to respond quickly to changes in technology and requirements. Your current codebase is not agile enough when:

  1. I found myself stuck with a technology/implementation
  2. I was faced with a major technical/implementation decision early in the project
  3. I find it difficult to add functional switches

Selection of the architecture

Once you have identified the problem, the next step is to investigate various architectural patterns. The good news is that there are plenty of architectural patterns to choose from; The bad news is that there are plenty of architectural patterns to choose from. In fact, most patterns are very similar to each other. So the advice here is to start by categorizing the architectural patterns that you need to use in a particular domain, categorizing those that are similar in design thinking, and then focusing on the one that represents the most in each category.

Once you have some understanding of these architectural patterns, it’s time to make a choice. Honestly, it doesn’t matter which model you choose, but how you put it into practice. Because most patterns only scratch the surface without breaking down the definition of each layer, choosing the “right” architecture does not automatically give you a well-architased codebase. The best way to decide which pattern to use is to try several patterns in your code base, which will give you the most valuable information about whether the pattern meets your requirements. Also don’t ignore the people factor. How big is the team? What is the development experience of the members? Their preferences? Is there a time limit? All of that has to be taken into account. Here are some questions to help you try and choose:

  1. Do you end up producing a lot of boilerplate code? If so, do they at least make the code easier to read?
  2. Will you end up producing lots of “empty” files that just proxy method calls to other objects?
  3. Is this pattern hard to understand?
  4. How much refactoring do you need to apply the pattern?
  5. Does this model add a lot of new concepts and vocabulary?
  6. Do you need to import a library to apply the pattern?

These questions aren’t necessarily bad, they just help you think. Finally, keep in mind that architectural design is more art than science. Keep practicing, learning and innovating. There are many good architectural approaches and many not so good approaches, but there is no right approach.

To put into practice

Each pattern has a different design idea and detail, and how you implement it, you play a decisive role. Again, the most important thing: it’s an art. So let go of your imagination and try, summarize and learn. Of course, in practice, there are some things we need to focus on in general. Here are some of them:

  1. Decoupling No matter which pattern you use, make sure your code is broken up into small, loosely coupled pieces.
  2. Cohesion Make sure your type is highly cohesive. If you define a small type that has very specific responsibilities, it is likely to show a high degree of cohesion.
  3. Modules Ensure that your application is broken down into modules.
  4. Dependencies Ensure that you use patterns such as Dependency Injection, Service Locators, etc to manage dependencies between objects.

Finally, may the architecture gods bless these young architects and let them blossom their artistic lives into code.

Refer to the article: www.raywenderlich.com/books/advan…