- 综合排序
- 最热优先
- 最新优先
- 来自专栏花落的技术专栏
企业架构原则
定义架构原则 一般架构原则是由企业架构师和一些企业关键人物定义，然后由架构委员会进行同意后制度发布。原则应该可被追踪，并且能清晰的表达人员做出决策依据。 定义企业架构原则一般受以下因素影响： 企业的使命和愿景： 企业的战略计划：企业的优势，劣势，机会和威胁。 一些示例 架构原则 基于标准的方法来做，如使用TOGAF架构方法 说不清的不做 没有上层持久推动的不做 达不成意见一致的不做 业务原则 企业利益最大化 业务持久性 对业务发展有长远规划，不能只考虑近期实现范围 业务通用性， 业务是否可以作为一个公用业务架构 业务一致性 合法 数据原则 数据价值性 > 数据正确性 > 数据完整性 数据积累分析需要规范化数据 数据是安全的 数据不只是可以共享的数据，还包含业务规则和策略 应用原则 技术独立性，不绑定到特定厂商 使用过程体现流程性 模块化设计原则 独立业务规则 统一授权，统一界面 应用系统间间调用采用服务调用的方式 与外部系统调用，必须有统一的接口规范信息格式 技术原则
36710发布于 2021-11-23 企业零信任架构设计原则与实施路径
引言：为什么零信任是大势所趋 还记得以前企业网络安全就像建城墙一样吗？外面危险，里面安全，只要守住城门就万事大吉。 传统架构 vs 零信任架构对比 2. 核心设计原则详解 3.1 最小权限原则 这个原则就像给每个人发钥匙——你只能拿到你工作需要的那几把钥匙，多一把都不给。 在这个数字化转型的时代，投资零信任架构就是投资企业的未来。 记住，最好的安全防护，是让坏人找不到可乘之机。零信任架构正是这样一把看不见的"金钟罩"，保护着我们的数字资产。 **关键词：零信任架构、企业安全 本文适用于企业安全负责人、IT架构师、网络安全工程师等相关人员参考学习。
64110编辑于 2025-07-14- 来自专栏小赵的Java学习
软件架构设计原则--开闭原则
本专栏内容参考自：咕泡学院Tom老师的《Spring5核心原理与30个类手写实战》，仅作个人学习记录使用，如有侵权，联系速删 开闭原则（open-closed Principle,OCP）是指一个软件实体 所谓开闭，也正是对口占和修改两个行为的一个原则。它强调的是用抽象构建框架，用实现扩展细节，可以提高软件系统的可复用性及可维护性。 开闭原则是面向对象设计中最基础的设计原则，它知道我们如何建立稳定、灵活的系统。例如版本更新，我们尽可能地不修改源代码，但是可以增加新功能。 在现实生活中开闭原则也有体现。 我把它可以理解为：定死规矩，灵活实现 开闭原则的核心思想其实是面向抽象编程，我们来看一段代码： 我们有这样一个接口：商品IGoods，有ID、名字、价格三个属性 public interface IGoods super.getPrice(); } //获取打折价 public Double getPrice(){ return super.getPrice()*0.8; } } 这就是开闭原则的体现了
60530编辑于 2022-12-02 - 来自专栏后端技术探索
简述架构设计原则
架构坚持组件化，持续重构，小而美。架构设计十大原则： 1.全面解耦原则：对业务进行抽象建模，业务数据与业务逻辑解耦，软硬件解耦，平台和产品解耦，系统各部件解耦。模块、组件高内聚，低耦合。 2.服务化/组件化原则：以服务、数据为中心，构建服务化、组件化架构，具备灵活，按需组合的能力。 5.安全可靠环保原则：构建最小权限，纵深防御、最小公共化、权限分离、不轻信、开放设计、完全仲裁、失效安全、保护薄弱环节、安全机制、经济性、用户接受度以及加强隐私保护的安全体系，确保系统、网络和数据的机密性 9.柔性供应制造原则：模块化设计，模块/物料归一化、标准化，支持自动化、数字化、智能化、随需应变的柔性制造。 10.持续演进原则：架构并非一蹴而就，需要有效地管理架构需求；持续构建和发展架构，适应业务需求变化，适时引入业界最佳实践，及时重构，确保架构生命力和竞争力。
1.7K30发布于 2018-08-10 - 来自专栏Tom弹架构
软件架构设计原则之开闭原则
1 开闭原则 开闭原则（Open-Closed Principle，OCP）是指一个软件实体（如类、模块和函数）应该对扩展开放，对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。 开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定、灵活的系统。例如版本更新，我们尽可能不修改源代码，但是可以增加新功能。 在现实生活中开闭原则也有体现。 开闭原则的核心思想就是面向抽象编程，接下来我们来看一段代码。 interface ICourse { Integer getId(); String getName(); Double getPrice(); } 整个课程生态有Java架构 、大数据、人工智能、前端、软件测试等，我们来创建一个Java架构课程的类JavaCourse： public class JavaCourse implements ICourse{ private
59930编辑于 2022-04-25 - 来自专栏芋道源码1024
谈谈架构：设计与原则
来源：http://t.cn/EZMtRwz
49911发布于 2019-10-29 - 来自专栏小赵的Java学习
软件架构设计原则--里氏替换原则
本专栏内容参考自：咕泡学院Tom老师的《Spring5核心原理与30个类手写实战》，仅作个人学习记录使用，如有侵权，联系速删 里氏替换原则（Liskov Substitution Principle 使用里氏替换原则有以下优点： 约束继承泛滥，这是开闭原则的一种体现。 加强程序的健壮性，同时变更时也可以做到非常好的兼容性，提高程序的可维护性和扩展性，降低需求变更时引入的风险。 用一个经典的业务场景：用正方形、矩形、和四边形的关系说明里氏替换原则，我们都知道正方形是一个特殊的长方形，所以可以创建一个父类Rectangle: public class Rectangle { square = new Square(); square.setLength(10); resize(square); } 对已有功能造成了影响，违背里氏替换原则 因此，我们的代码设计是存在一定风险的。 里氏替换原则只存在于父类和子类之间，约束继承泛滥。
51230编辑于 2022-12-02 - 来自专栏小赵的Java学习
软件架构设计原则--依赖倒置原则
本专栏内容参考自：咕泡学院Tom老师的《Spring5核心原理与30个类手写实战》，仅作个人学习记录使用，如有侵权，联系速删 依赖倒置原则(Dependence Inversion Principle ，DIP)是只设计代码结构时，高层代码不应依赖低层代码，二者都应依赖其抽象。 buyer.buy(); buyer.setBuyer(new fruitBuyer()); buyer.buy(); } } 以抽象为基准比以细节为基准搭建起来的架构要稳健的多 ，因此在拿到需求以后，要面向接口编程，先顶层再细节的设计代码结构，尽量让新添加的业务不会对已有的业务产生影响。
47320编辑于 2022-12-02 - 来自专栏小赵的Java学习
软件架构设计原则--接口隔离原则
本专栏内容参考自：咕泡学院Tom老师的《Spring5核心原理与30个类手写实战》，仅作个人学习记录使用，如有侵权，联系速删 接口隔离原则（Interface isolation principle 这个原则知道我们在设计接口时应当注意以下几点： 一个类对另一个类的依赖应当建立在最小的接口上。 建立单一的接口，不要建立庞大臃肿的接口。 尽量细化解耦，接口中的方法尽量少（不是越少越好） 接口隔离原则符合我们常说的高内聚、低耦合的设计思想，可以使类具有很好的可读性、可扩展性和可维护性。 我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括对哟吼可能发生变更的地方还要做一些预判。 所以，对于抽象、对于业务模型的理解是非常中重要的。 那么这就不符合接口隔离原则了，怎么改进呢？ 把三种行为拆分为三个接口，让每个动物实现他们各自需要的就行了。
38730编辑于 2022-12-02 - 来自专栏Tom弹架构
软件架构设计原则之开闭原则
开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定、灵活的系统。例如版本更新，我们尽可能不修改源代码，但是可以增加新功能。 在现实生活中开闭原则也有体现。 [图片1.png] 关注微信公众号『 Tom弹架构 』回复“设计模式”可获取完整源码。 【推荐】Tom弹架构：30个设计模式真实案例（附源码），挑战年薪60W不是梦 本文为“Tom弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！ 其他设计原则 Tom弹架构：依赖倒置原则（Dependence Inversion Principle，DIP） Tom弹架构：单一职责原则（Simple Responsibility Pinciple ，SRP） Tom弹架构：接口隔离原则（Interface Segregation Principle, ISP） Tom弹架构：迪米特原则（Law of Demeter LoD） Tom弹架构：里氏替换原则
1.2K00发布于 2021-10-24 - 来自专栏小赵的Java学习
软件架构设计原则--合成复用原则
本专栏内容参考自：咕泡学院Tom老师的《Spring5核心原理与30个类手写实战》，仅作个人学习记录使用，如有侵权，联系速删 学习设计原则是学习设计模式的基础。 在实际开发中，并不要求所有代码都遵循设计原则，我们要考虑人力、时间、成本、质量等多方面因素，不能刻意追求完美。 但要在适当的场景遵循设计原则，这体现的是一种平衡取舍，可以帮助我们设计出更加优雅的代码。 虽然我们要根据具体的业务场景来做代码设计，但也需要遵循OOP模型。 但是就目前的设计来说，DBConnection还不是一种抽象，不便于系统拓展。
37730编辑于 2022-12-02 - 来自专栏Tom弹架构
软件架构设计原则之接口隔离原则
接口隔离原则（Interface Segregation Principle, ISP）是指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。 这个原则指导我们在设计接口时应当注意以下几点： （1）一个类对另一个类的依赖应该建立在最小的接口之上。 （2）建立单一接口，不要建立庞大臃肿的接口。 接口隔离原则符合我们常说的高内聚、低耦合的设计思想，可以使类具有很好的可读性、可扩展性和可维护性。我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括对以后有可能发生变更的地方还要做一些预判。 这时候，我们针对不同动物行为来设计不同的接口，分别设计IEatAnimal、IFlyAnimal和ISwimAnimal接口，来看代码。 本文为“Tom弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！
37210编辑于 2021-12-21 - 来自专栏爱思
golang 架构设计原则 单一职责原则
golang 架构设计原则 单一职责原则 缘起 最近复习设计模式 拜读谭勇德的<<设计模式就该这样学>> 该书以java语言演绎了常见设计模式 本系列笔记拟采用golang练习之 单一职责原则 单一职责原则 直播课可以播放和暂停, 不支持快进快退 录播课支持播放, 暂停, 快进和快退 如果把直播课和录播课实现在一个class里面, 则快进和快退的处理会比较麻烦 将直播课和录播课分开class实现, 从而遵循单一职责原则
1.1K00发布于 2021-01-26 - 来自专栏Tom弹架构
软件架构设计原则之依赖倒置原则
依赖倒置原则（Dependence Inversion Principle，DIP）是指设计代码结构时，高层模块不应该依赖低层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。 大家要切记：以抽象为基准比以细节为基准搭建起来的架构要稳定得多，因此在拿到需求之后，要面向接口编程，先顶层再细节地设计代码结构。 本文为“Tom弹架构”原创，转载请注明出处。
55720编辑于 2021-12-21 - 来自专栏小赵的Java学习
软件架构设计原则--单一职责原则
这样设计，可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更所带来的危险。 设计一个顶层接口，ICourse: public interface ICourse { //获取基本信息 String getCourseName(); //获取视频流 String userName,String address){ userName = "Tom"; address = "北京"; } 但是我们已经学过了单一设计原则 我们在实际开发种，会有项目依赖、组合、聚合这些关系，还有项目的规模，周期，技术人员的水平，对进度的把控，很多类都不符合单一职责原则。
46820编辑于 2022-12-02 - 来自专栏Tom弹架构
软件架构设计原则之接口隔离原则
接口隔离原则符合我们常说的高内聚、低耦合的设计思想，可以使类具有很好的可读性、可扩展性和可维护性。我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括对以后有可能发生变更的地方还要做一些预判。 [图片5.png] 关注微信公众号『 Tom弹架构 』回复“设计模式”可获取完整源码。 【推荐】Tom弹架构：30个设计模式真实案例（附源码），挑战年薪60W不是梦 本文为“Tom弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！ 其他设计原则 Tom弹架构：开闭原则（Open-Closed Principle，OCP） Tom弹架构：依赖倒置原则（Dependence Inversion Principle，DIP） Tom弹架构 ：单一职责原则（Simple Responsibility Pinciple，SRP） Tom弹架构：迪米特原则（Law of Demeter LoD） Tom弹架构：里氏替换原则（Liskov Substitution
74400发布于 2021-10-24 - 来自专栏Tom弹架构
软件架构设计原则之里氏替换原则
因此，我们的代码设计是存在一定风险的。里氏替换原则只存在于父类与子类之间，约束继承泛滥。 当然，我们在后面的设计模式的内容中还会继续深入讲解。 关注微信公众号『 Tom弹架构 』回复“设计模式”可获取完整源码。 【推荐】Tom弹架构：30个设计模式真实案例（附源码），挑战年薪60W不是梦 本文为“Tom弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！ 其他设计原则 Tom弹架构：开闭原则（Open-Closed Principle，OCP） Tom弹架构：依赖倒置原则（Dependence Inversion Principle，DIP） Tom弹架构 ：单一职责原则（Simple Responsibility Pinciple，SRP） Tom弹架构：接口隔离原则（Interface Segregation Principle, ISP） Tom弹架构
60800发布于 2021-10-24 - 来自专栏小赵的Java学习
软件架构设计原则--迪米特原则
，又叫最少知道原则（Least Knowledge Principle，LKP），尽量降低类与类之间的耦合度。 迪米特原则主要强调：只和朋友交流，不与陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以被称为成员朋友类，二出现在方法体内部的类不属于朋友类。 假设现在来设计一个权限系统，Boss需要查看目前发布到线上的课程数量。 根据迪米特原则，Boss只想要结果，不需要跟Course直接交流。而Leader统计需要引入Course对象。 另外，学习软件设计原则，不能形成强迫症。碰到业务负责的场景，需要随机应变。
37730编辑于 2022-12-02 - 来自专栏Tom弹架构
软件架构设计原则之依赖倒置原则
本文节选自《设计模式就该这样学》 依赖倒置原则（Dependence Inversion Principle，DIP）是指设计代码结构时，高层模块不应该依赖低层模块，二者都应该依赖其抽象。 [图片1.png] 大家要切记：以抽象为基准比以细节为基准搭建起来的架构要稳定得多，因此在拿到需求之后，要面向接口编程，先顶层再细节地设计代码结构。 关注微信公众号『 Tom弹架构 』回复“设计模式”可获取完整源码。 【推荐】Tom弹架构：30个设计模式真实案例（附源码），挑战年薪60W不是梦 本文为“Tom弹架构”原创，转载请注明出处。 其他设计原则 Tom弹架构：开闭原则（Open-Closed Principle，OCP） Tom弹架构：单一职责原则（Simple Responsibility Pinciple，SRP） Tom弹架构 ：接口隔离原则（Interface Segregation Principle, ISP） Tom弹架构：迪米特原则（Law of Demeter LoD） Tom弹架构：里氏替换原则（Liskov Substitution
71800发布于 2021-10-24 - 来自专栏Tom弹架构
软件架构设计原则之里氏替换原则
里氏替换原则（Liskov Substitution Principle，LSP）是指如果对每一个类型为T1的对象o1，都有类型为T2的对象O2，使得以T1定义的所有程序P在所有的对象O1都替换成O2时 在讲开闭原则的时候我埋下了一个伏笔，在获取折扣时重写覆盖了父类的getPrice()方法，增加了一个获取源码的方法getOriginPrice()，显然就违背了里氏替换原则。 ： （1）约束继承泛滥，是开闭原则的一种体现。 因此，我们的代码设计是存在一定风险的。里氏替换原则只存在于父类与子类之间，约束继承泛滥。 当然，我们在后面的设计模式的内容中还会继续深入讲解。 本文为“Tom弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！
57720编辑于 2021-12-21
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号