What the software architecture should do

Software architecture is the work done before software construction starts after the software requirements come out

What the architect should be sure of:

1 Program Organization

The schema should define the main building blocks in the program.
Depending on the size of the program, each building block may be a single class or a system composed of multiple classes. Each building block implements a high-level function. And each requirement has at least one building block to cover it.

Define communication rules and dependency rules between individual building blocks

2 Main Classes

The schema should define or write out the main classes used in detail. and shows how the class interacts with other classes.

Schemas do not need to be described for all classes, using the 82 rule: Description of the 20% classes that make up system 80% functionality

3 Data design

The schema should explain the design of the data tables that are used clearly and describe why the choices are made

4 Business Rules

Architectural descriptions of specific business rules (e.g., customer information cannot be updated for more than 30 seconds) (e.g. synchronizing client information within 30 seconds)

5 User Interface Design

Architecture should have a detailed user interface, a good user interface is directly related to the implementation of the function and the final effect of the software

6 Resource Management

The architecture should have a management plan for scarce resources. such as the use of database connections, threads, handles, and so on. It is possible to design a module of the "explorer"

7 Security

The schema should describe the security instructions for user input data, cookies, configuration files, etc.

8 Performance

Estimate performance data should be provided based on performance descriptions in the requirements document, and explain why architects believe they can achieve performance goals. Or why some of the performance indicators can not be achieved

9 Scalability

The architecture should show how the system should respond to the growth of the number of users, the number of servers, the number of network nodes, the number of database records, the length of database records, and the volume of transactions.

10 Interoperability

If the system has shared resources with other software or hardware, the architecture should explain how to do this

11 Internationalization/Localization

Does the system support internationalization and how to internationalize in modules that interact with the user?

12 Input and output

Schemas should define read policies in detail

13 Error Handling

It is estimated that up to 90% of the code in the program is used to handle exceptions and errors, meaning that only 10% of the code is used to handle conventional situations.

The issues to consider include:

Error handling whether to correct or only to detect

Whether the error detection is active or passive

How the program spread the error, is immediately discarded or notify a place

What's the deal with error handling?

How to handle exceptions, when to throw exceptions, where to log, where to capture

Where to handle the error, is passed to the place where the error is handled specifically or along the chain of functions to pass the error

How the input data amount of each class is responsible for the validity of

Do you want to use the error handling mechanism built into your environment or a custom set of mechanisms

14 Fault Tolerance

Fault tolerance is the technology to enhance system reliability, if the error is into "partial operation" or "functional degradation"?

15 The feasibility of the architecture

The architect should demonstrate the feasibility of the system design

16 Over Engineering

That is, robustness. The architecture should indicate which classes and modules need to be overallocated (robustness testing) and which classes or modules need to be done with the simplest performance

17 about buying or building

Some software, open source code, processing program, is to use the spot purchase or custom development

18 About reusing

If you use the industry's existing software, Open-source code and other resources, you should explain how to process these things.

19 Change policy

Schemas should clearly describe the strategy for handling changes. The schema should list the requirements that have been considered that may be changed, or the capabilities that might be enhanced.

and provide processing, such as using version numbers for control, or designing code to dynamically add new data

20 overall quality of the architecture

The architecture should clearly describe the motives of all the major decisions it makes

Clearly point out where the risk is