System Architecture Design Entry Literacy _ Architecture design

Recently responsible for a project's system architecture design, just started rough to give a draft. After a revision with a draft to find the company's chief scientist legend of "God", a long talk, although criticized for nothing, but I feel unusually cool, suddenly feel that in the system architecture design has gradually begun to get on track.

Extremely welcome to have the reason to criticize to me, the more poured the more enjoyable. (some of them are cheap, haha)

Combined with the actual situation of the project, summed up some suggestions for improvement and future noteworthy places:

1. Platform APIs are not considered first. My original first edition considered the public API on the platform, but in fact, in the first version of the description, it is not very useful, and later want to expand the words is very simple. So in order to reduce the complexity of the system, do not consider. 2. Design to be more detailed, must be finalized the necessary technical selection. System design is not a description of the requirements, as a system architect, must just start on the key technology selection. 3. The call relationship does not allow a triangle relationship to occur. The original design diagram does not specifically indicate the master-slave relationship, which leads to seemingly triangular relationship appearance. The call direction should actually be indicated, and the active initiator is the starting position of the arrow. 4. To be able to identify the program module from the design level. There must be clear guidance as to which system is a what kind of program. , such as a command-line program, a system service program, or a Web service program. ) 5. This system is not a layered system, but a network hub system (star type). Layered systems are generally suitable for dishes that are completely closed at the bottom, and star systems cannot be described as layered systems. 6. The division of the business into the business layer, the task system must be business-independent. As far as possible split the business-independent module, the business-related tasks must be completed at the business level. 7. After the calculation process is split, the intermediate calculation process cannot record the result directly, but the system rollup must be dispatched. (Transaction, crash-proof) the intermediate Task module considers the crash recovery of the transaction. 8. Computing systems and external management system can be further abstracted into computational units. 9. The coupling of dispatch system and business should use database isolation. 10. Configuration information should also be embodied in the architecture design. 11. All call relationships must be clear. 12. Reference status > Reference history. 13. All systems are as passive as possible. This can reduce system coupling and the complexity of development. 14. The video meta computation is indivisible, and the distributed cluster computation is not considered. 15. The log must be disposable, otherwise it is the business. This sentence is classic. 16. Automatic upgrade of compute nodes can be designed from the start.