- 综合排序
- 最热优先
- 最新优先
- 来自专栏java开发的那点事
Mysql业务设计（物理设计）
物理设计 根据所选择的关系型数据库的特点对逻辑模型进行存储结构的设计 物理设计： 定义数据库、表及字段的命名规范 选择合适的存储引擎 为表中的字段选择合适的数据类型 建立数据库结构 定义数据库、表及字段的命名规范
73210发布于 2020-09-30 - 来自专栏java开发的那点事
Mysql业务设计（逻辑设计）
逻辑设计 数据库设计三大范式 数据库设计第一大范式 数据库表中所有的字段都只具有单一属性 单一属性的列是由基本数据类型所构成 设计出来的表都是简单的二维表 ? 数据库设计的第二大范式 要求表中只有一个业务主键，也就是说符合第二范式的表不能存在非主键列，只对部分主键的依赖关系 ? 数据库设计的第三大范式 指每一个非非主属性既不部分依赖于也不传递依赖于业务主键，也就是在第二范式的基础上相处了非主键对主键的传递依赖 ? 反范式化设计 为啥要有这个东西呢，就是因为如果过分的依赖于三大范式，设计出来的表虽然很符合规范，但是SQL的查询性能将会很差，所以才有了反范式设计 什么叫反范式化设计： 反范式化是针对范式化而言的，在前面介绍的三大范式 所谓的反范式化就是为了性能和读取效率的考虑而适当的对数据库设计范式的要求进行违反 允许存在少量冗余，换句话来说反范式化就是用空间换时间 逻辑设计总结 不能完全按照范式的要求进行设计 考虑以后如何使用表
73330发布于 2020-09-30 - 来自专栏windealli
业务系统存储设计
一、引言 现在业务系统设计中，存储设计扮演着至关重要的角色。随着数据量的爆炸性增长和业务需求的不断变化，如何高效、安全地存储和管理数据成为了每个业务系统设计必须面对的挑战。 存储设计的关键考虑因素 数据的完整性和一致性 性能 可拓展性 可用性与容灾 安全合规 成本效益 3. 存储设计的原则 需求驱动设计： 存储设计应基于业务需求和应用场景，确保设计方案能够满足实际业务需求。 遵循标准和最佳实践： 遵循行业标准和最佳实践，确保存储设计的规范性和可维护性。 灵活性和适应性： 设计应具备灵活性，能够适应业务需求的变化和技术发展的趋势。 五、业务数据存储的常见优化策略 1. 缓存机制 缓存机制通过在内存中存储频繁访问的数据，减少对数据库的直接访问，从而提高系统的响应速度和吞吐量。
77012编辑于 2024-07-20 - 来自专栏技术趋势
设计模式-业务代表模式
业务代表模式是什么？ 业务代表模式（Business Delegate Pattern）用于对表示层和业务层解耦。它基本上是用来减少通信或对表示层代码中的业务层代码的远程查询功能。 业务代表（Business Delegate）：一个为客户端实体提供的入口类，它提供了对业务服务方法的访问。 查询服务（LookUp Service）：查找服务对象负责获取相关的业务实现，并提供业务对象对业务代表对象的访问。 业务服务（Business Service）：业务服务接口。 实现了该业务服务的实体类，提供了实际的业务实现逻辑。 优点： 低耦合高灵活：减少系统之间的相互依赖; 高内聚：有问题外部也是不知道的，只会怪接口，所以内部好处理掉这些问题。 业务代表模式主要解决一个是直接将业务交给业务代表去调用，当然所有的内部接口都向业务代表暴露，通过业务代表统一去操作，起到一个作用是用户不会直接面对内部系统而是面对。
1K20发布于 2020-09-18 - 来自专栏OSChina
单点登录流程 业务设计
登录的处理流程： 1、登录页面提交用户名密码。 2、登录成功后生成token。Token相当于原来的jsessionid，字符串，可以使用uuid。 3、把用户信息保存到redis。Key就是toke
66230发布于 2019-08-01 - 来自专栏知了一笑
设计「业务」与「技术」方案
唯独离谱在这里； 从实践经验上来看，产品研发抛开业务设计所带来的反伤，也许会迟到，但绝对不会缺席； 所谓的简单业务流程，仓促上线之后，后续补坑的成本可能高的离谱； 相对于完整的研发周期来说，设计、落地、 一次性的高质量完成，就是成本最低，效率最高的决策； 对于研发角色，方案设计通常就是围绕技术和业务两个核心； 02 【常用的方法论总结】 在做方案设计时，必然要运用一些基础的方式方法； 有关方法的经验总结很多 ，并且能意识到这种模式是映射到产品设计或者服务中的； 必须理解业务模式所对应的产品矩阵设计，各个核心功能的流程和路径； 理解负责的业务板块 个人的工作习惯，并不是常规的流程机制； 明确自己负责的业务板块 ，就是方案设计的主线； 05 【统筹技术和业务方案】 设计研发方案，自然需要把握业务的整体，规划技术架构，确保业务和技术双线推进； 方案的核心则是围绕当前阶段的具体业务需求，设计实现流程、目标、指标； ，关键问题与核心矛盾，在版本需求中有序解决； 业务和技术的流程 分析业务的运转流程和特征，映射为技术的实现过程，作为方案设计的核心思想； 业务的运转流程，围绕客户、产品、组织协作来设计，侧重于场景的分析
49020编辑于 2023-02-13 - 来自专栏Java项目实战
Java业务重要还是设计重要？
3.业务重要还是设计重要？ 这几个问题都是近期遇到的问题，逐一想自我验证一下，还有我年初的计划是用心写30-35篇啊，这疫情原因，年初在家都写了将近20篇了，我还不高产吗？怎么还拖更掉粉了呢？ 查询条件并没用到最左侧的字段，优化器竟然用到了索引 业务重要还是设计重要？ 关于这个问题就当下的业务展开进行了讨论，由于对业务的不不熟悉，在项目落参数时导致的参数不全，业务固然是代码书写的关键，何时落参，落哪些参数，在整个项目阶段，如果将业务捋清，流程理解，剩下的搬砖就是测试问题 而设计问题就会导致整个项目的扩展性，架构选择只是其中一方面，真正影响的还是业务设计，对后期的接入，扩展影响巨大，是否可抽离？是否可共用？是否强依赖？是否改动最小？ 最近感受比较深刻，当然这是历史设计遗留问题，时间久的项目考虑肯定没有那么细化，导致业务的模块与模块之间依赖太严重，不好抽离。
65720发布于 2020-04-21 架构设计与业务梳理
架构设计和业务梳理是软件开发过程中至关重要的步骤，它们可以帮助团队理清业务逻辑、优化系统结构，提高系统的可扩展性和可维护性。 在这篇博客中，我们将探讨架构设计和业务梳理的方法论，并提供一些实用的指导原则。 架构设计 架构设计是指在软件开发过程中，针对系统整体结构和组件之间的关系进行规划和设计的过程。 以下是一些关于架构设计的方法论： 需求分析：首先要深入理解业务需求，明确系统的功能和性能需求，与业务团队充分沟通，确保对需求的准确理解。 可扩展性：考虑系统未来的扩展需求，设计灵活的架构，方便添加新功能或调整现有功能。 性能优化：在设计阶段就考虑系统的性能需求，避免出现性能瓶颈，选择合适的技术栈和架构模式。 综上所述，架构设计和业务梳理是软件开发中不可或缺的环节，它们有助于团队对系统的整体结构和业务逻辑有一个清晰的认识，从而帮助团队高效开发、优化系统性能。
29110编辑于 2025-08-29- 来自专栏编外气象人
气象业务驱动模型（MODD）设计
气象业务驱动模型（MODD）的提出是为了解决气象业务信息化过程中气象业务和信息化技术的有效融合，不只是气象业务系统开发过程中的需求有效转化以及信息化架构的合理设计，还包含气象业务的合理改进和新技术有机融合的相关思考 业务模型驱动（BMD）是一种业务导向和驱动的软件体系，也是基于业务模型的概念结构表达体系，用来描述、分析、设计、构建、集成、扩展、运行的管理信息系统，是企业业务运行的基础平台架构。 领域驱动设计（DDD）是目前比较流行的软件建模设计方法，早在2004年埃里克.埃文斯（Eric Evans）就发表了《领域驱动设计》（Domain-Driven Design-Tackling Complexity DDD核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。 在昨天提出MODD这个概念时我说过，解决这个问题的关键在于人，这个人就是要懂得气象业务驱动模型设计的人，这个人所承担的职能一方面要深入理解气象业务，懂得气象业务的核心和关键点在哪里，另一方面还要懂得将业务体系通过模型创建表述出来
79120发布于 2020-06-01 Java业务系统平台架构：实现业务分析与详细设计
标题：Java业务系统平台架构：实现业务分析与详细设计 引言： 在当前的信息化时代，快速、高效地构建可靠的业务系统平台是企业成功的关键之一。 本文将详细介绍如何通过Java技术实现业务分析与设计，帮助读者构建一套高度可扩展、稳定可靠的业务系统平台架构。 数据库设计： 依据业务需求，设计数据库表结构，合理规范表字段和表关系。 选择合适的数据存储技术，如关系型数据库、NoSQL数据库等。 设计数据库访问层，包括DAO（数据访问对象）层，封装数据库操作，提供高效的数据访问接口。 3. 业务逻辑设计： 基于业务需求，设计业务逻辑处理层，将业务流程转化为可执行的代码逻辑。 利用领域模型、业务对象、服务等概念，建立清晰的业务模型。 考虑业务拓展性和可维护性，采用设计模式（如工厂模式、策略模式）进行设计。 4.
25510编辑于 2025-08-29- 来自专栏新亮笔记
业务驱动的应用架构设计
《业务架构·应用架构·数据架构实战》读书笔记 什么是应用架构？ 应用架构是—组应用系统及其交互关系的描述，其中的每个应用系统都是一个 “逻辑功能组” ，用于支撑业务功能、管理数据资产。 必须强调，应用架构不关注 “每个应用的内部” : 既不关注每个应用本身的架构； 也不关注每个应用的实现技术； 【注意】应用架构的目标，是 定义支持业务 和 处理数据 需要的哪些应用系统。 这些应用系统需要执行哪些操作才能管理数据并将信息呈现给企业人员； 应用架构中的 “应用” ，不应被描述为具体的计算机系统，而应被描述为 “逻辑功能组” ，这些逻辑功能组负责支持 “数据架构中数据对象的管理” 或支持 “业务架构中的业务功能 业务驱动的应用架构设计步骤
74050编辑于 2022-03-31 - 来自专栏架构之家
如何利用设计模式改善业务代码？
在业务部门的开发中，大多数的我们在完成的业务的各种需求和提供解决方案，很多场景下的我们通过 CRUD 就能解决问题，但是这样的工作对技术人的提升并不多，如何让自己从业务中解脱出来找到写代码的乐趣呢，我做过一些尝试 ，使用设计模式改善自己的业务代码就是其中的一种。 责任链设计模式 ▐ 模式定义 责任链模式(Chain of Responsibility Pattern), 是行为型设计模式之一。 这种简单的流程即可试用于我们当前业务场景。 这样负责积分消费次数累加和负责语音播报的订阅者就会收到“支付成功事件”，进而做各自的业务逻辑。
52130编辑于 2022-07-12 - 来自专栏新亮笔记
业务驱动的数据架构设计
《业务架构·应用架构·数据架构实战》读书笔记 什么是数据架构？ 数据架构是通过对齐企业战略得到的数据资产管理蓝图。 具体而言，该蓝图用于指导如何分析数据需求、如何做好响应设计。 数据架构描述企业的： 主要数据类型及其来源； 逻辑数据资产； 物理数据资产； 数据管理资源； 上述所有内容的结构和交互； 数据架构的五大设计内容： 数据类型及其来源 - 例如一个电商企业需要操作日志、生产库 、BI 库，这三类数据； 数据模型 - 例如日志模型、进销存模型、BI 星型模型，以及跨业务的主数据模型； 数据存储 - 例如日志采用文本文件存储，其他采用关系型数据库存储； 数据流 - 例如从查找商品
50510编辑于 2022-03-31 - 来自专栏数据库相关
【业务场景】短信日志表的设计
----+------------+---------+--------------+--------+---------------------+3 rows in set (0.00 sec)这种设计方案算是比较简单和通用的
23510编辑于 2025-08-06 - 来自专栏爱撸猫的杰
基于领域驱动设计的业务中台架构设计
软件设计首要面对的挑战是如何应对复杂多变的业务问题。而对于业务中台来说，这个问题变得尤为突出。 2003年，Eric Evans提出了名为领域驱动设计（Domain Driven Design）的领域建模方法，其基本思想是把我们对软件架构设计的关注点拉回到业务上，以业务领域驱动架构设计，从而达到解决控制软件复杂度并保持软件架构随业务演进的问题 随着最近几年微服务架构已成为软件技术架构设计的事实标准，DDD重新进入业界的视野并得到广泛使用，其天然能够很好分离业务复杂度的优点使它成为微服务划分甚至业务中台架构设计的最佳方法。 领域驱动设计的分层、分治 领域驱动设计的原则 识别与聚焦核心域 在探索问题域空间时，在战略层会得到关于按照业务范围区分的子域（Subdomain）。 解决方案域的领域建模与架构设计需要架构师与技术人员依据业务的输入进行深入的讨论、思考和抽象，并且需要向业务人员解释清楚建模的依据，以及验证模型是否具有足够的能力支撑业务。
1.4K31发布于 2020-07-16 - 来自专栏TechFlow
设计模式 | Catalog设计模式，抵御业务方需求变动
大家好，这是一个全新的专题——设计模式。 其实可以选择的专题还有好几个，为什么选择设计模式呢？原因也很简单，首先是设计模式简单、易学。干货的文章固然好，但是普适性往往不强。 设计模式简介 设计模式这个词我想大家应该都听说过，但是它究竟是什么意思可能很多人并不清楚。其实设计模式就是一种经验，就是一种前人总结出来反复印证过可以解决各种问题或者是做出各种优化的代码设计经验。 我们读大牛的代码常常惊叹，同样的功能他怎么这么简单就实现了，这个设计太巧妙了。设计模式就是这些令人惊叹的精彩设计的总结。第二种用途相对功利一些，是为了抵抗业务逻辑变动。 其中很重要的一个点就是业务逻辑的变动，昨天才说了这里要这么设计，突然过了两天就改了。或者是过了几天突然增加了一个之前没有想到的需求。 前面也说了设计模式是代码经验的总结和提炼，所以它也和语言特性有关，不同的语言实现出来的设计模式以及能够实现的设计模式也不一样。
61010发布于 2020-09-01 - 来自专栏Keegan小钢
App架构设计经验谈:业务层的设计
这样，业务层无疑就已经变为了一个数据中转站。 业务层的职责 所以，设计业务层之前，对业务层的职责要先真正理解清楚。这里，我举两个栗子说明一下。 第一个是新用户注册的例子。 所有这些都属于业务逻辑处理，也就是业务层的工作。 第二个是涉及用户验证的例子。 这些逻辑处理，也是业务层的工作。 因此，简单点说，业务层就是处理业务逻辑，包括数据的检查、业务分支的处理等。 业务层的交互 只有真正理解了业务层的职责之后，才能有效地设计业务层与外层的交互接口。 业务层向下，与数据层交互；向上，与展示层交互。 写在最后 业务层可以说是一个数据加工场，处理核心的业务逻辑。其实，只要理解清楚了业务层的职责，业务层就不难实现。
75120发布于 2018-08-10 - 来自专栏黒之染开发日记
服务端业务设计方案——用户系统表结构业务逻辑
这几年来不停在写需求，终于不想再闷头写业务了。希望记录下来一些自己验证过觉得蛮不错的方案，作为自己的沉淀，也方便大家一起交流，让这些方案更健壮和完善。 unique (id) ) comment '用户的登录方式' ; 基本上每个项目都允许用户有多种登录方式，以前的方式是把用户的账号密码写在用户表，但是扩展性不强，而且不同登录方式有不同的字段名，对于封装业务组件不方便 这样设计有个麻烦的地方，其实应该再增加一个密码表，因为每个用户也就只有一个登录密码，或者会有几个别的功能密码。 但是这种设计也能兼容这两个情况，只要登录密码统一拿type=1的记录，其它的功能密码，只要增加type即可。
86610发布于 2020-05-25 - 来自专栏架构进阶
企业级业务架构设计笔记三:设计起点与设计过程
企业级业务架构设计：方法论与实践 学习笔记 企业级业务架构设计：方法论与实践学习笔记二 1 摘要 本篇继续探讨业务架构设计篇，包括业务架构设计的起点、设计过程以及设计难点。 2 业务架构一般实现过程 业务架构面向企业战略和企业整体。它的一般实现包括设计和落地两个过程，并且设计与落地（升级）这两个过程是不断交替上升的。 落地过程：通过业务架构驱动IT设计、协调实施过程，建立业务架构元素与IT设计元素之间的联系，并在实施中对业务架构进行基于实现的最终调整，以确保业务架构与IT实现之间的一致。 3 业务架构设计 3.1 企业战略分析 战略作为业务架构分析的起点，业务架构设计必须透彻理解其战略。下图就是我们常见的企业战略设计模型（BMGovernance公司设计）。 企业级业务架构的整体逻辑，通过图可以表示如下： 5、 业务架构的设计难点 企业级业务模型的建设离不开标准化过程，因为做企业级模型需要横向对比分析企业的所有业务领域，以期在设计上实现“以更少支持更多”，
1.2K31编辑于 2022-12-01 - 来自专栏架构随笔录
大数据设计模式-业务场景-批处理
大数据设计模式-业务场景-批处理 一个常见的大数据场景是静态数据的批处理。在此场景中，源数据通过源应用程序本身或编排工作流加载到数据存储中。 对于批处理，通常需要一些业务流程将数据迁移或复制到数据存储、批处理、分析数据存储和报告层。 技术选型 对于Azure中的批处理解决方案，推荐使用以下技术 数据存储 Azure存储Blob容器。 许多现有的Azure业务流程已经使用了Azure blob存储，这对于大数据存储来说是一个很好的选择。 Azure数据湖存储。 许多大数据解决方案通过包括集中式在线分析处理(OLAP)数据模型(通常称为多维数据集)来模拟传统的企业业务智能架构，报告、仪表板和交互式“切片和骰子”分析可以基于该模型。
2.3K20发布于 2020-02-24
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号