http://www.cnblogs.com/ruirui413/p/4609033.html
模式: UBIQUITOUS LANGUAGE(通用语言)
第一章 消化知识
有效建模的要素
1. 模型和实现的绑定
模型要基于现实的业务,不能和用户现实的业务脱节
2. 获得一种基于模型的语言
通过一种统一的语言(业务人员和开发人员都能理解的)去描述所建立的模型,如UML图,基于业务的术语,无奇异的,作者的意思是业务人员和开发人员建立基于模型一个沟通的桥梁。
3.开发一个蕴含丰富知识的模型
灵活的,适应变化的的模型,模型不能简单等同于类图,而是解决复杂业务问题的方案。包含各种类型的知识
4. 提炼模型
对业务的描述要抽象,从场景的分析,需求的分析中提炼出。随这业务的发展,模型是变化,模型也是需要迭代的,对于过时的概念要删除。去其糟粕,取其精华。
模型是基于实际的业务去创建,分析需求时,要深层次的挖掘需求,知道需求的本质是什么,只有这样才能更好的去建立模型。
模型的建立是业务和开发沟通的桥梁,通过模型的建立,开发人员了解需求,双方共同去阐明问题是什么,发现那些业务是变化的,那些是不变的,让系统更好的去实现业务,适应变化。
http://www.cnblogs.com/ruirui413/p/4609169.html模式: UBIQUITOUS LANGUAGE(通用语言)
开发在于领域专家沟通时,需要建立一个通用语言,来减少沟通的成本
基于业务,开发和业务达成共识,用双方都能理解的黑话来讨论序曲
强调了专业术语的差异,带来沟通和理解的成本,为了降低成本,必须使用一种共同的术语来建模。
这个术语更偏重于业务,而不是开发,但开发对于术语所代表的意义和业务要达成共识。
领域语言在描述业务场景或者是构建领域模型时,如果有歧义,则需要领域专家向开发人员澄清,清除歧义,同时也会更新模型。
通用语言的包括口头的交流语言,图表,文档。
书面文档,不是必须的,但它可以作为口头交流的补充,文档是基于领域模型的,不是对代码的复述。
书面文档如果不再被及时的更新,那么它就失去存在的意义,请把它归档。
所以书面文档请保持尽量的简洁
文字和图是相辅相成的,不要刻意的去偏重某一种描述。
代码是最实时有效的对模型的描述,但它太偏重与细节,不是能被领域专家所能完全理解的,即便领域专家能理解,但会让人深陷细节中。
所以需要文档作为补充。
图不完全是UML图,可以用简单的图示去描述业务流程,更适用与沟通。
本章更多是在强调用一种双方都便于理解的语言、文字和图去对系统进行描述,便于大家对系统的分析和设计。
http://blog.csdn.net/flyweilai1287/article/details/28120969