Anders小明的Blog

Domain Model：Business Request的虚实之道与Business Action的设计模式          Author：Anders小明同步自：http://www.blogjava.net/AndersLin/archive/2006/09/19/70643.html      在《Domain Object：基于业务行为的分析》一文中，我提出在high level的角度

<<Domain Driven Design>> 和<< Patterns of Enterprise Application Architecture >>，令Domain 这个词很火，也引起了广泛争论。我这里也乱谈一把。什么是领域模型(Domain Model )   我以为Domain分两个含义：Domain Object和Domain Ser...

分析阶段的Use Case（User Story）除了Business Flow描述外，另一个重要的部分就是业务规则。组织和实现这些业务规则有不同的手段（将带来不同效益）。除传统的开发人员的代码实现外，越来越多系统开始使用规则系统来组织。  对于应用规则引擎网络上著名的有两篇文章：《Java规则引擎与其API应用详解》和《企业平台中的业务规则引擎》 此外，JBoss也基于Drools推出了JBPM...

   我在《小议领域模型Domain Model》讨论了service和object，以及关联逻辑(咳咳，该文中的一些观点我已修正，合适的时候放上来)。关联逻辑就是本文讨论的重点--specification   一、从DDD(Domain Driven Design)说起    这个Specification来自DDD，DDD有对specification分为三个类型    1. Validat...

Domain Object ：基于业务行为的分析 ——Domain Object 的动静之分，及其与 Business Process 的关系 Author：Anders小明     一、Domain Object的动静之分 1.1 动静的标准是什么？ 在系统运行期间，被频繁建立和更新的称为“ 动态” ，而在较长的一段时间内保持稳定的称为 “ 静态” 。   1.2 考查Domain Object...

Business Request的虚实之道 Business Request的概念，与http request是不同的。为避免误解，特意加上Business一词修饰。 所谓虚实是指是否将Business Request概念实例化。不做实例化的理由时处理简单；实例化则有助于处理Business Transaction以及账目模式。 一个业务上的Business R...

本文放在javaeye可能未必合适。文章中中英文混用也是问题。而且本文讨论的模型比较适合交易类系统，对于ERP类未必合适。Author : Anders小明原文: http://www.blogjava.net/AndersLin/archive/2006/10/09/74187.html 在Domain Object的动静之分中，其实我已经把业务对象分为三大类，不过...

Author: Anders小明[b]为何要Domain Model[/b]传统的开发方式：基于数据库的设计开发。数据库提供的设计模型是表和字段两种粒度，这两种粒度有时并不合适于系统设计：1. 模型的结构化能力1.1. 同一模块组件下的设计优势；一个model可以来自多张表的数据聚合而成，一张表可以聚合多个Model；一个逻辑是由几个固定字段或者非固定字段聚合；Model间的关...

Author: Anders小明（2008-1-12更新）从以上的分析中，我们可以了解到Domain Model分为三种类型：0. 全局常量对象1. 长生命周期业务对象（类似保单对象）；2. 交易过程的Transaction对象，几乎没有生命周期的；3. Request/Response对象。这类对象以前没有识别的，通常和VO混在一起；但是在IAA中以及电信业的模型...

Author :  Anders小明   续《Domain Model:业务对象的进一步设计》       Product Line    Product Line体系存在比较特殊，Product Line的概念并不明显。Product Line以Product为核心，维护了一类product所共有的属性与其它关联业务对象如Document，同时维护了不宜在product一级维护的信息：produ...

作者：anders小明2009年5月7日  需求背景现在的样子如PoEAA中提到的：事务脚本(Transaction Script)和表模型（Table Moduel）模式。存在问题事务脚本看到的是零散的数据，而表模型混合了下文要说领域模型和领域服务界限。1.     两者都导致了分析和设计的割裂，领域模型只存在于分析中；数据间的内在关系无法通过代码体现；2.   

Author :  Anders小明同步自: http://www.blogjava.net/AndersLin/archive/2006/10/09/74187.html        在Domain Object的动静之分中，其实我已经把业务对象分为三大类，不过在那一部分中没有明确的提出。这三大类是Party，Product和Contract。         Party         包括

   Author :  Anders小明   续《Domain Model:业务对象的进一步设计》       Product Line    Product Line体系存在比较特殊，Product Line的概念并不明显。Product Line以Product为核心，维护了一类product所共有的属性与其它关联业务对象如Document，同时维护了不宜在product一级维护的信息：pr

(同步自http://www.blogjava.net/AndersLin/archive/2006/06/15/53086.html)  > 和>，令Domain 这个词很火，也引起了广泛争论。我这里也乱谈一把。什么是领域模型(Domain Model)   我以为Domain分两个含义：Domain Object和Domain Service。那么什么样的系统是面向Domain的系

同步自：http://www.blogjava.net/AndersLin/archive/2006/06/30/55926.html 2007.12.20更新部分内容       分析阶段的Use Case（User Story）除了Business Flow描述外，另一个重要的部分就是业务规则。组织和实现这些业务规则有不同的手段（将带来不同效益）。除传统的开发人员的代码实现外，越来越多系统

同步自：http://www.blogjava.net/AndersLin/archive/2006/08/14/63551.html我在《小议领域模型Domain Model》讨论了service和object，以及关联逻辑(咳咳，该文中的一些观点我已修正，合适的时候放上来)。关联逻辑就是本文讨论的重点--specification   一、从DDD(Domain Driven Design)说

Domain Object ：基于业务行为的分析 ——Domain Object 的动静之分，及其与 Business Process 的关系 Author：Anders小明     一、Domain Object的动静之分 1.1 动静的标准是什么？ 在系统运行期间，被频繁建立和更新的称为 “ 动态” ，而在较长的一段时间内保持稳定的称为 “ 静态” 。   1.2 考查Domain Objec

Author: Anders小明为何要Domain Model传统的开发方式：基于数据库的设计开发。数据库提供的设计模型是表和字段两种粒度，这两种粒度有时并不合适于系统设计：1. 模型的结构化能力1.1. 同一模块组件下的设计优势；一个model可以来自多张表的数据聚合而成，一张表可以聚合多个Model；一个逻辑是由几个固定字段或者非固定字段聚合；Model间的关联关系也是使用表无法展示的（外键的

Author: Anders小明（2008-1-12更新）从以上的分析中，我们可以了解到Domain Model分为三种类型：0. 全局常量对象1. 长生命周期业务对象（类似保单对象）；2. 交易过程的Transaction对象，几乎没有生命周期的；3. Request/Response对象。这类对象以前没有识别的，通常和VO混在一起；但是在IAA中以及电信业的模型是这类对象是独立存在

作者：anders小明2009年5月7日  需求背景现在的样子如PoEAA中提到的：事务脚本(Transaction Script)和表模型（Table Moduel）模式。存在问题事务脚本看到的是零散的数据，而表模型混合了下文要说领域模型和领域服务界限。1.     两者都导致了分析和设计的割裂，领域模型只存在于分析中；数据间的内在关系无法通过代码体现；2.   ...