DDD:主键映射,你一直在使用的企业应用模式
名称解释
主键映射是为了保证一个业务事务(请求)内只访问或修改一份领域模型。基本的思路是在内存中维护一个映射表,映射表的键为领域模型的主键,值为加载的领域模型。工作原理如下:
- 根据主键加载:先判断映射中有没有,有就直接从映射中返回,没有就从数据库加载,然后添加进映射再返回。
- 根据查询加载:先从数据库加载所有满足条件的领域模型集合,然后遍历这个集合,用1的算法处理每个加载的领域模型,返回新的集合(集合.Map算法)。
总之,主键映射会保证整个业务事务发生的过程你只会引用到一个内存引用,你自己实现主键映射也要保证这个语义。
图片示意
不用主键映射会出现什么问题?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
using System; using Microsoft.VisualStudio.TestTools.UnitTesting; using System.Linq; using System.Transactions; using System.Threading; namespace TSTest { [TestClass] public class 工作单元测试 { [TestInitialize] public void 初始化数据() { using (var context = new TestEntities()) { foreach (var table in context.Tables) { context.Tables.Remove(table); } context.Tables.Add( new Table() { Id = Guid.NewGuid(), Name = "李妞妞" , Age = 26 }); context.SaveChanges(); } } /// <summary> /// 因为EntityFramework的DbContext封装了主键映射,所以这里模拟一次用了两个主键映射。 /// 用多个或没有用主键映射都可能导致一些逻辑异常 /// </summary> [TestMethod] public void 两个主键映射_或_没有主键映射_都会出现的问题_测试() { using (var context = new TestEntities()) { var user = context.Tables.First(); this .修改年龄(); //因为两处的修改逻辑修改的是不同的内存实例,如果后续的逻辑中有用到Age属性,就会出现业务逻辑异常。 //正常的期望是这里会变成26 Assert.AreEqual(26, user.Age); user.Name = "段光伟" ; context.SaveChanges(); } } private void 修改年龄() { using (var context = new TestEntities()) { var user = context.Tables.First(); user.Age = 28; context.SaveChanges(); } } } } |
主键映射的生命周期管理
参考此文:DDD:管理“工作单元实例”的两种模式
自上世纪中后叶以来,随着信息技术的发展,各个工业、制造业领域,甚至是在人们的日常生活领域中,自动化以及效率提升等方面均得到了长足的发展,因此各个领域也纷纷加大了对信息技术的投资,从而形成了一个良性的循环。可以说,借助于信息技术的发展,人们的工作方式得以从传统的“蓝领式”的工作方式逐步转变为“白领式”的工作方式。随着时间的推移,企业中的信息系统越来越复杂,而且业务与信息系统的关系也日趋紧密,从而使得组织或企业中信息系统的优劣直接影响了其竞争力的强弱。随着这股以自动化和高效化为目标的潮流的演进,各个组织和企业对于信息系统的发展不约而同地走上了“技术驱动”的道路,不过IT技术在带来便利的同时也引起了业务和职责范围的扩大,这使得企业或组织中信息系统的结构也渐为复杂,之前靠纸笔或少量信息系统的方式已疲于应付,诸如信息孤岛之类的顽疾所带来的问题也逐渐凸显,而由于无法掌握全面的信息而产生的错误决策所带来的负面影响却在自动化和高效化的帮助下被进一步放大,IT技术沦为双刃剑,而这正是由于企业对信息技术发展的态度依然保持着自动化和高效率化的惯性思维,而并没有注意到境况已经发生了变化,他们在信息系统的发展过程中仅仅关注于眼前问题的解决,而忽视了他们自身的环境以及其已经具备的信息化资源,从而缺乏全局性的眼光来指导信息化系统的建设。甚至在一些业务部门与信息技术部门脱节相对严重的组织内部,企业的信息化建设与企业的核心业务的不平衡发展日渐严重:一方面企业的业务部门还在用较为落后的办公软件进行日常业务的维护和发展,另一方面企业的信息技术部门却仅仅因为信息技术的发展,不顾业务环境的真实境况而进行着信息系统的更新换代,而企业的决策者们却苦于没有足够的全局化的视角和手段在这两者之间进行决策和协调。
上面提出的问题,其根本原因是企业长期以来一直秉承“技术驱动”路线,而没有意识到环境已经发生变化,并且当前企业和组织中的信息系统的数量和复杂度与以前相比都不可同日而语,同时企业和组织的业务与信息系统之间的关系也越来越紧密。信息技术在将人们的工作方式变为“白领式”之后,其发展方式不应该是按照“技术驱动”的惯性前进,而应该使人们的工作更加“智能”。这里所说的“智能”,并不仅仅包括前述的“自动化”和“高效化”,其主旨是使人们工作于一个信息完备且条理清晰的工作环境之中,从而人们可以在给信息系统发布指令之前确保其决策是符合现实环境并经过深思熟虑的,且对指令发布后的结果以及影响均也能有一定程度的了解和评估,也只有在这样的环境中,人们才能真正了解自己所要完成的工作、所处的工作环境以及他们之间的关系,从而重用企业中的各种信息资源并得出切实可行的决策。
综合来说,随着信息化的发展,企业逐渐开始面对两个问题:
- 系统复杂度升高,并越来越难以进行管理。
- 业务和信息技术之间的关系虽然越来越紧密,但是却越来越不同步。
这两个问题的本质可以概括为“复杂”二字,因而这些问题的解决最终还是要落实到“复杂度管理”之上,而企业架构以及企业架构框架理论在本质上正是将企业或组织看作为复杂的客观对象,并对其在各个领域(战略决策、业务、数据、应用、技术和项目实施)中的复杂度进行有效管理,从而辅助企业或组织健康发展的学说。由此可见,解决以上两个问题的方法就是以企业架构以及企业架构框架理论为指导,在企业或组织中建立完备并且准确的企业架构。
要正确掌握企业架构相关理论与技术,首先要准确界定“企业”、“架构”、“企业架构”、“框架”、“企业架构框架”等概念。
- 什么是企业:企业架构中所指的企业并不是通常在商业环境中所定义的企业,按照《TOGAF Version 9》 的定义,企业是对一个组织的最高层次的描述,一般涵盖该组织的全部使命和功能。一个企业通常会跨越多个组织(The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations.)。由此可见,这里的“企业”是一个用于描述组织的抽象概念,强调的是组织的使命、功能与单一的基线,以及其组成。它既可以代表具体的一个公司、企业或政府,也可以是公司、企业或政府管辖之下的某个部门或部门集合,而具体的 “企业”的范围是什么,应该由驱动企业架构建立的需求范围来决定。
- 什么是架构:在ISO/IEC 42010: 2007中,架构被定义为:一个系统的基础组织,具体体现为其所包含的各个组件、组件之间以及与外部环境之间的关系,以及用于指导架构的设计和演进的各项原则(The fundamental organization of a system embodied in its components,their relationships to each other,and to the environment, and the principles guiding its design and evolution)。
经过若干年的修订后,在ISO/IEC 42010: 2011中,这一关于架构的定义又被修改为:一个系统在其所处环境中所具备的各种基本概念和属性,具体体现为其所包含的各个元素、他们之间的关系以及架构的设计和演进原则之中(<system> fundamental concepts or properties of a system in its environment embodied in its elements,relationships,and in the principles of its design and evolution)。
根据《TOGAF Version 9》所述,TOGAF 9对于架构的定义涵盖了ISO/IEC 42010: 2007中对于架构定义的各个方面,并以此为基础做出了自己的解释:
-
架构是以指导某个系统的实施为目标的有关该系统的形式化描述,或在组件级别为此系统的实现而制定的详细规划。(A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010: 2007).)
-
架构描述了组成系统的各个组件在系统中的布局、它们之间的相互关系以及用于对这些组件的设计和演进进行治理的各项原则及指南。(The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution overtime.)
-
- 什么是架构描述:在ISO/IEC 42010: 2007中,架构描述被定义为:用于记录架构的产品集合(A collection of products to document an architecture)。而在ISO/IEC 42010: 2011中,这一定义被修订为:用于对架构进行表述的工作产品(Work product used to express an architecture)。
- 什么是视角和视图:企业架构的主要用处是在企业或组织的各个干系人之间建立起一座无障碍沟通的桥梁,因而“沟通”是企业架构的主要精神之一。这里所说的“沟通”,不单单指的是人与人之间的沟通,业务信息系统本身也可以被看作是“干系人”,只不过他们所需要的企业架构的描述信息在抽象程度上比自然人更加精细、其所使用的语义也更加规范罢了。即便不考虑各种干系人中的自然人与信息系统之间的不同,不同自然人之间由于其背景、责任的差异,其对于企业的关注点也具有很大的不同,而这些不同也造就了各种不同的视角(ViewPoint)。通过不同视角观察所得的关于企业的某一侧面形象就产生了此视角之下的一份视图(View)。一言以蔽之,视角用于描述从何处看,而视图则是看到的内容,视角是视图的模式,而视图是视角的实例化结果。
在ISO/IEC 42010: 2007中,视角和视图分别定义如下:
视角(Viewpoint):一份与构建和使用视图相关的各项规范的说明。借助于对视图的目标和受众所进行的明确,以及在视图的创建和分析过程中所采用的各项技术,视角还可作为各个视图的开发模式或模板(A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and techniques for its creation and analysis)。
视图(View):站在一组相互关联的关注点的角度之上对整个系统所进行的表述(A representation of a whole system from the perspective of a related set of concerns)。
在ISO/IEC 42010: 2011中,视角和视图的名称发生了变化,在他们的名字之前分别增加了“架构”这一名词,而他们的定义也被修订为:
架构视角(Architecture Viewpoint):(work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns)。
架构视图(Architecture View):(work product expressing the architecture of a system from the pe rspective of specific system concerns)。TOGAF 9中的定义多来源于ISO/IEC 42010: 2007,但也有着其自身的特点。在《TOGAF Version 9》中,视角和视图被分别定义为:
视角(Viewpoint):一个针对某视图所采用的观察角度的定义,是构建和使用某视图的规约的描述(通常采用一个适当的模式或模版的形式)。通俗的说,视图描述了所看到的内容;而视角则描述了站在何处进行观察——一个能够决定你所能看到的事物的制高点或角度。(A definition of the perspective from which a view is taken. It is a specification of the conventions for constructing and using a view (often by means of an appropriate schema or template). A view is what you see; a viewpoint is where you are looking from — the vantage point or perspective that determines what you see)。
视图(View):针对一系列相互关联的关注点的表达。一个视图描述了采用某个视角后所看到的事物。架构视图可以通过模型来进行表述,从而为不同的干系人根据各自针对架构的关注点而分别提供描述。一个视图从本质上讲不一定以可视化或图形化的方式进行展示。(The representation of a related set of concerns. A view is what is seen from a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture. A view does not have to be visual or graphical in nature)。 - 什么是干系人:在早期的ISO/IEC 42010: 2007中并没有关于干系人(Stakeholder)这一概念的定义,但之后的ISO/IEC 42010: 2011却对此作出了这样的定义:对系统具有利益关系的个人、团队、组织或其种类(<system> individual, team, organization, or classes thereof, having an interest in a system)。与此非常相似,在《TOGAF Version 9》中The Open Group将干系人定义为:对架构的产出物具有利益关系或关注点的个人、团队或组织(或其种类)。担当不同角色的不同的干系人通常具有不同的关注点(An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, the outcome of the architecture. Different stakeholders with different roles will have different concerns)。
- 什么是企业架构:由于企业架构并没有一个统一的定义,且每个企业和组织在建立各自的企业架构的过程中均会按照各自的理解去对企业架构进行定义,因而目前在业界存在多种对于企业架构的正式定义:(下面内容源自《什么是EA(企业架构)?》 ,其中EA指代企业架构,EAF指代企业架构框架)
Zachman:EA是构成组织的所有关键元素和关系的综合描述。企业架构框架(EAF)是一个描述EA方法的蓝图。
Clinger-Cohen法案:EA是一个集成的框架用于演进或维护存在的信息技术和引入新的信息技术来实现组织的战略目标和信息资源管理目标。
OPEN GROUP:EA是关于理解所有构成企业的不同企业元素,以及这些元素怎样相互关联。
OMB(Office of Management and Budget,美国的管理和预算办公室):EA是业务和管理流程和信息技术之间当前和将来关系的显式描述和记录。
MetaGroup:EA是一个系统过程,它表达了企业的关键业务、信息、应用和技术战略以及它们对业务功能和流程的影响。关于信息技术怎样以及应该如何在企业内实施,EA提供一个一致、整体的视角,以使它与业务和市场战略一致。
Microsoft:EA是对一个公司的核心业务流程和IT能力的组织逻辑,通过一组原理、政策和技术选择来获得,以实现公司运营模型的业务标准化和集成需求。
IBM:EA是记录企业内所有信息系统、它们的相互关系以及它们如何完成企业使命的蓝图。综上所述,一个企业架构具有三个方面的含义:
- EA是一个描述工具:EA为组织中的所有干系人提供了一种描述手段(模板),使其可以对组织中的业务、信息系统及其之间关系按照各自的视角进行描述。而且由于使用统一的语言进行描述,所有干系人之间也有了无障碍沟通的基础,而这也正是EA最重要的用处。
- EA是一个知识库:EA为组织中所有参与者所提供的针对企业架构各方面的描述提供了一个分类管理、便于访问的知识库和信息资源库。
- EA是一个系统过程:为了使组织内信息技术与业务的需求、变化相适应,EA提供了一套实施准则和管理策略。
- 什么是企业架构框架:《TOGAF Version 9》中将框架(Framework)定义成一种内容或流程结构,用于对思维进行结构化组织,并在此过程中确保其一致性与完整性(A structure for content or process that can be used as a tool to structure thinking, ensuring consistency and completeness)。它描述了如何用一系列信息技术模块化地设计一个信息系统,并揭示了这些模块是如何结合在一起的。以此类推,对于企业这一现实存在的客观对象来说,企业架构就是以这一客观对象的实现和正确运行为目标的形式化描述,而企业架构框架则是用来构建企业架构的工具集和方法论。从某种意义上说,企业架构框架是企业架构的元模型,通过它可以帮助企业全面的且有条理地定义自己的企业架构。目前在业界存在多种企业架构框架理论,例如TOGAF,FEAF,DODAF,Zachman等。他们的虽然都是用来指导企业架构的创建的理论,但是他们各自的侧重点又不尽相同。无论什么样的企业架构框架理论,其内容大体分为如下两个方面:
1. 创建企业架构的过程和方法。
2. 企业架构的内容定义。
在上述的业界中存在的各种企业架构框架理论中,他们之间最大的不同应该就是针对上述两点的不同侧重程度上。例如在Zachman体系中,并没有侧重于针对企业架构的创建过程和方法的论述,而主要着眼于企业架构内容的定义(实际上在Zachman的论文中还没有提及企业架构这个字眼,他当时是从企业信息系统的构建这个角度来阐述,但后来业界人士均将这篇论文奉为企业架构框架的开山之作)。TOGAF 9之前各个版本的论述重点则放在企业架构的创建过程和方法论之上,并没有加入关于企业架构内容方面的论述,直到2009年TOGAF 9问世,才在其中加入了比较完备的用于描述企业架构内容的内容框架(Content Framework)。 - 什么是架构制品:《Comparison of the Top Four Enterprise Architecture Methodologies》将架构制品(Architectural artifact)定义为有助于架构描述的特定文档、报告、分析结果、模型或者其他的形式的事物(A specific document, report, analysis, model, or other tangible that contributes to an architectural description)。不同的架构框架对于架构制品有着不同的定义,例如在TOGAF的内容框架中,架构制品的形式就被定为目录、矩阵和图形三种方式。但不论如何,架构制品都是用来描述架构的,是架构描述的具体体现形式,因而在有的企业架构框里理论里,比如TOGAF,将视角(Viewpoint)与架构制品的具体定义联系起来,并把一份具体的架构制品内容当作架构的一个视图(View)。
企业架构研究总结(1)——参考资料列表
2013-04-23 18:05 by 闹市闲云, 44 阅读, 0 评论, 收藏, 编辑在2010年公司有幸参与到了某公司的企业架构建设项目之中,但对于一直从事于企业信息化建设的我们来说,由于一贯以来的努力都集中于企业的数据建模、管理和访问这些方面,像企业架构这样一门牵涉颇广的学问对我们来说还比较陌生,因而一条漫长的学习曲线是无法避免了。笔者有幸参与到这一项目之中,在漫长的学习过程中,笔者感触最深的就是资料的繁杂和中文资料的缺乏,虽然公司同事参加了某知名机构的企业架构培训,但其所带回的资料和标准原文相比差距甚远,因而从那时起笔者就一直想着有朝一日将自己的研究所得进行忠于原标准的总结,希望能对感兴趣的人产生帮助。
基于企业架构的复杂性,这篇总结必定篇幅不短,笔者将抽空持续添加,现在先将涉及到的参考资料罗列如下:
- 《企业信息化总体架构》赵捷,2011
- 《从FEA看中国电子政务的顶层设计》姚乐
- 《美国政府在社会信息化中的主导作用》,袁传宽、侯炳辉
- 《什么是EA(企业架构)?》,CIO时代网
- 《TOGAF Version 9》The Open Group, 2009
- 《Enterprise Architecture at Work》2nd,Marc Lankhorst et al.,2009
- 《Building an enterprise architecture practice: tools, tips, best practices, ready-to-use insights》,Martin van den Berg, Marlies van Steenbergen,2007
- 《Comparison of the Top Four Enterprise Architecture Methodologies》,Roger Sessions,2007
- 《Results of FY 2007 Federal Enterprise Architecture Assessment》
- 《Overview of the Federal Enterprise Architecture》,Blueprint Technologies Inc.,2004
- 《A practical guide to Federal Enterprise Architecture》,CIO Council,2001
- 《Federal Enterprise Architecture Framework》,CIO Council,1999
- 《Federal Enterprise Architectureand E-Government: Issues forInformation Technology Management》,Jeffrey W. Seifert,2008
- 《FEA Practice Guidance》,OMB,2007
- 《FEA Consolidated Reference Model Document Version 2.2》,OMB,2007
- 《The Data Reference Model Version 2.0》,OMB,2005
- 《Federal Transition Framework Usage Guide》,OMB,2006
- 《Enterprise Architecture Assessment Framework v3.0》,OMB,2008
- 《ArchiMate 1.0 Specification》,The Open Group,2009
- 《ArchiMate 2.0 Specification》,The Open Group,2012
- 《A framework for information systems architecture》,J.A.Zachman,1987
- 《The Zachman Framework For Enterprise Architecture》,J.A.Zachman,2003
- 《ISO/IEC 42010: 2007》,ISO,2007
- 《ISO/IEC 42010: 2011》,ISO,2011
以上各项为笔者阅读过的主要资料,而这篇总结将以对这些资料的翻译、集成和总结为手段,以回本溯源为主旨,希望至少能够为感兴趣的人们提供一个集中参考,免去学习时四处收集材料之苦。