The author called Srinath, a scientist, software architect, also a programmer working on a distributed system. He is the co-founder of Apache Axis2 project, also a member of Apache Software Foundation. He is WSO2 stream processors (wso2.com/analytics) co-architect. Srinath has written two books on MapReduce and many technical articles. He received his doctorate. From Indiana University.
Srinath through unremitting efforts finally summed up the 30 principles of architecture, he advocated the architect's role should be played by the development team itself go, rather than have a dedicated team of architects or department. Srinath think architects should play the role of a leader is to discuss the initiator, the construction of plants, rather than the definition of who and builders. Srinath order to solve disputes and architecture choices within the team, has developed the following 30 principles that are widely recognized by members, it has become a way of learning novice architects.
The basic principle
Principle 1: KISS (Keep it simple, sutpid) and keeping everything as simple as possible. With the most simple solution to solve the problem.
Principle 2: YAGNI (You are not gonna need it) - do not engage in some unwanted stuff, when you need to engage in it.
(Comments: Examples abound of speculative development programmers say to myself:.. "I'm sure the future will need this extra functionality, so now put it ahead of time to achieve it." In fact, this is the biggest test skill areas, not behind closed doors function YY needs, but also insight into the trends in architecture.)
Principle 3: crawl, walk, run. In other words, to ensure that run through, and then optimize to get better, and then continue to optimize allowed to become great. Iteration with the idea to do something, agile development. For each function point, create milestones (maximum two weeks), then go iteration.
(Comments: Fast Feedback, a "milestone racking our brains" is better than no milestones ...)
Principle 4: Creating stable, the only way to high-quality products is the automated testing. All can be automated, when you design, think of this.
(Comments: all automation should also consider the ROI, such as a page for special variable layer ...)
Principle 5: the moment in order to input-output ratio (ROI). It is not worthwhile.
Principle 6: Know your users, and then based on this to balance what things you need to do. Do not spend a few months time to do a devops user interface, you finally found that people who just prefer the command line. This principle is a concrete manifestation of the principle of 5.
Principle 7: Design and test a function was as independent as possible. When you do the design, you should think about this one. This can give you a lot of problems to solve in the long run, or you can wait for all the functions of the other functions of the system are ready to test, which is obviously very bad. With this principle, your version will be more smooth.
Principle 8: Do not get fancy. We all like the high-end cool design. Finally, we do a lot of features and solutions to our architecture, then these things will not be used.
(Comments: boss likes ppt?)
Feature Selection
Principle 9: It is impossible to predict how users will use our products. So to embrace MVP (Minimal Viable Product), the minimum run version. The main idea of this view is that you rarely pick a few usage scenarios, and then get it out, and then let users publish on-line, and then based on experience and user feedback to decide what to do next.
Principle 10: do fewer features as possible. When in doubt, do not do it, even kill. A lot of features never used. Stay a maximum extension point enough.
(Comments: Product Manager may be not listen, it is best to take data metrics to speak ...)
Principle 11: until someone asked to say (unless it is affecting the core processes, or to wait until the time needed to do it again).
Principle 12: Sometimes you have to have the courage to say no and customers. This time you need to find a better solution to come and resolve. Remember Henry Ford once said: "If I had asked people what they need, they will say I need a faster horse." Remember: You're the expert, you're going guidance and leadership. To do the right thing, not the popular thing. End users will thank you with a car for them.
Design and concurrent server
Principle 13: To know how to run a server from the hardware to the operating system until programming language. The number of calls to optimize IO is the first choice of the road you access to the best architecture.
Principle 14: For Amdhal synchronize the law. Variable data shared between threads will make your program slower. Just before going to use concurrent data structures when necessary, must be used only in synchronous (synchronization) to use when it is synchronized. If you want to lock, but also to ensure the least possible time to hold live lock. If you want to do something in the lock, make sure you lock in which things will do.
Principle 15: If you are a non-blocking design and event-driven architecture, then do not block the thread or do some IO operations in these threads, if you do, your system will slow like a mule.
Distributed Systems
It is directly scalable and stateless system: Principle 16. At any time to consider this, do not put forward a non-scalable, stateful stuff out, this is the minimum.
Principle 17: to ensure that the message is delivered only once, regardless of failure, it's hard, unless you want the client and server do control. Try to make your system more portable (using Principle 18). You have to know that most of the promises exactly-once-delivery systems are made streamlined.
Principle 18: Achieving a possible power operation. In this case it is better to recover, but you still in the state for at least one pass (at least once delivery) is.
Principle 19: CAP know the theory. Scalable Affairs (distributed transactions) is difficult. If possible, then, as far as possible the use of compensation mechanisms. RDBMS affairs can not be extended.
(Comments: new SQL find out ...)
Principle 20: distributed consensus can not be extended, nor can perform group communication can not communicate reliably in the cluster-wide. Ideally node is limited to a maximum of eight nodes.
Principle 21: In a distributed system, you can never avoid delays and failures.
(Comments: ah, right, facing the design, but you fail to consider your users, your service provider SLA really need 7 * 24 * 365 it..?)
user experience
Principle 22: To clearly understand your users and their goals. They are a novice, expert or casual user? They understand the extent of computer science. Geeks like extension points, developers like examples and scripts, while ordinary people are like UI.
Principle 23: The best product does not require product manual.
Delivered to the user when you can not make decisions in two options, please do not put this issue directly by providing configuration options for the way: Principle 24. This can only make the user more muddled. If you are in this case not even the experts can not be selected, than you give a few people still know so appropriate? The best approach is always to find a viable option; the next best practice is automatically given the option, the third best practice is to add a configuration parameter, then set a reasonable default value.
Principle 25: To configure the settings are always a reasonable default value.
26 principle: poorly designed configuration will cause some problems. You should always provide some examples of values for the configuration.
27 principle: the user configuration value must be able to understand and direct filled. For example: we can not let the user fill in the maximum number of cache entries, but should allow users to fill in for the maximum amount of memory that can be cached.
Principle 28: If you enter an unknown configuration to throw an error. Never quietly ignored. Quietly ignore configuration error bug is often spent hours looking for the culprit.
Tough questions
Principle 29: dreaming of a new programming language becomes simple and clear, but often in order to truly grasp would be difficult. Do not enchant programming language.
(Comments: "technology geeks" are not listen, it is better to "personal practice" and "project a" separate look ...)
30 principle: sophisticated drag drag interface is difficult, not to try such an effect, unless you're ready for 10 man-years of the team.
(Comments: I always do not believe the integrity of the code generation, such as MDA, pull or drag modeling instead of writing code ... If there is success, or relatively small areas)
Finally, I said, a feeling. In an ideal world, a platform should be a plurality of orthogonal components - each component is responsible for one aspect (for example, security, messaging, registry, mdidation, analytics). To build a system like this is perfect. Unfortunately, in reality, it is difficult to achieve such a state. Because in the initial state of the project, many things are uncertain, you can not do this independence, and now I am more inclined to at the beginning of the appropriate repetition is necessary, when you try to eradicate them, you will find introduces new complexity, distributed itself implies complex. Sometimes the cure itself more worse than the disease process.
(Comments: different stages using different approaches, often mere copycat copy)
to sum up
As an architect, gardener should be like in general, it is more cut flowers, weeding rather than to define and build, you should plan rather than direct, you should go to trim rather than the definition should be discussed rather than labeling. Although in the short term you may feel nothing, but in the long run, guiding the team to find their own way will bring benefits. If you are too easy, it is easy for architecture to become an empty word. For example, designers would say that his architecture was wrong, but I do not know why it is wrong. A good way to avoid this is to have a list of principles, this list is widely accepted principle, this list is an anchor people to discuss the issue, the path also a novice architect to learn.