- 综合排序
- 最热优先
- 最新优先
- 来自专栏哲学驱动设计
090609 T 领域建模
领域建模的重要性 以数据为中心的应用程序开发，面向过程分析方法的核心在于对数据库的设计。 而现在以面向对象的方式进行分析（OOA，OOD）时，领域建模就替换了上述方法的地位。 （需求和领域建模，是相互促进的两个过程。） 如何建模 1.首先应该以画图的形式进行建模。
49880发布于 2018-01-26 - 来自专栏大数据架构师成长之路
领域建模-总结
随着业务的变化、系统设计也要演进升级。好的架构设计一定演化来的，不是一开始就设计出来的，但系统演进过程中的成本，一定是最开始的设计决定的。一个健康公司的成长，业务横向、纵向会发展的会越来越复杂，支持业务的系统也一定会越来越复杂。在领域驱动设计中，域模型对应的是业务模型，是系统架构的内核，通过域模型来驱动与外界的交互。
1.1K50发布于 2020-06-22 - 来自专栏斑斓
或许是领域建模的真相？
我们一提及领域建模，就好像回到了石器时代。然而这个谜题至今还未解决，就好像穴居人的生存方式，我们只能猜测、推测以及演绎，却不能真实复现。 没有教会领域建模的方法，只有可意会不可言传的感觉。之所以还要提方法，不过是事后诸葛亮而已。 故而，我无法解答这是否“真相”，或许我以为找到了，其实不过是火堆将领域建模的方法投影到墙上，而我凑巧是那个被锁着的囚犯。 行文至此，其实我仅仅提出了问题。
87850发布于 2018-03-07 - 来自专栏软件方法
ECAD的领域建模和SysML扩展
modeling-languages.com/sysml-extension-ecad-electrical-cable-design/ 作者 Jordi Cabot 对ECAD（计算机辅助电子设计）的核心概念做了领域建模
82610发布于 2019-09-23 - 来自专栏全栈程序员必看
领域建模与数据库建模
面向对象与领域建模： 我也是引用的别人的 多变且复杂的需求 如果没有多变的需求，也许就没有今天的面向对象软件，我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击，可是这样下去的结果只有一个 不能期望软件人员也是其他领域专业人员，可是在中国现实中，很多人总是 无法分辨，例如某局长将整个机关考核信息化的任务交给电脑中心，这就是将考核管理专业和软件专业混同的例子， 在考核管理和软件之间需要一个领域建模专家 Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计 ）简称Evans DDD， 领域建模是一种艺术的技术 领域建模的重要性 如果你说一个软件开发需要经过需求、分析和设计三个阶段的话，那么可能反映你的思想已经落伍，软件开发现在是 经过需求、建模阶段，混合了分析和设计阶段，可以更激进地说：我们国家的系统分析员和系统设计员考试也许应该合并了 领域建模属于与具体.NET或Java技术无关的设计思想，有人总是说：.NET比Java简单，其实这又是一个大误区，如果都达到同样设计水准，无论使用.NET或Java，都需要付出同样的努力；那为什么有人觉得
95830编辑于 2022-07-31 - 来自专栏JAVA杂谈
架构师之路 - 业务领域建模
领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。概念比较深奥，其实说白了就是我们把基于对业务的理解画成一个类图，并画出这些类之间的关系（面向对象）。
1.3K30发布于 2021-05-11 - 来自专栏斑斓
代数数据类型与领域建模
逸言 | 逸派胡言 本文是函数式编程思想与领域建模的第一部分，重点讲解代数数据类型与领域模型之间的关系。
2K20发布于 2019-06-03 - 来自专栏斑斓
《解构领域驱动设计》领域建模篇
领域建模的过程，是模型驱动设计的过程，也是迭代建模的过程。 不可妄求一蹴而就能获得完整的领域模型，也不可殚精竭虑地追求领域模型的尽善尽美。 领域建模的分析、设计和实现是循序渐进的增量建模，建模目标与侧重点也不尽相同。 领域分析模型负责捕捉表示领域知识的领域概念，明确它们之间的关系，形成反映现实世界的对象概念图。 聚合是领域建模阶段的基本设计单元。
69920编辑于 2023-03-23 - 来自专栏ThoughtWorks
威胁建模——围绕假想敌的领域建模
简而言之，威胁建模是一个围绕假想敌开展的领域建模活动。 一些常见的威胁（攻击向量）就像领域建模里最细粒度的组件一样，共同组成了假想敌的攻击树。
1.1K20编辑于 2021-12-09 - 来自专栏京东技术
领域建模之数据模型设计方法论
开发人员在日常工作中，参与PRD评审、听产品经理讲述用户故事、提出各种需求。评审结束，一般会一股脑投入到设计开发，而数据库表设计就是其中不可或缺的一个过程。对于熟悉的业务模块，通过对需求分析，可以轻而易举的完成数据表设计，但对于非熟悉业务领域，可能会经过多轮PRD分析，整理一套数据表结构基础，然后对其追加字段，就完成了基础的数据模型设计。而在这个过程中，往往会感觉没有可以参考的理论，有时候甚至对设计的数据库表产生怀疑，不断考虑此设计是否符合业务、表结构设计后期是否具有通用性、表之间关系是否恰当可扩展等等。今天来谈些在实际业务开发中，针对数据建模的一些思考。
1.6K10编辑于 2021-12-28 - 来自专栏全栈程序员必看
数据仓库常见建模方法与大数据领域建模实例综述
随着从IT时代到DT时代的跨越，数据开始出现爆发式的增长，这当中产生的价值也是不言而喻。如何将这些数据进行有序、有结构地分类组织存储，是我们所有数据从业者都要面临的一个挑战。
2.5K22编辑于 2022-08-22 - 来自专栏京东技术
最全的【DDD领域建模】小白学习手册（文末附资料）
Tech 导读 DDD领域建模被各个大小厂商提起并应用，而每个人都有自己的理解，本文就是针对小白，系统地讲解DDD到底是什么，解决了什么问题，及一些建议和实践。 20多年前，顶尖的软件设计人员已经意识到领域建模和设计的重要性。尽管没有被清楚的表述出来，在对象社区涌动着一种新的思潮，Eric Evans把它称为领域驱动设计。 在面向过程，面向函数，面向对象的编程语言中，面向对象无疑是领域建模最佳方式。 类和表有以下几个显著区别，这些区别对领域建模的表达丰富度有显著的差别，有了封装、继承、多态，对领域模型的表达要生动得多，对SOLID原则的遵守也会严谨很多。 由于不再承载领域建模这个特性，数据库的设计可以变得天马行空，任何可以加速存储和搜索的手段都可以用上，可以用column数据库，可以用document数据库，可以设计非常精巧的中间表去完成大数据的查询。
3.3K33编辑于 2023-08-22 - 来自专栏程序员吾真本
OnD1操练纪要-微信朋友圈权限领域建模操练
操练题目：微信朋友圈权限领域建模操练 题目描述：为了提升开发人员编写正确的代码和用正确的方法编写代码的实践能力，可以使用逆向工程的思路和面向对象的分析、设计和编程（Object-Oriented Analysis , Design and Programming, OOADP）方法，为微信朋友圈权限（设置->朋友权限->朋友圈）中的“不让他（她）看”和“不看他（她）”两个功能进行领域建模，设计出包括属性和方法的领域类及其之间的关系 软件开发过程中的科目和阶段与“领域建模7步法” 1 需求启发：微信朋友圈权限控制功能 2 系统愿景：识别价值和痛点 3 系统上下文：识别用户和依赖系统 4 责任风暴：梳理服务、责任和业务规则 5 领域模型
41630编辑于 2022-12-11 - 来自专栏软件方法
团队内训-分析和设计高阶（领域建模和领域驱动设计）训练方案（202209更新）
本训练强化分析和设计（领域建模和领域驱动设计）的技能，使软件组织迈向基于核心域的复用，降低开发维护成本。 以下是UMLChina参与（书上有UMLChina标记）的分析和设计（领域建模和领域驱动设计）相关的书籍。 分析（领域建模） --建模方法学选择和基本概念 --提炼领域概念的要点 --核心域透镜 --DDD“新词”祛魅（通用语言、实体……） --提炼领域概念之间的关系 --不变式和对象约束语言OCL --彩色建模架构型介绍和应用
51820编辑于 2022-10-31 - 来自专栏软件方法
幻灯片03-剔除“伪创新” 的领域驱动设计-领域建模结构部分Part2
pdf文件下载：http://umlchina.com/training/umlchina_ddd_02_domainmodeling_structure.pdf
28010编辑于 2022-10-31 - 来自专栏服务端技术杂谈
换个角度看软件建模
用一句话讲领域建模的根本目的就是统一认识、减少沟通成本。 这句话听起来很简单，但其实有两个层面的含义：一是工程技术规范，指的是业内规范；二是业务认识，指统一业务、开发、测试、产品的认识。 然而要做到统一与规范是很难的，开发喜欢从技术层面去描述问题，产品习惯从业务层面描述问题，双方沟通成本较大，此时领域建模就能够起到“一图胜千言”的作用。 领域建模的关键是找到业务的流程节点，找到业务流程节点就成功了一半。正如在小学做阅读理解一样，重要的是概括文章中心思想和段落划分。 比如商品领域建模、优惠券领域建模等。 其次，模是模型，反映到业务上，模就是业务场景的映射，换言之，通过模型就能推导出业务场景，反之也一样，通过业务场景也能推导出模型，所以，不懂业务无法建模。 以上就是领域建模的三步方法，没有任何高深的理论，都是简单朴素的方法，但重要的是了解业务，因为领域建模源于业务，又服务于业务。
48910发布于 2020-05-27 - 来自专栏软件方法
幻灯片02-剔除“伪创新” 的领域驱动设计-领域建模结构部分Part1
pdf文件下载：http://umlchina.com/training/umlchina_ddd_02_domainmodeling_structure.pdf
28220编辑于 2022-10-31 - 来自专栏软件方法
幻灯片04-剔除“伪创新” 的领域驱动设计-领域建模结构部分Part3
pdf文件下载：http://umlchina.com/training/umlchina_ddd_02_domainmodeling_structure.pdf
20720编辑于 2022-10-31 - 来自专栏方丈的寺院
一次关于聚合根的激烈讨论
背景 之前有同事在分享DDD在闲鱼商品详情页的实践时，大家对闲鱼团队领域建模关于商品详情页的聚合根建模表示不认同。 因为这是面向页面建模，不是面向领域建模，将微服务拆分和领域建模混为一谈了 于是我以聚合根定义作为引子，结合组内在实践DDD过程中，聚合根随着业务查询复杂而导致聚合根不断膨胀的问题，提出借鉴CQRS读写分离的理念 通常我们说领域建模不应该去考虑微服务架构，工程结构，应该专注于业务。 但在实践过程中发现这并不是一个好的方式，或者说是可落地的。 因为业务领域建模完成后，还是要反映到系统架构中， 最终是要落地到代码实现，通过代码来表达出领域模型。所以说我们的讨论不应该是脱离 系统架构的。 但是当我们发现业务领域建模完，通过代码实践一段时间后，发现代码模型腐化了，这时候 我们首先思考的方向不应该是通过代码来纠正，而是应该回归到业务建模。
80820发布于 2019-08-05 谈DDD领域驱动设计，90%以上软件项目都没有完整实施DDD的必要
今天我准备接着跟大家聊一下领域建模和领域驱动设计。首先提出一个明确的观点，就是领域建模很多思想是相当好的。但是就当前大部分的软件开发项目来讲，90%以上的项目其实都没有去完整实践领域驱动设计的必要性。 领域建模思想-横向分层 第一个就是进一步讲一讲领域建模的思想。 大家都知道，领域建模的一个核心思想是一种横向分层领域驱动的思想，而我们传统的软件开发更多的是纵向从展现层到逻辑层到数据库层，一个个竖井式的纵向建设的思想。 而领域建模的思想，它更多是一种横向分层的思想，从领域建模的整体的架构里面可以看到它最下面是基础设施层，中间是核心的领域层，在上面是应用层。 这个才是领域建模、领域驱动最最核心的思想，这是我想强调的第一个点。
21800编辑于 2025-06-24
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号