- 综合排序
- 最热优先
- 最新优先
- 来自专栏GreenLeaves
领域驱动系列四之模型驱动
1、常规以类图作为领域模型开发存在的问题 传统型以技术为驱动的团队,往往喜欢通过类图来展示产品的模型,这样的模型往往存N个对象,这些对象往往存在复杂的关联,产品的创始人,可能能理解整个产品的架构思路,但是如果是新成员 而且假设这个类图代表的领域模型是正确的,但是当团队真正的去实现这个模型的时候,发现还是无法将这种错综复杂的模型转换成可存储可转换的事务单元.这里需要解释下,因为前面的文章介绍了,最小化抽象领域的概念,这是领域驱动设计的必然要求 领域模型种类很多,他们的目的也各有不同,且领域驱动设计要求,模型不仅能够指导前期的分析工作,而且还应该成为设计的基础,我们的代码也必须是结合模型的. ) C#之所以强大,因为他是面向对象并且基于建模范式,我们可以通过他来模拟现实种得场景和对象.像C这种面向过程式得语言,可能表现得比较无力. 5、模型驱动对于用户的重要性 当我们设计系统时,要尽可能让用户得到最多的可配置模型 而不是由IE自行处理,这样用户就变得非常的弱势,那么软件的用户可能随之减少. 6、模型驱动对于开发人员的重要性 如果在项目开发种架构师只负责搭建核心驱动程序的模型,而不参与业务模型的搭建,任由手下的开发随笔的去构建业务模型
1.2K20发布于 2019-01-03 - 来自专栏互联网技术栈
领域驱动模型（DDD）
什么是领域驱动模型? 领域驱动设计分为两个阶段： 1、以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型； 2、由领域模型驱动软件设计，用代码来实现该领域模型 而在业务知识梳理的过程中，我们必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计的基本概念。而领域驱动设计的核心就在于建立正确的领域驱动模型。 ? 领域驱动模型的一些要素 ? image.png 实体(Entity) & 值对象(Value Object) 实体与面向对象中的概念类似，在这里再次提出是因为它是领域模型的基本元素。 image.png 总结 领域驱动设计的核心是领域模型，这一方法论可以通俗的理解为先找到业务中的领域模型，以领域模型为中心驱动项目的开发。
4.2K11发布于 2018-12-12 - 来自专栏JAVA乐园
Spring 事件驱动模型
0x01：spring事件驱动组成 spring事件驱动由3个部分组成 ApplicationEvent：表示事件本身，自定义事件需要继承该类。
1.9K20发布于 2021-06-25 - 来自专栏斑斓
引入风险驱动模型
引入风险驱动模型 George Fairbanks提出的风险驱动模型（Risk-Driven Model）非常适合遗留系统的技术栈迁移。 所谓“风险驱动模型”，就是通过识别风险，对风险排定优先级；然后根据风险选定相关技术，再对风险是否得到缓解进行评估的一种架构方法[5] 。
2.3K110发布于 2018-03-07 - 来自专栏全栈程序员必看
linux内核驱动模型详解_arduino驱动安装
转载请标明出处floater的csdn blog，http://blog.csdn.net/flaoter Linux SPI驱动分为核心层，控制器驱动层和设备驱动层。 核心层是Linux的SPI核心部分，提供了核心数据结构的定义，总线、设备和驱动的注册、注销管理等，提供与上层的统一接口。 linux将I2C、SPI、USB等总线驱动隔离成控制器驱动和设备驱动，使两者相对独立。 本文以qcom的spi控制器为例，对spi控制器驱动进行解析。kernel代码版本是3.18。 linux驱动与设备是一对多的关系，在spi_master设备注册时，控制器的结构体信息会提供给spi_master作为私有数据。 3.3 厂商的总线传输 控制器驱动注册函数中进行了传输函数的赋值。
12.6K40编辑于 2022-11-02 - 来自专栏编程一生
架构视角 - DDD、TDD、MDD领域驱动、测试驱动还是模型驱动？
但是TDD测试驱动、MDD模型驱动好像也很火啊，到底什么在驱动？ 分析问题 不用着急，这是三个5分钟就能区分开的概念。开发中在协同工作。 首先纠正两个误区。 DDD是Domain-Driven Design领域驱动设计。但是TDD和MDD的D意思是Development开发的意思。TDD对应测试驱动开发，MDD对应模型驱动开发。 这就是为什么很多大佬在大谈特谈「领域」，但是测试驱动、模型驱动其实也都在用，但谈的少些。因为这是我等实际一线写代码的同学才用的。 解决问题 在Eric Evans的《领域驱动设计-软件核心复杂性应对之道》中第一节的消化知识开始就开始建模。在我们平时的设计开发中，在描述总体设计思路也需要用模型也表示。 fr=aladdin 这些本质上是模型驱动开发的一种方法。现在很多公司和组织在研究一些更方便建模的工具。基于MDA(模型驱动架构)的工具涌现的比较多了，但是基本都是收费的。
4.5K40发布于 2019-05-15 - 来自专栏全栈程序员必看
Struts2中属性驱动与模型驱动
属性驱动： 1、概念 能够利用属性驱动获取页面表单元素的内容 2、步骤 1、在action中声明属性，属性的名称和页面元素中 模型驱动： 1、假设页面上元素内容太多，用属性驱动实现，action中代码就会非常庞大，这个时候能够考虑用模型驱动来实现 2、步骤 1、action
60220编辑于 2022-07-09 - 来自专栏用户7344545的专栏
学Linux驱动:你应该先了解驱动模型
注：代码分析基于linux-5.4.31 为啥要驱动模型 随着系统结构演化越来越复杂，Linux内核对设备描述衍生出一般性的抽象描述，形成一个分层体系结构，从而引入了设备驱动模型。 Linux内核驱动程序模型是先前在内核中使用的所有不同驱动程序模型的统一。 它旨在通过将一组数据和操作整合到全局可访问的数据结构中，来扩展基于基础总线来桥接设备驱动程序。 驱动模型抽象了啥 当前驱动程序模型为描述总线和总线下可能出现的设备提供了一个通用的、统一的模型。 特定于设备的驱动程序也可以在其目录中导出文件，以暴露特定于设备的数据或可用接口。 驱动模型实现 先来梳理一下内部几个主要与驱动模型相关的数据结构： . 总体上而言： 通过上面一些关键数据结构关系分析，总线设备驱动模型最终目的是实现如下这样一个分层驱动模型。
3.6K11发布于 2020-06-03 - 来自专栏Linux内核深入分析
Linux设备驱动模型-Kset
当多个kobject属于同一类的时候，为了方便管理，就引入了Kset。Kset可以认为是一组kobject的集合，是kobject的容器。
4.4K61发布于 2020-03-24 - 来自专栏Linux内核深入分析
Linux设备驱动模型-Kobject
Kobject是linux设备驱动模型的基础，也是设备模型中抽象的一部分。如果想了解设备驱动模型就需要明白Kobject的构成或原理。 通常驱动程序员很少使用到kobject结构及其相关接口，而是使用封装之后的更高层的接口函数。 Kobject结构体 内核使用kobject来表示内核一个对象。 init_name; /* initial name of the device */ const struct device_type *type; Kobject相关操作函数 kobject相关的操作函数一般驱动程序员是不会直接操作的
6.3K32发布于 2020-03-24 - 来自专栏Linux内核深入分析
Linux设备驱动模型-Driver
前言 linux将所有的驱动抽象为struct device_driver结构。这样设计可以方便驱动程序更好编写，在编写驱动的时候只需要将此结构嵌入到具体的驱动中即可。 bus： 设备驱动所属的总线 owner: 设备驱动的owner，通常为THIS_MODULE suppress_bind_attrs: 通过sysfs操作设备驱动的bind/unbind, groups: 设备驱动的属性。 p: 设备驱动的私有数据结构，通常可以将驱动的信息放入此结构中。 和设备一样，内核也为设备驱动定义了一些驱动的宏属性，方便定义驱动属性。 B: 将具体的驱动添加到所属的总线，这是注册驱动的核心函数。
5.5K30发布于 2020-03-24 - 来自专栏Linux内核深入分析
Linux设备驱动模型-Ktype
it */ if (name) { pr_debug("kobject: '%s': free name\n", name); kfree(name); } } 所以基于上述的执行路径，在驱动的
5K21发布于 2020-03-24 - 来自专栏Linux内核深入分析
Linux设备驱动模型-Device
这样设计之后就方便驱动开发工程师编写驱动，只需要将具体的设备包含struct device结构，具体的驱动包含struct device_driver结构。 C: 关于总线先设备与驱动的匹配是设备驱动模型的核心 void bus_probe_device(struct device *dev) { struct bus_type *bus = dev-> probe，这下知道驱动的probe函数是如何调用的。 if (ret) goto probe_failed; } driver_bound(dev); //将设备所属的驱动加入到驱动链表中 device_attribute dev_attr_##_name = __ATTR_WO(_name) 关于设备属性的调用过程，最终会调用到设备的show和store函数中，具体的流程分析可见Linux设备驱动模型
9K21发布于 2020-03-24 - 来自专栏Linux内核深入分析
Linux设备驱动模型-Bus
前言 在linux设备驱动模型中，总线可以看作是linux设备模型的核心，系统中的其他设备以及驱动都是以总线为核心围绕。不过驱动程序员在系统中创建一条总线的机会并不多。 驱动模型中的总线可以是真是存在的物理总线（USB总线，I2C总线，PCI总线），也可以是为了驱动模型架构设计出的虚拟总线（Platform总线）。 为此linux设备驱动模型都将围绕"总线--设备--驱动"来展开，因为符合linux设备驱动模型的设备与驱动都是必须挂载在一个总线上的，无论是实际存在的或者虚拟的。 .match: 当一个设备或者驱动添加到此总线上的时候，bus就会调用match对设备和驱动一一匹配的。 p: 一个用来管理总线上设备与驱动的数据结构。
5K20发布于 2020-03-24 - 来自专栏HackforFun
U-Boot 驱动模型
最近拿了一块 Firefly 的开发板，主控是 RK3308，发现上面用的 U-Boot 是 2017 年的，于是想移植一个最新的版本上去，调试驱动的时候，总结了这些经验。 U-Boot DM 三要素 DM 是 U-Boot 中的驱动框架，全称 Driver Mode。 driver 是与这个设备匹配的驱动。 uclass 是同一类设备的抽象，提供管理同一类设备的抽象接口。 udevice ? 还有部分特殊的驱动，他们并不存在实际意义上的设备，比如 MMC 子系统中的 mmcblk 驱动，该驱动主要是把所有的 mmc 设备注册到更上一层的 blk 子系统中，向 blk 层提供操作 mmc 设备的 显然，这个驱动位于抽象层，它不和具体的硬件设备直接交互，并不适合用一个 dts(dts 是用来描述具体的硬件信息的) 节点或者 UBOOTDEVICE(_name) 宏来为这个驱动显示的申明设备。
4.1K40发布于 2020-01-13 - 来自专栏嵌入式Linux系统开发
Linux USB 设备驱动模型
BUS/DEV/DRV 模型 "USB 接口"是逻辑上的 USB 设备，编写的 usb_driver 驱动程序，支持的是"USB 接口"： USB 控制器或 Hub 识别出 USB 设备后，会创建、 注册 usb_device usb_device 被"drivers\usb\core\generic.c" 驱动认领后，会选择、设置某个配置 这个配置下面的接口，都会分配、设置、注册一个 usb_interface 接口函数 在 USB 设备驱动程序中，能使用的 USB 函数都在这个头文件里：include\linux\usb.h。 已经提交的 URB，可以取消它，有 2 个函数： usb_kill_urb：这是一个同步函数，它会等待 URB 结束 usb_unlink_urb：这是一个异步函数，它不会等待 URB 结束，USB 控制器驱动会调用它的回调函数
4.3K40编辑于 2023-08-22 - 来自专栏Linux内核深入分析
Linux设备驱动模型-Uevent
前言 当一个设备动态的加入到系统时候（比如常见的将U盘插入到PC机器上）， 设备驱动程序就需要动态的检测到有设备插入了系统，就需要将此事件通知到用户层，然后用户层对这一事件做响应的处理，比如加载USB驱动 Linux系统对uevent机制的具体实现是建立在设备模型的基础上的，通过kobject_uevent函数实现。 在前面的kset小节中提到了注册一个kset的接口，可以在这里习复下。
4.9K41发布于 2020-03-24 - 来自专栏Linux内核深入分析
Linux RTC驱动模型分析
linux为新的接口设计一套驱动模型，如果驱动工程师想增加某一个驱动，只需要将芯片相关的代码编写，然后注册到rtc核心层中即可。 RTC驱动框架 RTC涉及的代码如下： driver/rtc/class.c: 此文件向linux内核驱动模型注册了一个类RTC, 同时为底层的RTC驱动提供了注册/注销RTC接口。 driver/rtc/rtc-xxx.c: 各式各样的rtc驱动。 RTC的模型图如下： ? 通过上图可以清晰的看出class.c为各种各异的驱动提供了注册接口。 ，当驱动程序使用rtc_device_register函数传递正确的参数，然后就返回struct rtc_deivce给驱动程序。 而在这个结构中rtc_class_ops函数需要驱动程序实现。 2.
6.6K41发布于 2020-03-24 - 来自专栏GreenLeaves
领域驱动系列五模型驱动设计的构造块
一、简介 为了保证软件实现的简洁性,并且与模型保持一致,不管实际情况有多复杂,必须使用建模和设计的最佳实践,即让通过我们的编程技术(设计模型、指责驱动、契约式设计)充分地体现领域模型,并保持模型地健壮性和可扩展性 ,而不是单单地实现模型.某些决策设计能和模型紧紧地结合,这种结合要求我们注意每个元素地细节. 开发一个好的领域模型是一门艺术,而模型中的各个元素的实际设计和实现则相对系统化,将领域设计(也可以是软件系统中的其他关注点)与软件系统中的其他关注点(也可以是领域设计)分离使整个领域模型非常的清晰.根据不同模型的指责 上图展示的模型驱动设计的基本构造块,当然实际开发中可能不止这些内容,可能还会有施加在实体上的一些契约还有一些特殊的计算规则、可能还有有一些复杂的实体运算,这些运算可能还需要使用一些设计模式去设计等等.但这个基本的构造 summary> /// 用户聚合根工厂,按照计价策略生成对应的用户实体,这个类会暴露给外面的业务结构使用 /// 将业务逻辑的处理交给工厂类,这样做的好处,是减轻控制器的压力,也符合领域驱动设计的理念
1K10发布于 2019-01-03 - 来自专栏架构师修炼
DDD领域驱动设计 — 贫血模型与充血模型
前言 要想深入掌握和了解 DDD 领域驱动设计的核心，那无论如何也绕不开两大较为抽象的概念——“贫血模型”、“充血模型”： 贫血模型即事务脚本模式。 充血模型即领域模型模式。 | 贫血模型 贫血模型最早广泛应用源于EJB2，最强盛时期则是由Spring创造，将： “行为”（逻辑、过程）； “状态”（数据，对应到语言就是对象成员变量）。 如今，面向对象的概念已经传播得很广泛了，而要反对这种贫血领域模型的做法，还需要更多论据。贫血领域模型的根本问题是，它引入了领域模型设计的所有成本，却没有带来任何好处。 将行为放入领域模型，这点和分层设计（领域层、持久化层、展现层等）并不冲突。因为领域模型中放入的是和领域相关的逻辑——验证、计算、业务规则等。 但是，这并不意味着领域模型就不应该包含行为。事实上，service层需要和一组富含行为的领域模型结合使用。
94431发布于 2021-11-12
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号