百科生活 投稿
关于【什么是存储程序概念】:什么是存储程序概念，今天涌涌小编给您分享一下，如果对您有所帮助别忘了关注本站哦。
- 内容导航：
- 1、什么是存储程序概念
- 2、解读《领域驱动设计 软件核心复杂性应对之道》（一）
1、什么是存储程序概念
1、“存储程序”原理，是将根据特定问题编写的程序存放在计算机存储器中，然后按存储器中的存储程序的首地址执行程序的第一条指令，以后就按照该程序的规定顺序执行其他指令，直至程序结束执行。
2、1945年，美籍匈牙利科学家冯·诺依曼（J.VonNeumann）提出的，是现代计算机的理论基础。现代计算机已经发展到第五代，但仍遵循着这个原理。
3、存储程序和程序控制原理的要点是，程序输入到计算机中，存储在内存储器中（存储原理），在运行时，控制器按地址顺序取出存放在内存储器中的指令（按地址顺序访问指令），然后分析指令，执行指令的功能，遇到转移指令时，则转移到转移地址，再按地址顺序访问指令（程序控制）。
2、解读《领域驱动设计 软件核心复杂性应对之道》（一）
最近学习了两遍《领域驱动设计 软件核心复杂性应对之道》。这本书是2000年出头由一个老外写的。然后经过了国人翻译。
2000年出头，技术架构还没有现在这么多好用的工具，也没有云原生的概念。这几年，随着云原生、微服务概念的兴起。这本书又被大家重视了起来。因为书中的很多理念，在现在的技术背景下，有很多的指导意义。大道至简，一些形而上学的东西往往是比较难说清楚，也比较难悟透的。就像孔孟的好多经典语句，放在当下时代，对我们仍然有很大的指导意义。这本书就是试图在说软件开发里面的道理。
开始读起来会有些别扭，但是入境之后，感觉还行，主要适应的作者的叙述方式即可。这本书，按照作者的说法，是一本为面向对象软件开发人员编写的数据。作者试图通过一些例子让大家理解。但是这些例子大都需要对例子背后的业务常识有较深的理解（毕竟DDD强调的是业务与系统的配套与融合）。而理解这本书就有点难了，再去理解一遍业务，就更费时间了。这往往也是开发人员最不愿意做的事情。我觉得这是这本书难啃的部分原因吧！
张逸写了一本《解构领域驱动设计》。这本书，在试图用现代技术的思维解读领域驱动设计。大家可以参考学习。但是学习二手的，不如学习一手的。这样也好有自己的理解。可以两本书结合着看，但重点还是读好原著。
作者在书中多次提到，领域驱动设计并不是要求一开始就设计出完美的系统。我们需要不断重构、不断精进。可以是对老系统进行领域驱动改造。也可以新系统直接使用领域驱动去设计。但谁也不能保证新系统在设计后，不会再次优化架构。本书只是在你优化时，给你提供一些指导思想罢了。重要的是思维方式，而不是最后的形态。因为架构总是在演进的，而方法论却可以一直陪伴我们。
这本书共分为4部分。有几个重点的章节。作者也在绪论里提了，可以选读。
第一部分，运用领域驱动模型
该部分提出了领域驱动设计的目标，后续章节都围绕这些目标展开讨论
第1章 消化知识
我们需要不断地学习业务知识，并和系统现状结合，提炼出模型，这是一个长期的过程。模型一定要和最终的实现保持同步。模型只需要展示重要部分，体现主要矛盾，无需面面俱到。
第2章 交流与语言的使用
建立团队通用的沟通语言UBIQUITOUS LANGUAGE 。
第3章 绑定模型与实现
要把代码的编写与模型紧紧结合起来。模型不能是空中楼阁，要能对程序设计产生指导意义。其中设计模式起到了粘合剂的作用。利用一些设计模式（书中叫“范式”），可以建立模型与技术实现之间的桥梁。建模人员必须花时间了解代码。通过技术实现中的反馈，动态调整模型。做一个亲身实践的建模者（HANDS-ON MODELER）。
一句话总结第一部分内容：MODEL-DRIVEN DESIGN利用模型来为应用程序解决问题。项目组通过知识消化将大量杂乱无章的信息提炼成实用的模型。而 MODEL-DRIVEN DESIGN将模型和程序实现紧密结合。UBIQUITOUS LANGUAGE 则成为开发人员、领域专家和软件产品之间传递信息的渠道。
第二部分，模型驱动设计的构造块
怎么理解模型驱动设计这句话，需要分开来看，模型，即“通过分析领域知识，抽象出的模型”，“设计"指的是技术实现的设计方案。整体上就是通过模型怎么指导技术方案设计出来。构造块是一些可以复用的、用于做出技术方案的元素。整体解释下就是”设计出模型之后，模型需要为开发方案指明方向和思路。这个过程中，有些元素是可以作为构造块参考复用的“。这些构造块都有啥，请看下图
第4章：分离领域
将领域层独立出来是实现领域驱动设计的前提。通过分层LAYERED ARCHITECTURE，将领域层摘出来。领域层的逻辑不要与界面层、应用层、基础设施层混为一谈。比如之前盛行一时的jsp，就很容易将业务逻辑与显示逻辑混在一起。再比如现在数据库中的触发器、存储过程、视图就是在基础设置层掺入了业务逻辑。这样都会给架构的分析与整合带来麻烦，使之更加复杂。个人认为数据库触发器这种工具，作为生产问题临时的补救措施还是可以的，作为架构的一部分则不妥当。
层分号之后，各层之间还要进行松耦合的通讯，可以通过SERVICE。上层依赖下层，下层不能依赖上层。将各层关联起来。我们可以依赖一些框架，比如SSH、SSM做实现，但是不能因为框架限制了领域驱动的设计。好在现在的框架已经对领域驱动设计越来越友好了，比如最近兴起的微服务框架。领域驱动设计只需要在一个特定的层存在即可。
领域驱动设计适用于大型的复杂的软件系统，如果只是实现比较简单的功能，直接采用SMART UI （智能UI，将业务逻辑和显示逻辑混为一体）即可。现在出现的低代码编程也是这种情况。每种设计方案，都有自己的使用场景。我们要明确的是SMART UI模式（及其类似模式）与领域驱动的理念是互斥的。
第5章：软件中所表示的模型
用模型来指导技术架构的设计时，在贴近技术实现这层，可用到一些元素，如ENTITY、VALUE OBJECT、SERVICE、MODULE。模型的元素之间，是具有关联性的。同时，我们在用模型指导技术实现时，也可以利用一些目前已经成型的范式（根据前人经验总结的固定模式）。
关联的概念
模型中每个关联都必须是可遍历的，同时在具体实现时，要考虑这种关联性和遍历性。至少有3种方法可以使得关联更易于控制：（1）规定一个遍历方向；（2）添加一个限定符，以便有效地减少多重关联；（3）消除不必要的关联。模型中的关联越少越好，越简单越好。
5.1ENTITY
ENTITY的概念
由标识定义的对象被称为ENTITY。ENTITY可以是任何事物，只要满足两个条件即可，一是它在整个生命周期中具有连续性，二是它的区别并不是由那些对用户非常重要的属性决定的。ENTITY可以是一个人、一座城市、一辆企业或者一次银行交易。这里重点注意下标识的概念。标识不是属性，是一个保证唯一性的符号。模型必须定义出“符合什么条件才算是相同的事物”。
在现实世界中，并不是每一个事物都必须有一个标识。同一个事物，在某些领域模型中需要表示为ENTITY，某些领域模型下，则不需要。比如座位，在预定程序种，如果座位不同价格不同，则座位需要表示为ENTITY进行区分；如果座位都是一个价格，则不需要区分。
如何定义ENTITY的标识
某些数据属性或者属性组合可以确保它们在系统种具有唯一性，或者在这些属性上加一些简单约束可以使其具有唯一性。这种方法为ENTITY提供了唯一键。利于，日报可以通过名称、城市和出版日期来识别。当对象属性没办法形成真正唯一键时，另一种经常用到的解决方案是为每个实例附加一个在类中的唯一的符号（如一个数字或者字符串，即ID）。ID通常是由系统自动生成的。当自动生成ID时，用户可能不需要看到这个ID，只是系统内部进行区分即可；也能需要看到，比如一个包裹的单号。某些情况下，需要确保ID在多个计算机系统之间具有唯一性。比如，需要在两家系统相互独立的医院之间交换医疗记录。
5.2 VALUE OBJECT（值对象）
一个对象时用来表示某种具有连续性和标识的事务的呢（可以跟踪他经历的不同状态，甚至可以跨不同的实现跟踪它），还是用于描述某种状态的属性呢？这是ENTITY和VALUE OBJECT之间的根本区别。在不同的场景下，ENTITY和VALUE OBJECT认定会有所不同。某些对象在某些领域场景下会被认定为VALUE OBJECT，某些场景下又会被认定为ENTITY。
VALUE OBJECT的概念
很多对象没有概念上的标识，他们描述了一个事物的某种特征。用于描述领域某个方面而本身没有概念标识的对象成为VALUE OBJECT。VALUE OBJECT被实例化之后用来标识一些设计元素，对于这些设计元素，我们只关心它们是什么，而不关心它们是谁（这句话有点抽象，举个例子，我们换了一个流程图。重要的值标识的这个流程，而不是这个流程图是用什么笔画的）。VALUE OBJECT经常座位参数在对象之间传递消息。他们常常是临时对象，在一次操作中被创建，然后被丢弃。VALUE OBJECT应该是不变的。不要为其分配任何标识，而且不要把他设置ENTITY那么复杂。
VALUE OBJECT的实现形式
VALUE OBJECT可以通过两种方式存在于架构中：复制和共享。复制就是在不同的对象之间传递VALUE OBJECT；共享就是各对象保留一个对VALUE OBJECT的指针引用。若VALUE OBJECT被严格的限制了不可变更，或者程序在考虑性能时希望减少对象数量，则共享就是一个很好的选择。VALUE OBJECT不可变这件事，如果不能从技术上加以约束，就要从制度、会议或者文档上加以强调，以保持VALUE OBJECT的稳定。
VALUE OBJECT之间应避免使用双向关联
我们应该尽量完全清除VALUE OBJECT之间的双向关联，因为说一个对象指向的对象正式那个指向它的对象没有任何意义。如果你在模型中感觉确实需要这种关联，则应重新考虑将对象声明为VALUE OBJECT是否正确。
5.3 SERVICE
SERVICE的概念
模型中的独立接口，称为SERVICE。应用层、基础设施层、领域层都可能涉及SERVICE。比如发送邮件服务，属于基础设施层的服务。咱们这里只谈领域层的SERVICE。领域层的SERVICE和应用层的SERVICE有时候界限比较模糊。主要区分方法时，看SERVICE的功能有没有对应一个业务概念。比如转账服务，对应的时“转账”的这个业务概念。在核心逻辑的实现上，是属于领域层的；在数据的传入传出方面来讲，可能就是属于应用层的。个人感觉，这个倒不是很重要。咱们只要指导在领域层，有SERVICE这个概念元素即可。
SERVICE的粒度
SERVICE的粒度不能太细，太细容易把领域知识泄漏到应用层。当然也不能太粗，太粗对于应用层来说，不能通过灵活的调用配置，实现多样化的功能。中等粒度，无状态的SERVICE更容易被复用，并有助于在应用层和领域层之间保持一条明确的界限。
SERVICE的实现
现在很多框架，都有对接口的具体实现，但是我们要清楚的是，这些框架只是SERVICE的提供机制，而不是有意义的领域对象。现在微服务的兴起，为SERVICE的繁荣发展，注入了新的活力。
未完待续。。。。。。
本文关键词：什么是存储程序概念?，存储程序的概念是什么 为什么它很重要，程序存储的概念，什么是存储程序概念的核心，什么是存储程序概念界定。这就是关于《什么是存储程序概念，什么是存储程序概念和特点（软件核心复杂性应对之道》）》的所有内容，希望对您能有所帮助！
- 最近发表