- DRY Don’t repeat yourself
系统设计中你碰到的问题别人都已经碰到过了，向高手学习他们的解题方法。另外，别重复别人的错误。
- KISS：Keep it simple, stupid!
我更喜欢解读成 Keep it stupid, so it can be simple（笨方法往往是最好的方法）。
- Avoid Creating a YAGNI：You aren’t going to need it
- Abstraction Principle
- Minimize Coupling
如果代码的力量来源抽象，那么系统的威力就来源于解耦，“抽象”和“解耦”两根大棒，但不要“滥用”（有代价），架构设计的好坏往往就体现在“抽象”和“解耦”的能力上。
- Separation of Concerns
- Single Responsibility Principle
- Maximize Cohesion
像搭积木一样，解决问题和写代码时尽量采用组合或延续的办法而不是从头开始，consistency 是软件工程质量的关键。
- OCP Open/Closed Principle
开闭原则 (OCP) 指出软件实体（类、模块、函数等）应该对扩展开放但对修改关闭。这意味着可以在不修改源代码的情况下扩展软件实体的行为。完整性和灵活性是架构师和优秀程序猿时常考虑的问题，也是和菜鸟的区别所在。
- Don’t make me think
把问题讲清楚，问题已经解决一大半了。
- Principle of least astonishment
一切和预期的一样，no news is good news。
- Avoid Premature Optimization
通常程序员只是一个人在编码，向组长负责。而架构师需要面对不同的 stale holder，带领一大群人编码完成项目，需要很好工程能力以及跨领域的知识。 一个优秀的架构师对系统设计考虑的问题必须全面，内部的，外部的，看得到的，看不到的，现在的，将来的，技术的，非技术的，例如新技术的成熟度，实施该模块团队的技术储备，用户体验，项目的资金和时限，承受风险的能力，管理上级和客户期望，领域趋势，等等。这些东西都是不能从书本直接得到，而需要经验的积累。
Beyond Microservices: Streams, State and Scalability • Gwen Shapira • GOTO 2020 Seeing this pattern so many times - microservices and event-driven have values but overemphasising the goods and dumping traditional design around apis and db, the system “may” end up with much worse things - event schema vs. normalized db schema, bloated message vs. concise api, building on top of every single piece of event vs. building on top existing modules and functional apis, etc.
Microservices Architecture From A to Z Overall quite good article, I have 2 things to point out according to what I learn: 1. in principal SOA is same as Microservices, it was just focusing on integration of different systems, so it was not meant for reusability, scalability, ops agility like Microservices; 2. Choreography is a big mistake and most Microservices advocates go for it. The design of softare architecture is tended to be decoupled/distributed but business never be like that and the system design should be always united and integrated. Distributed logic (business or funcational) is just too complicated to get it right especially for a modern business. We all know No.1 rule is to avoid distributed computing. For common or supporting components/services, I will follow choreography pattern. But for core services belonging to the business process (e.g. in e-commerce: shopping cart, warehoursing, payment, accounting) I will stick with orchestration design. I have learned this through a few very big Microservices projects in different industrials.
Microservices Database Management Patterns and Principles Unfortunately under the context - catalog, shopping cart, ordering, i think, the anti-pattern is the best solution. When in the ideal case to go for microservices, database-per-service is the best practice, the others are actually anti-patterns - its not practical to do that with a huge microservices system and I am strongly doubt those advocates have handson experience. CQRs, Event Sourcing, and Saga, are more like patching approach because the system has been designed as microservices when it is not necessary.
Why Agile Sucks for Building Quality Software What you are saying is perfectly correct, but then what Agile brings on table specifically for building good software? Agile is not helpful because in reality it focus on the process instead of the meaningful techniques. Agile is more about methodologies and it can come in different forms. So i wont think it sucks but it does not help. Good developers/teams/architects are agile by quality.
注意，这和所使用的编程语言和技术栈无关。99% 的软件项目都是被“复杂度”杀死的，而这是微服务/分布式系统的死结（参考经典文章：
How Complex Systems Fail）。作为架构师，抛开各种技术和复杂表象，其工作核心就是: 对抗熵增（We want to fight entropy），而这往往是大家都挂在嘴边，但和最后大家所做所为却恰恰相反的。
