未分类文章
domain model的延伸讨论
domain model，又称为领域模型，是Java企业应用讨论的一个热门话题，JavaEye也曾经多次围绕这个话题讨论，我们来看个简单的例子： 引用 一个简单的公司工时管理系统，记录员工的个人信息，每个员工的工作任务分配，以及工作所属类别(例如开发，还是测试，还是培训等等)，其中每个员工有n个任务，员工和任务是一对多关系，每个员工也分别隶属于多个不同的工作类别，员工和类型是多对多关联关系，而每个 ...
Domain Model：业务对象的进一步设计
本文放在javaeye可能未必合适。文章中中英文混用也是问题。 而且本文讨论的模型比较适合交易类系统，对于ERP类未必合适。 Author : Anders小明 原文: http://www.blogjava.net/AndersLin/archive/2006/10/09/74187.html 在Domain Object的动静之分中，其实我已经把业务对象分为三大类，不过在那一部分中没有明确 ...
Domain Object ：基于业务行为的分析
Domain Object ：基于业务行为的分析 ——Domain Object 的动静之分，及其与 Business Process 的关系 一、Domain Object的动静之分 1.1 动静的标准是什么？ 在系统运行期间，被频繁建立和更新的称为 “ 动态” ，而在较长的一段时间内称为 “ 静态” 。 1.2 考查Domain Object的动静将意义何在？ 通常而言，“ 动态” 的Do ...
DomainModel之鸟瞰
第一次接触GoogleEarth，带给我相当的震撼。你可以随意转动地球，通过缩放，看到不同层次的景象，这着实让我吃惊，竟然可以这样！手握鼠标，来回查看，有种作“上帝”的感觉，如果是实时的那就不得了了！相信很多人都有在上面寻找自己家的经历。就拿我来说，首先转到背面中国的位置，滑动滚轮，逐渐深圳的全貌显露出来，西面是蛇口黄色的填海区，上面是深圳的绿肺塘朗山。继续向下，黑灰色的广深高速开始清晰可见，在我辨 ...
DomainModel之演化(已更新)
OO世界里的DomainModel，相对其他人工创造的领域来说有它的优势，大部分DomainObject在现实世界都能找到原型。通过分析现实世界的原型，我们能得到足够多的原始材料。 在构建企业信息系统时，我们希望构建出的系统，在高效正确运行的同时，构架容易理解，易于扩展。我认为要做到这点，必须要满足后面的条件--系统构架须同领域存在一致的演化映射。领域基本概念就是系统的基本对象，在领域基本概念上 ...
DomainModel之控制风格
I know what I know,I'll sing what I said,We come and we go ... --I Know What I Know,paul simon 相对于分歧较少的静态DomainModel结构，DomainModel的动态特征一直是扑朔迷离，让人捉摸不定。以至于出现了很多争论，分歧在哪里呢？如果我们把DomainModel整个动态特征看作一个集合，那 ...
高举Domain Specification，应用函数式编程
http://forum.iteye.com/viewtopic.php?t=21760 balaschen发帖说要提供sql的对象化拼装，buuawhl老大说思路不对，可是ajoo（我的偶像啊）也说要整整这个sql拼装（偶像啊，还是把高贵时间用在刀刃上吧）。 让我忍不住跳出来新开一帖讨论（观点不一定正确，还是尝试中）， 我是同意buuawhl的，不过可能出发点不一样。 buuawhl 写道 组 ...
DomainModel之DomainObject
相对于UI的开发受限于既有框架的结构，DomainModel有更大的灵活性，因为框架本身由自己开发的。 在整个DomainModel框架中，最基础的对象莫过于DomainObject。DomainObject既然是所有领域 对象的父类，就该体现最基础的特征。并且为其他层或某些方面提供一致的入口。 “有名万物之母”，这也是DomainObject中需要体现的。 DomainObject的名有很多， ...
DomainModel之相互作用
1.如两DomainObject有关联，则必存在生命周期短者到生命周期长者的关联。 2.如两DomainObject有关联，并且存在生命周期长者到生命周期短者的关联，则它们两者的概念互为依赖。
Domain Pollution Resolution 域污染解除
Domain Pollution Resolution 域污染解除 0. Domain 名词解释 首先说明一下 Domain 在本文中的意思。 <<Domain Driven Design>> 一书，令 Domain 这个词很火。引起了广泛争论：哪些Logic 应该放在 Business Service Layer, 哪些应该放在 Domain Object里面。这类争论纷 ...
Domain injection with AOP
几个月前在JavaEye上讨论得如火如荼的domain object问题似乎已经硝烟散尽。在那个经典的贴子 里，robbin为domain object总结了三种模型，其中的模型二好象完美地解决了domain object的所有疑问。但现实的情况却并不象理想中的那么简单，在贴子的末尾七彩狼、frankensteinlin等都提出了相关的疑问。虽然我们的domain object里只包含业务逻辑，我们 ...
基于domain object进行OOAD设计
我一直觉得基于domain的OOAD的设计思想有一个重大的缺陷，导致我们的设计灵活性很差。 OOAD有一个基本的前提：所以的类以及类之间的关系在设计完成后就已经确定了，不可以更改。我觉得正是这种“静态性”导致灵活性很差。 比如：在domain层有一个Employee类，在设计的时候我们必须确定好：Employee有name和address等属性，如果程序发布后用户需要增加一个属性，就不得不重新编 ...
domain model 的疑问
首先:我同意业务层采用domain model 优点这里不作叙述 其次:我不会采用把业务层和DAO合并(尽管那样做也有好处) 第三:我同意区分领域逻辑和业务逻辑和他们的区分规则(即持久操作不作为领域逻辑不存在于领域对象中而是作为业务逻辑存在于SERVICE中) 我的问题在于:一个逻辑的区分上.因为一个项目不会是一个人或几个人进行开发,所以开发人员的水平也是不同的,对于逻辑的区分归类上也会有不同,因 ...
总结一下最近关于domain object以及相关的讨论
在最近的围绕domain object的讨论中浮现出来了三种模型，(还有一些其他的旁枝，不一一分析了)，经过一番讨论，各种问题逐渐清晰起来，在这里我试图做一个总结，便于大家了解和掌握。 第一种模型：只有getter/setter方法的纯数据类，所有的业务逻辑完全由business object来完成(又称TransactionScript)，这种模型下的domain object被Martin F ...
谈一谈贫血的Domain Logic问题。
如今采用Hibernate实现的Domain Model，多数只是维护实体之间的关联，而大多数的业务逻辑，则是由Service Layer来实现。 这样的模型对象拥有的行为太少了，以至于Martin Fowler给他们下了一个定义：贫血模型。 我们知道，高内聚低耦合是衡量一个模型设计是否合理的重要标准之一。对象组件间合理分工协作可以解决复杂的问题逻辑，按照这个标准，我们似乎可以很自然的各种行为封 ...
群组知识库热门文章
- 4909 domain model的延伸讨论
- 2353 DomainModel之DomainObject
- 2297 Domain Object ：基于业务行为的分析
- 2246 Domain Model 探索
- 2212 谈一谈贫血的Domain Logic问题。