1、业务活动与规则对于一个领域来说与其涉及的实体同样重要。   2、领域也会包含各种类别的概念。对知识的消化要能够产生出反映这种理解的模型。   3、超越实体与值之上的变化可能会对知识消化产生剧烈的影响,因为业务规则之间可能存在不一致。   4、领域专家通过与软件专家的密切合作,进行知识消化,才使得规则明晰化。   5、提炼隐藏概念,将业务规则可以放到一个领域对象中。   6、任何业务专家都不可能阅读代码来检对规则。   7、一个非业务人员的技术人员,要将需求文档与代码联系起来是很困难的。   8 ...
1、高效的建模人员就是知识的消化器。   2、知识消化并不是一个孤立的行动,它由开发团队与领域专家共同合作,由开发人员领导。   3、老式的瀑布方法中,业务专家与分析人员会谈,分析人员提取摘要,进行抽象后将结果转达给程序员,由程序员进行编码。这种方法并不成功,因为没有反馈机制。   4、优秀的程序员会自然地开始进行抽象来开发一个模型。   5、在团队成员一起讨论模型的过程中,他们之间的交互也会发生变化。模型的不断精化使得开发人员不断学习他们所需要的重要业务原理。领域专家通过提炼他们认为必须的知识来精化他们的理解。   6、程 ...
1. 模型与实现相互绑定。未经加工的原型建立了早期必需的联系,在随后的迭代中始终对它进行维护和完善。   2. 基于模型生成了一种语言。随着项目的进行,我们中的每个人都可以自如地使用来自模型的术语,将它们组织成与模型结构一致的句子,不需翻译,也不会引起歧义。   3. 开发了一个包含丰富知识的模型。对象都具有行为和一些强制性的规则。模型并不仅仅是一个数据方案,它是解决一个复杂问题必不可缺的。它捕获了各种类型的知识。   4. 提炼模型。在模型变得更加完善的过程中,一些重要的概念被加入其中。同样重要的是,如果概念被证明没有用处或并不重要,则应该丢弃。如果 ...
作者:老王 Eric Evans所著的《领域驱动设计》(Domain-Driven Design:通常简称为“DDD”)一书可以说是经典中的经典,虽然“领域”的概念早就存在,但是直到这本书的出现,才让人们真正开始认真审视软件的构 建,相信你看了这本书后会真正体会领域的力量,也正是这个力量决定了软件最终的价值。 领域的含义: 简单的说,每个软件程序都会与其用户的活动或兴趣相关,其中使用程序的主要环境称为软件的“领域”。 领域中形形色色的业务逻辑构成了软件丰富多采的行为。举例来说,银行财务系统中,领域逻辑就 ...
  越来越多人开始使用Java,但是他们大多数人没有做好足够的思想准备(没有接受OO思想体系相关培训 ),以致不能很好驾驭Java项目,甚至 导致开发后的Java系统性能缓慢甚至经常当机。很多人觉得这是Java复杂导致,其实根本原因在于:我们原先掌握的关于软件知识(OO方面)不是太贫乏就是不恰当,存在认识上和方法上的误区。 软件的生命性   软件是有生命的,这可能是老调重弹了,但是因为它事关分层架构的原由,反复强调都不过分。   一个有生命的软件首先必须有一个灵活可扩展的基础架构,其次才是完整的功能。    目前很多人对软件的焦点还是落 ...
  当Java世界提供的可选择性框架平台越来越多时,我们可能被平台架构所深深困扰,而无暇顾及软件的真正核心:业务建模,其实,业务领域建模同样是一个比平台架构更复杂,更需要学习的新的领域。    相反,在实践中,我们技术人员在经过冗长的平台架构学习和实践后,就匆忙开始项目开发,这时是什么指导他们进行软件业务实现呢?大部分可能是依赖数据库 建模,甚至是复杂冗长的数据库存储过程设计,这些已经开始走向面向对象分析设计的反方向,走上了一条错误的软件开发方向,最终开发出缓慢的、经常当机的 Java企业系统。   如果你没有恰当的OO设计思想,Java就会用性能惩罚你,这可能是Java世界的一个潜 ...
  板桥里人 http://www.jdon.com 2006/12/6(转载请保留)   多变且复杂的需求   如果没有多变的需求,也许就没有今天的面向对象软件,我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击,可是这样下去的结果只有一个:使得软件更加僵化;或者程序员更加 劳累。   需求不但多变,而且经常是不可能第一次就能掌握,需求反映了某个领域的专业知识,例如数学、管理、财务或 电子商 ...
    我们知道:一个软件从无到有需要经过如下几个阶段:分析、设计、编程、调试、部署和运行。    编程阶段我们通常使用Java/.NET这样面向对象语言工具,可以带来很多设计上的好处,但是也存在一个奇怪的现象: 很多程序员虽然在使用OO语言,但是却在code非OO的代码,最终导致系统性能降低或失败,这个现象在Java语言尤其 显得突出,难怪有些人就把问题归结于Java语言本身 ...
面向对象与领域建模 板桥里人 http://www.jdon.com 2006/12/6(转载请保留) 多变且复杂的需求   如果没有多变的需求,也许就没有今天的面向对象软件,我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击,可是这样下去的结果只有一个:使得软件更加僵化;或者程序员更加 劳累。   需求不但多变,而且经常是不可能第一次就能掌握,需求反映了某个领域的专业知识,例如数学、管理、财务或 ...
1、设计模式是设计上的重用,框架是更大粒度上的重用。   2、原型:人类组织、总结、概括客观世界的基本概念。   3、业务原型是对业务领域中的原型。是对不同业务需求中的共同之处的抽象和概括。   4、一个业务原型应该是一个在业务领域或商业软件系统持续发生并且普遍存在的最初级的事物。   5、原型之间是相互交互的,Party, Product, 和 Order是每个虚拟商业系统的基本概念,在这个商业系统中,你可以卖产品或服务。我们将这些原型之间的协作看成是业务原型模式(business archetype patterns)。   ...
1、了解面向对象语言是必要的,但不是首要的,了解“面向对象思想”才是关键。   2、UML只是标准的图形表示法。常用的表示法是有用的,但更重要的是面向对象的内容值得学习,尤其是如何利用对象进行思考。   3、UML只是图形表示法,不是OOA/D,也不是方法。如果没有掌握如何创建优秀的面向对象设计,或者如何评估和改进现有设计,那么学习UML或者UML工具是毫无意义的。   4、对象思想才是重点和难点。   5、为对象分配职责、对象间如何协作、什么对象做什么事情,是系统设计的关键问题。   6、OO经典设 ...
领域模型是对领域内概念类或现实世界中对象的可视化表示。 概念类:思想、事务或对象。 概念类包括三个方面:符号、内涵、外延。 为什么要建立领域模型? 原因:降低与OO建模之间表示的差异。领域层软件类的名称要来源于领域模型中的名称,使对象有源于领域的信息和职责。 如何创建领域模型: 1、创建概念类。 2、将其描述为UML中的类 3、添加关联和属性
jokermanager
搜索本博客
最近加入圈子
存档
最新评论