内功
最近太忙了，忙得没有时间思考和总结。近大半年一直在做架构设计和架构且谈起架构设计，刚好有许多心得想分享给大家。谈起架构设计，脑海里如果没有出现架构设计的六大原则、康威定律，那应该是一个还没来得及修炼内功的架构师。没听过的读者，可能会希望我给大家结合案例来普及基本知识，作为作者的我也比较懒，就简单地给大家扒点概念，更多的内容还是靠大家自行百度或谷歌了。
- 架构设计的六大原则
单一职责原则（Single Responsibility Principle - SRP）
开放封闭原则（Open Closed Principle - OCP）
里氏替换原则（Liskov Substitution Principle - LSP）
最少知识原则（Least Knowledge Principle - LKP）
接口隔离原则（Interface Segregation Principle - ISP）
依赖倒置原则（Dependence Inversion Principle - DIP）
- 康威定律
第一定律 组织沟通方式会通过系统设计表达出来。
第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。
第三定律 线型系统和线型组织架构间有潜在的异质同态特性。
第四定律 大的系统组织总是比小系统更倾向于分解。
那除了上述的两大神器外，谈架构设计的时候，你会想到什么？
……
其实读者想到啥，我压根也不知道-。-。开个玩笑，别锤我...
干货
浸淫了大半年的架构迭代，外加业界新兴的理念越来越多。我对架构设计的理解也是越来越蓬勃，越来越深入。提起架构设计，我的想法不再是用什么框架，用什么数据库，用什么新技术，而是...
先想想架构设计的
业务是什么？
再想想架构设计的组织与流程是什么？
其次想想架构设计的数据有什么？
然后想想架构设计的系统是什么？
最后想想架构设计能整合哪些外部资源？
赶紧拿小本本记下来，上面几点考试要考！
1. 架构设计的业务是什么？
有人说这个架构设计的业务不是有业务专家、BA在梳理嘛，我操这个心干嘛呢？非也，好的架构师有时候需要比业务专家、BA还要专业，只有足够的深入业务，了解业务，才能进行好的架构设计。
这让我想到一个产品设计里面一个非常经典的MVP案例，即原始用户的需求是什么，业务是什么？这个MVP背后的真实需求其实是“出行”，帮助用户更好的出行。那么一个滑板、自行车、摩托车等等就是比较正确的最小可行性产品。我们架构同样需要了解业务真实的诉求，才能辅助我们更好地设计。
只有深入了解业务，明确业务的初衷和目的，我们才有信心来设计符合产品、符合业务的架构，也只有清晰地了解业务，才能给我们的架构设计规划出一条合理的迭代路线，而不是每到一个阶段就因为业务推翻重构。
只了解当下的业务，设计出的系统肯定是能解决当前用户诉求的，而了解业务的未来，设计出的系统肯定是灵活有度，相当持久的。
2. 架构设计的组织与流程是什么？
如果刚刚有去认真回顾康威定律的话，你就会发现架构的设计与组织是密不可分的。往通俗了说，什么人用你设计的
系统架构的设计源于业务组织形态，也将先于组织形态。
起初，你的架构设计会随着组织的考虑，符合各种岗位之间的便捷和协作，而随着业务形态的改变，技术的先进性，技术会反过来影响组织的。
举个例子，自从大数据、人工智能如火如荼，智能客服、RPA等技术的出现，给架构和系统添加了许多Niubility的元素的同时，更是提升了实体组织之间的协作和效率。
我在梳理业务组织形态的时候，发现原本由于业务组织的不稳定性，反过来影响系统的边界不合理，增加系统的设计的复杂度，我反过来推动业务的组织固化以及岗位的合理能动性，让系统与业务形态更加灵活和契合。
3. 架构设计的数据有什么？
这里的数据主要指的我们在系统中运作的数据模型、数据实体，甚至主数据。有读者肯定会疑问为什么谈架构设计的时候要把数据也考虑上呢？可能是你还没被大数据、数据中台这些理念熏陶到，没有get到这里面的一些精华和惨痛的教训。数据这块真的太重要了，数据的模型设计合不合理，将会影响你的架构设计是否能够持续。
之前谈的很火的业务中台，背后最核心的就是业务模型实体的资产的积累和业务能力的积累，业务模型这块和我们的数据质量息息相关。
架构中要考虑的数据不单单只是业务模型实体，还有考虑数据之间的串联、数据之间的契约与标准，没有考虑好的话，在后期发展过程就会成为一轮又一轮的数据治理。
这里推荐大家可以看一些数据中台相关的文章，作者比价懒，就不推荐了-。-
4. 结合上述的要求，系统怎么设计架构？
终于到大家非常擅长的PPT架构师设计环节，用什么框架体系，用什么技术体系，详细大家还是可以信手拈来的。这里主要还是提一些要注意的点
架构的选型与团队的契合度
架构的设计与业务形态的契合度
架构的设计与运维的复杂程度
架构的实现与投入产出比
最重要一点，一定让业务、BA、团队成员能够清晰地了解到你的设计思考、架构迭代考虑和成本投入，别为了架构而架构设计。
愿每个读者都能成为一个伟大的架构师，是的，不脱发的那种架构师。
