架构设计六大原则
小企业设立组织架构应遵循哪些原则？
小企业设立组织架构应遵循哪些原则？
小企业设立组织架构应遵循的原则
1.组织架构需要满足未来3-5年的发展规模和需要
2.组织架构内，各部门职责清晰明朗，晋升通道畅通
3.组织内各部门有相互协调和沟通的通道
节点的构成原则是什么?
节点在信息架构中是依据组织原则（organizing principle）来安置的。从字面上来讲，组织原则基本上就是我们决定哪些节点要编成一组，而哪些节点要保持独立的标准。
不同的组织原则将被应用在不同的区域和网站不同的层面。以一个公司的信息网站为例，我们的树状结构中的最上层也许是这样的类别：“消费者”、“企业集团”和“投资者”。在这个阶段，组织原则是“不同内容所针对的观众”。
其他网站也许有另外的最上层类别，比如“北美洲”、“欧洲”和“非洲”，使用地区作为另一种组织原则是满足全球使用者需求的一种方法。一般来说，你在产品最高层级使用的组织原则应该紧密地与“网站目标”和“用户需求”相关。而在结构中较低的层级，内容与功能需求将对你所采取的组织原则产生重大影响。
结构设计三原则？
架构设计三原则：
合适原则
简单原则
演化原则
一、合适原则
架构设计的几个误区：
1. 最流行架构
微服务很火，是不是立马把用的好好的springmvc改成微服务架构？docker很火是不是立马进入容器？
2. 追随一线大厂
我们在做电商，淘宝是一线大厂，要不要直接采用淘宝架构？微信开源了消息队列中间件，我们社交的也直接切换吧？
3. 追求大而全
我们随着业务展开用户量会提升很快，我们要兼容微服务扩展， 要加入消息队列，数据库主从，加入Elasticsearch 有利与后期查询，并且随着系统分布式部署，要加入docker来管理环境，日志管理要上kafka 等等。
以上几点，可以说都是错的，因为我们选型偏离的最主要的矛盾，为我们独特的业务场景，定制合适的系统架构，使用最流行的架构，有没有考虑我们业务特殊性？直接追随大厂有没有考虑我们团队的技术能力和是否真的能碰到大厂那种极端场景？追求大而全是否让有限的团队资源陷入无穷的低产出工作上？ 架构就是取舍，不求最新，不求最全，只求最合适。
二、简单原则
复杂，就意味着难度增加，不可控风险增加，保持简单，能系统方便理解，方便扩展，耦合度降低。简单并不代表没有技术含量，反而简单的实现更为实用，比花哨设计更能适应系统一步步演化。
三、 演化原则
罗马不是一天建成的，QQ也不是一天开发起来的。我们要做高内聚低耦合设计，就是为了可扩展。但是我们也要避开过度设计，避免根本不会遇到的场景投入过度资源，设计就是取舍，好钢用在刀刃上，集中资源做主要的事，然后根据未来的方向，不断重构优化，自然会衍生出最适合本业务的工程。