• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

以前写过一篇《基于抽象的分层结构》，这里补充一篇《基于业务模块组件的系统架构》
一些内容在《项目笔记：dao，web，模块边界以及Model分类》以及《模块的接口设计》随笔中已经提到，这里补充总结一下。

任何一个有一定规模系统，通常会把系统做一定分解降低分析设计开发的难度，模块划分是一个比较常见的方式。
而在模块的划分及其分析设计的实践中，包括了两种层次的边界。第一是交互行为层次，第二是对象层次。

首先说交互行为。
模块和模块的交互接口最为重要，通常我们认为这些接口应该通用稳定，然而如何设计每个模块对外提供的接口却是一个不易的问题。

集成的两种基本实现方式：
1. API方式。
这是常见的实践方式。即每个模块公开数量不多的接口类（但拥有较多的接口方法）以及接口参数（都是普通的VO），每个接口的设计和实现都有该模块成员维护；实践中：这些接口都独立打包，形成多（模块）对一（接口）的依赖关系，方便编译。
这样的好处是：接口边界清晰，开发编译依赖比较简单。
然而实践中极有可能出现两种状况：接口维护失控或者过严而死板（而影响开发）。接口失控是因为接口的维护太过随意，因为A模块的需要就轻易在B模块中添加一个接口（方法），导致该接口（方法）非独立性（基本上只给模块A的这个功能点使用），或者是接口的控制过严，导致或者工作效率不高，或者接口的易用性不好。
原因在于：接口是两个模块间的耦合，而发生的种种问题在于模块耦合太过紧密；同时实践中，把模块对外提供的接口，与模块需要实现的外部模块的集成混为一谈；换句话说，A模块需要集成的语义，和B模块提供接口的语义存在差距。
这样的实践优点：开发管理控制成本较低，模块编译依赖简单，模块物理边界明确。

2. Adapter方式
这种的实践可以一定程度上解决API方式面临的问题：根据指导原则——为了降低耦合只有在中间加一层；即不轻易为模块设计对外提供的接口（方法），除非是通过重构得来的；模块对外提供两种类：一个是需要外部模块实现的接口（接口设计从本模块需要出发，当然每个接口尽管是为某个功能点服务，但也要注意其在模块内通用性）；另一个是其它模块要求本模块实现的接口的实现类（这块物理上独立打包，独立于模块之外）。
即：A模块拥有一些需要B模块实现的接口（A模块对B模块的要求），而B模块中也有要求A模块实现的接口，因而A有这些接口的实现类。
处于编译依赖的考虑，已有的实践是把处理接口适配的代码维护在模块外的，就是所谓的集成模块，这样编译上就形成了1（接口实现）对n（模块）的依赖关系。模块的边界在这里模糊了，当然在这之外模块的边界是很清晰的。
这种实践方式的好处在于：模块的接口就多了一层隔离降低了耦合，把接口的通用性和接口的适应性分离，又明确了模块的边界，使得接口在日后的优化和调整有了缓冲。
这样的实践和API实践的不同之处在于：接口的设计权利一分为二，需求方拥有了其应该有的权利，并且这个权利与提供方没有冲突（旧的模式不行，一旦供应方改变了接口，就立刻导致编译问题）。

两种方式的对比：
1. 采用API方式集成，代价在于维护API本身，API面对众多的客户端，其面临的设计维护成本较高，同时实施成本高；
2. 采用Adapter方式集成，由于没有维护API，缺乏可复用接口，但可以做到为每个客户端自由定制，其设计维护成本较低，实施上成本较高；

 集成的演进方式：
1. 采用事件模式。
这也是完成交互处理的模式。通常事件模式在业务行为上也可以完成和接口相互的功能，不过由于其在接口签名上无法明确提供其业务含义，建议谨慎应用。对于产品化项目，项目开始可以应用事件处理机制，在成熟时提取为更具体的接口。
 事件模式中，Event的监听类也面临着模块的边界问题。已知的成熟开源项目都在事件源中暴露的模块内部对象，方便开发者使用。
 可以说这种方式的是Adapter方式的演进；
 
2. 采用框架回调方式
工作流和页面流也负责集成不同的模块.不过因为工作流和页面流框架都维护独立的数据对象共享池,因而在这个层面上,模块间直接的交互并不存在。这种集成上的优势，演化成通过ESB等集成框架完成.
 这种方式是API方式的演进，但是把调用点以及调用方独立出来，成为框架的一部分。

现在说说对象一级的边界集成。
在保险中，benefit对象会关联一个product对象，不过product对象是是属于产品模块而非保单模块，对于保单模块只关心id而并不使用对象，但在RMS或者FMS或者UIC这样的集成环境却是需要product对象的。我们要采用代码生成的方式，在benefit对象上加一个annotation，比如Integration的annotation标识，使用AspectJ在编译上enhancement生成的class，使得benefit对象在集成环境上可以拿到product对象，这算是一个集成方面。

组件化管理
组件化管理包含两个含义：
1. 组件访问控制，依赖管理以及服务注册；
现有的访问控制的办法，只能通过代码提交时或者编译发布时检查，但我们更期望支持运行时的能力，避免外部组件访问组件未申明公开的内部结构和程序；同时维护方式应该简单方便，成本低。
目前的组件依赖管理几乎没有，尤其是基于版本的依赖；而在实践中，依赖维护管理尤其是多版本的通常花费大量的成本。
2. 组件依赖的绑定以及失效（故障）的隔离；
我们希望能够为每个组件提供一个保护区域，当其依赖的一个组件因为种种原因（软件错误的或者软件升级）失效时，系统至少应该提供一种fail-fast机制，包括如下能力：
A．故障即停（Halt on failure）——当一个组件出错时，应当立即停止下来，而不是继续执行可能不正确的操作；
B．故障曝光性质（Failure status property）——当一个组件发生故障时，系统中的其他组件应该得到通知，故障的原因必须交代清楚；
同时，我们希望该组件，如果可能它应该可以继续运行。完成这样的目标需要很多的工作，但首先依赖于系统fail-fast能力，同时在故障消除服务恢复后，系统能够提供相应的通知，并控制恢复的顺序。

已知的支撑框架：SCA和OSGi
1. SCA考虑的是异构异步环境，OSGi考虑同构同步环境；
2. OSGi规定了容器如何管理组件，组件依赖（版本）管理，组件边界保护以及组件服务依赖运行时绑定策略和权限控制；SCA对此没有涉及；
3. SCA考虑的如何暴露服务，设计时客户端如何使用服务；OSGi考虑的更加完善；

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

一、什么是架构

1. 和架构相关的几个问题域

架构需要解决的非业务问题域包括如下：

A 系统目标：系统性能，稳定性.

B.项目目标：开发成本，质量

C.项目过程：需求的不确定性和开发过程的团队协作性

不同的问题域，解决之道也不相同！而同一问题域的不同层次的要求，解决之道也不尽相同。

2. 什么是架构

   架构到底是啥，愚以为下面的这段英文描述的很清楚。

That's like asking, what is culture? Culture is the way you do things in a group of people. Architecture is the way you do things in a software product. You could argue by analogy, then, that architecture is to a software product as culture is to a team. It is how that team has established and chosen its conventions，

Which leads us inevitably to the question of “goodness”? How do you know if an architecture is good? Consider an architecture that isn't built using a strong domain model, and instead relies heavily on stored procedures. That might be OK, or it might not be OK. You could have decided that part of your architecture is to use a really strong domain model and not use stored procedures, right? So an architecture is some reasonable regularity about the structure of the system, the way the team goes about building its software, and how the software responds and adapts to its own environment. How well the architecture responds and adapts, and how well it goes through that construction process, is a measure of whether that architecture is any good.

The system architecture determines how hard or easy it is to implement a given feature. Good architectures are those in which it is considered easy to create the features desired. In that the way to judge whether an architecture is good is whether the architecture is good for the purposes to which it is applied.

The definition of goodness has to be related to fitness for purpose. Is this glove good? I don't know. What are you doing with the glove? Are you throwing snowballs, cooking barbeques, or playing golf? There's a set of changes that are going to occur to a software system over time. Probably the utilitarian or most useful definition of goodness is the answer to this question: are the changes that will keep this system successful in this domain in this product line relatively easy? If they are, then it's probably a good architecture.

3. 架构的背后

为了实现架构的目标涉及到以下三个方面：技术，组织和过程。这里举例说明。

1)       技术对开发效率和运行性能，以及组织和过程的影响。

案例A．映射的问题。公司产品的一个重要需求是根据客户输入，映射到PDF文件上。技术上整体实现需要四个步骤：在PDF文件上画好所有的数据域，通过读入一个XML映射文件，获得运行数据并生成FDF，合并FDF和PDF生成目标文件。后两步工作都由代码自动化了，因而实现的主要工作在于前两步。

在第一个实现版本里，XML映射文件的DTD太简单，致使一个xml文件至少在4000行左右，同时xml文件太verbose了。这样的结果直接导致运行系统在峰值时，由于XML消耗了大量内存，1G的内存根本吃不消；同时对XML解析执行使用了CPU的大量时间；导致开发人员需要做大量的工作，开发效率降低了，通常需要尽一周才能完成一个xml文件，员工都不愿意做；也导致开发过程的漫长， 开发部门对于BA部门和ST部门的要求反应变的缓慢。

在第二个版本的实现中，重新实现了DTD，加入了大量的关键字同时也消除了verbose，大量的缩小了XML大小，从4000多行减低到900多行。不仅减低了内存使用，提高执行效率；也提高了开发效率，基本只要一天就可以完成一个映射文件。同时对BA部门和ST部门的反应也快了。

案例B：脚本的问题。产品在web层提供了脚本支持，出于方便开发的目的。但是没有对脚本的环境限制，脚本可以做系统程序的大部分工作。导致开发人员偷懒，在web层混入了大量业务逻辑代码。最终造成业务逻辑分散而不可控制。

2)       组织结构对技术，开发效率和应变能力的影响。

案例A.部门的分工问题。开发部门根据不同的职责，分成A，B和C等数个小组。大部分开发中互不相干。但也有时候，需要跨组的支持，比如B要实现某个需求，需要A在一定条件在记录一个或多个信息。因为每个开发人员各自负责一部分工作，导致跨组沟通的困难。同时由于整个开发部采取任务绩效，有时间压力，加上只是一个小的要求。于是在A人员的同意下，B人员直接在A代码中写入业务逻辑。每次都是这样的小改动，不断的发展后，代码开发变凌乱。

案例B.开发的历史问题，当某个开发人员写下的代码，有是问题的，接手开发人员由于文档不全以及没有测试用例，不愿意承担变化的代价，选择小修小补，这个小修小补有可能和有问题的代码混杂，导致更大的代码。

3)       过程对开发效率和应变能力，以及组织的影响

案例A.过程的问题。开发部门的上下游部门BA部门和ST部门的合作关系。ST部门的绩效考核,考核基于发现错误的数量，导致ST为了完成任务，提出一些非正常性要求。PM部门出于部门的方便通常提出一些实现难度比较大要求。开发部门本身又存在时间压力，导致一些需求的实现本应在低一层的代码中实现的，却在高层用蹩足的方式实现。

案例B.帮助系统的问题。帮助系统一开始采用一个个单独分散的静态页面。出于性能的考虑和部门负责考虑。帮助系统不断改进中，过程缺乏组织性，文件的命名规则随意，存储位置随意，造成了管理的混乱。直接的后果是页面的入口混乱和各自引用关系混乱。

在帮助系统的第二版，从静态页面转成动态页面。采取统一分类和命名规则，并统一了入口。同时采取分级管理引用关系，适度冗余。虽然减低了运行性能。但提高了开发效率和可维护性。

Domain层VO对象，通常是用于不同领域组件间的交互，但随着架构的改进，集成代码独立存在而不再嵌入到组件内部，组件的边界问题保护不复存在；更进一步的是，框架提供自动化的接口适配映射能力的增强。因而VO对象也失去存在的意义。

5.2.设计方法：Domain Model Prototype和业务行为的分析模式。

架构面临的品质问题，则通过自动化测试，代码检测工具来完成。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

（2008-1-12更新） 

写在前面
SOA现在越发闹腾的厉害了，各种宣传越来越多，都把SOA吹上天；到底SOA是什么，有啥神奇之处，真的想宣传说的那么好吗？看了种种文章，只是越发混沌。
罢了，俺做技术的，商业上的宣传，俺不在意。既然SOA只是理念，那么俺就从它的支持技术来看看，从过去到现在的区别，看看SOA到底是啥！

从EAI到SOA
从集成的角度看，集成面临的问题如下
A. 数据集成，包括信息交换和交换管理
B. 业务集成，包括服务管理和流程管理

1.史前时代
现象：
1.1. 采用原始交换手段—— 点对点的传输通道依赖，机制是Socket或者后来的RMI。存在两个问题：1. 只能在同一平台上传输数据，无法处理异构系统数据传递，比如RMI没有办法和.NET通信；2.如果目标地址变化或者故障，就出问题。由于没有更多的交换管理能力，点对点的交换越多导致的管理成本就越高；
1.2. 数据格式绑定，依赖于双方的严格的私有格式。

1.3 扩展——EDI的出现解决了异构系统的数据传递格式标准。

2. EAI时代。
现象：
2.1. 基于中间件系统，采用了集中式管理的消息交换管理系统，就是所谓的信息总线技术——MQ技术，包括了两种不同的消息传递方式。
相对以前，统一了内部信息格式（这是基本工作），提供较好的数据交换管理。存在的问题：1. 只关注于消息的内部格式和传递，而忽略的各个系统的集成程序：没有提供对于这些集成程序的打包和管理；2.系统是紧耦合的，不同消息系统间的通信困难。

2.2 扩展——JCA. 相对于JMS，JCA关注于对于旧有系统数据访问，相当于访问数据库的JDBC；

2.3 发展：采用开放的自解释的XML作为系统通信格式，采用松耦合的Web Service作为通信手段。

3. SOA时代。
现象：
3.1. 天然的引入XML和Web Service技术。
3.2. 出现了ESB这样的技术平台。ESB是SOA的最佳基础平台。ESB与MQ一样也提供统一的消息格式，并管理消息传递；不同的是，ESB重新发现了集成程序的价值——在集成环境中，集成程序代表其背后的应用系统，这些程序提供了各个子系统的应用服务，它们才是集成环境中最有价值的部分，是集成环境中的First Class；并对这些程序提供统一的打包方式，并提供运行时管理。另一方面，ESB把集成程序进一步分解为服务（业务逻辑）以及Endpoint（服务的入口点），这样服务不仅仅是可重用，而且是可组装编排; 可快速注册发布; 质量可监控；生命周期可管理的，也正是因此，
3.3. 出现了所谓的BPEL等面向业务的能力开始显现，提供流程管理。

EAI和SOA的区别
EAI时代是企业的收发室，只知道信件本身，对于信件收发者的身份却不知道，更不知道信件所处的流程体系。
SOA时代是企业的办公室，不仅知道信件本身，对于信件收发者的身份都清楚，还可以知道信件所处的流程体系。就可以很容易的组合各个服务，建立起各种虚拟专员（specialist），响应业务的变化。

SOA的产商利益
SOA的基础框架提供了支撑平台，也就是可能性。但要实现SOA的理想，却还需要对业务重新梳理，发现和重用IT资产，正如ERP那样，这才是SOA实施的关键所在；而IBM这样的公司正拥有这样的咨询能力，所以IBM每年都投入大量的资金来推动SOA的应用，就在情理之中了。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

Author：Anders小明

先从后端的dao说起吧：
已有项目的开发以及appfuse的开发，都属于传统的开放方式，内部有dao，外部还有service。

这样的开发方式太学院了，每次改动其实影响面很大，要改二个类，两个接口。平时不忙的时候也就算了，项目一紧的话，大家就乱来的了。相当部分都是最外层接口实现类就直接访问了数据库，而不走规范路线。

现在对外提供一个repository的service接口（加载该领域模块的root对象，以便程序利用root对象来游走，ddd推荐的做法），然后内部有一个dao接口，继承该repository接口，提供一些内部使用的额外服务，比如一些数据库查询。接着有一个类继承框架提供的如spring的HiberanteTemplate同时实现dao接口，这样来改动的规模就比较小，一个接口和一个实现类。这个思路和SS2的思路是一样的。

框架数据访问已经提供一些公共的操作简化开发，当然还利用泛型等。此外，Ibatis3.0的设计思路，将是下一步的工作目标。

另外：通过root对象游走访问领域对象，性能可能有点问题。但这是可以接受的，因为从开发的角度看，通常都root下的对象都是和root对象一起出现操作的，不可能单一出现一个root以外的对象来操作以及显示的。

现在就说说Web层：
由于servcie对外都是开放domian model了，不再提供VO对象，免去无谓的copy property操作。而把VO的这部分工作交给自行开发的界面设计工具，因此在设计页面的时候其实已经知道的页面的访问的元素以及对象路径，在设计页面完成后由该设计工具生成VO对象和映射对象。这样VO对象的设计产生，以及property的copy都是工具完成，无须人工干预。

另外Web层采用SWF，除了完整的抽取出流程控制流转逻辑，还完整的封装了对于Request以及Response的数据访问操作。这样一个流程中调用了那些model以及servcie都非常清楚。将来有可能通过工具像规则引擎那样可以提供给业务人员直接使用。同时没有了传统的Control类结构的存在，极大的提高了开发效率问题。

模块边界的处理包括两个部分：
一是行为的边界集成上，比如订单管理模块对财务模块的行为要求。
订单管理模块自行设计它所需要的接口，由一个集成模块提供adapter类，来适配到财务模块合适的service上。这样就解决了旧系统设计现有的问题，旧系统现在都是直接调用财务模块提供的API，这样的做法实际上是把集成工作放在了订单管理模块下。

二是对象的边界集成，是这样做的。
订单明细对象（OrderItem）会关联一个产品对象，不过产品对象是是属于产品模块而非订单模块，对于订单模块只关心id而并不使用对象，但在规则引擎或者界面设计工具这样的集成环境却是需要产品对象的。我们采用代码生成的方式，在订单明细对象上加一个annotation，比如Integration的annotation标识，使用aspectj在编译上enhancement生成的class，使得订单明细对象在集成环境上可以拿到产品对象，这算是一个集成方面。

最后是domain model部分：
一类是类似保险中的保单对象这样的长生命周期对象；

另一类是transaction交易过程的对象，几乎没有生命周期的；

最后一类是request/response对象。这类对象以前没有识别，通常和VO混在一起；但是在IAA中以及电信业的模型是这类对象是独立存在，并被持久化的。
当然他们也是几乎没有生命周期的，request对象建立在增量更新上很有用。

reponse对象目前没有特别用途，依然采用VO处理。

request对象的建立有两个好处。
1. 以前直接更新订单对象，虽然记录了log但是只知道减肥前，减肥后。
2. request对象的第二个好处，可以解决一个业务事务跨越两个物理事务的设计问题。即一个业务请求可以分多次累进完成，比如分两天来处理，每天完成一个部分，但在完成之前，所有操作数据都不生效。在没有持久化request对象前，我们只能把操作的数据写到临时表上。

此外，由于某个领域模块的增量操作通常从一个根对象开始，所依赖的criteria可以从request中加以识别并通过框架提前加载，而service对象的方法接受传递对象而不再关心对象的加载工作；同时也可以通过框架处理基本数据复制工作，这样程序只关心关联对象的操作。这个做法和SS2是一样的，只不过采用的是AOP的处理方式。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

Author：Anders小明.

0. 业务分包.

在package命名上，摈斥了Appfuse以及SpringSide中出现的model, service以及manager等技术名词,取而代之的是业务名词和动词,使得行为和模型物理上内聚。我们以为对于开发人员来说，通过包名以及类名获取其业务功能远比了解其技术分类更有助于设计和开发。

这里借用springside的package前缀:

org.springside.insurance.product
org.springside.insurance.quotation
org.springside.insurance.quote
org.springside.insurance.contract
org.springside.insurance.newbiz
org.springside.insurance.cs
org.springside.insurance.claim
 

1. 抽象分层

业务是有抽象层次的. 往大的方面，可以见《Domain Model：基于抽象的分层结构》。这里只往小的方面说，比如保险中accident就拥有自己独立的业务概念和行为，并且这些概念和行为是紧耦合的。我们的目标是类似这样的业务抽象层次，我们只要发布相应的类和资源文件就可以在服务器上热部署。包的命名结构如下：

org.springside.insurance.accident.contract
org.springside.insurance.accident.product
org.springside.insurance.accident.quotation
org.springside.insurance.accident.quote
org.springside.insurance.accident.newbiz

当然可能有朋友说：我也可以这样命名，一样可以达到同样的目的。

org.springside.insurance.contract.accident
org.springside.insurance.product.accident
org.springside.insurance.quotation.accident
org.springside.insurance.quote.accident
org.springside.insurance.newbiz.accident

的确如此，对计算机或者jvm来说没有区别，它不管怎么命名。但是程序是写给人阅读的，我们希望在命名上能够尽量提供信息和暗示。我们以为，上一种命名方式更容易阅读，同时能给出紧耦合的暗示。

2. 技术职责分层

减少不必要的技术职责层次. 尤其是减少了Web层的VO. Web层直接访问Domain Model.

当然关于这点在技术上有过很多讨论. 我只想说的: 是否建立VO的题关键在于边界的确立, 建立边界的情况有两种:人员分工以及边界双方存在替换可能. 通常意义上Web和Domain都是一个人开发的,没有特别分工(也有可能不是同一个但没有出现并行开发, 美工除外)，即便此时强制要求设计VO，也会发现设计出来的VO和model非常的类似，但增加了不必要工作量，包括copy属性操作，以及null处理（是页面没有提交该值，还是user要清空该值）; 同时很少存在Web不替换而替换后台Service以及Model的情况. 因此我们可以得出一个结论：页面依赖于模型.

这样系统需要写代码的只有Service和Model两类对象 

还有一个类对象，传统的Dao，这类对象比较麻烦。采用DDD中提出的Aggregate模式，把domain模型区分开来。Domain Model利用主对象作为root，游走访问其关联对象，减少dao爆炸，使OLTP中的dao保持在较少的一个层次；对于Report或者OLAP则利用其它SQL保持性能。（关于这块目前的没有遇到大的问题，不算成功了，还在尝试中）
 

3. 业务职责设计模块

主要工作在模块间的交互接口设计：适应性接口和公共接口分离。 (原则:不要以用户无法使用或不感兴趣的东西扰乱类的公有接口). 在我的另一篇blog《模块的接口设计》中有描述.

4. 代码和文档的统一。

文档的维护一直是比较麻烦的问题。尝试通过Annotation等元数据来帮助我们简化工作。

首先Annotation能够提供的信息有三个级别：代码级别（IDE支持, JavaDoc），编译级别（编译器支持，代码生成），运行时级别（框架反射）。尤其是后两种，既是设计又是代码。除此外Spring的XML还包括很多信息，例如事务声明，Web Flow的页面流程信息等。

尝试通过应用更多既是设计又是代码的元数据，在借助一定手段收集这些信息，减少在文档上的工作量。

5. 设计上的细节

在Service对象的设计上。按model是骨架, service是肌肉,而rule是神经的职责分类.service对象的设计以行为为主线,利用template模式把rule做一定分离。另一个原因是系统应用了规则引擎，采用这样的设计有利于单元测试。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

想想也是：
VM的更新工程浩大且影响面广，而在编译器中动手脚简直是低风险高收益的买卖，何乐而不为。
而手握像antlr这样一神兵利器更是如虎添翼。

那么下一个带来惊喜将会是什么？DSL还是其它？

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

Author: Anders小明 

        任何一个有一定规模系统，通常会把系统做一定分解降低分析设计开发的难度，模块划分是一个比较常见的方式。
        而在模块的划分，及其分析设计的实践中，模块和模块的交互接口最为重要，通常我们认为这些接口应该通用稳定，然而如何设计每个模块对外提供的接口却是一个不易的问题。
        实践中，极有可能出现两种状况：接口维护失控或者过严而死板（而影响开发）。接口失控是因为接口的维护太过随意，因为A模块的需要就轻易在B模块中添加一个接口（方法），导致该接口（方法）非独立性（基本上只给模块A的这个功能点使用），或者是接口的控制过严，导致或者工作效率不高，或者接口的易用性不好。
原因在于：接口是两个模块间的耦合，而发生的种种问题在于模块耦合太过紧密；同时实践中，把模块对外提供的接口，与模块需要实现的外部模块的接口混为一谈。 
        根据指导原则：为了降低耦合只有在中间加一层。一种可行的实践是：不轻易为模块设计对外提供的接口（方法），除非是通过重构得来的；模块对外提供两种类：一个是需要外部模块实现的接口（接口设计从本模块需要出发，当然每个接口尽管是为某个功能点服务，但也要注意其在模块内通用性），另一个是其它模块要求本模块实现的接口的实现类。 
        即：A模块拥有一些需要B模块实现的接口（A模块对B模块的要求），而B模块中也有要求A模块实现的接口，因而A有这些接口的实现类。
        这种实践方式的好处在于：模块的接口就多了一层隔离降低了耦合，把接口的通用性和接口的适应性分离，又明确了模块的边界，使得接口在日后的优化和调整有了缓冲。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

《domain model的延伸讨论》 http://www.javaeye.com/topic/57075
robbin试图用两个例子来支撑其观点似乎太过牵强！

1. ruby的代码中是domain model直接包含了操作集合的代码，java的理念则不是如此。用来比较优劣是否妥当暂且不说，首要的问题在于：domain model理念是哪个？是允许一个对象包含自己的集合操作还是不可以？
我以为目前并没有定论。
退一万步说，就算是允许，那么java可以参照的同级别的语言是有些ADO.NET的C#（C#是可以和ruby在ActiveRecord可比的），java想做不难！
再次，允许是一回事，好不好又是另一回事。

回到正题，既然是比较就要标准统一，表面上看都是同一个题目，其实背后的理念是不一样（由此引发的种种设计实现上的变化，robbin就得出了ruby可以做更多的逻辑，因而……），
然而我以为这样的比较是支持不了robbin的观点的。

2. robbin说：“但是Java如果不使用IoC方式注入，而是直接调用依赖类的静态方法，行为就被限定死了，复杂的类依赖关系的创建和织入就是一个很麻烦的问题，这也是Java引入IoC的主要原因。”
为什么不可以直接调用依赖类的静态方法，我可以不用IoC而用AspectJ。可以看看我之前写的blog
http://www.blogjava.net/AndersLin/archive/2007/02/09/95666.html
或者
http://yimlin.javaeye.com/blog/53545
看上去有点抬杠，其实不是，看官们请冷静思考一下这个问题（又或各位不以为然，没有关系）。

因此robbin说：“对于Java来说，更加适合采用贫血的模型，Java比较适合于把一个复杂的业务逻辑分离到n个小对象中去，每个小对象描述单一的职责，n个对象互相协作来表达一个复杂的业务逻辑，这n个对象之间的依赖和协作需要通过外部的容器例如IoC来显式的管理。但对于每个具体的对象来说，他们毫无疑问是贫血的。”
从robbin写的这样java来看，似乎确实如此。然而java的程序的设计是否就此一种。
如果用AspectJ来重写代码，是否还需要那么多接口，那么类？同样加上annotation的应用，又可以省去xml文件
有关于dao的设计可以这样处理：
public class User{ public static UserFinder finder; ...... }
public interface UserFinder{ public List doQuery(...); ...... }
public class UserService{ public void FindByDept(...){ List list = User.finder.doQuery(....); .... } }
这里我选择保留了接口，实际的情况则是未必，各自选择。

3. Java在AspectJ的支持下，可以对domain model的各个方面的逻辑进行切割，就像C#的partial class那样，一个应用就是
http://yimlin.javaeye.com/blog/54060
我以为是可以解决robbin所认为的一个”充血模型的坏处“：对象高度自洽的结果是不利于大规模团队分工协作。一个编程个体至少要完成一个完整业务逻辑的功能。对于单个完整业务逻辑，无法再细分下去了。

4.如果robbin的观点是：ruby和java在实践domain model理念中，因为ruby的语言特性及其设计理念比java的有自己的优势，那我认为没有什么问题。而现有观点太过草率和武断了。


BTW：感谢newman对小弟《小议领域模型》一文的认可。

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

Interface play as Placeholder, without any class implement it
Author：Anders小明

有个这个题目是在ApectJ的应用，以及博客园子中一个blog讨论什么时候用接口（一个很古老的话题）。
接口作为一种重要的抽象能力，重要意义在于：
模型上看：接口代表做什么，而实现表示怎么做！
在框架上：接口代表稳定，而实现代表多变！
在语言上：接口代表0，而实现代表1，通过对象类型消除if…else…。
（这段话我<<Domain Model：业务流程的进一步分析2>>提过）
既然是应用开发，模型角度看根据现实意义，没有AspectJ前的开发，都是设计好一个接口，然后至少一个实现类，然后通过factory获取正确的实现类，后来spring出现了，实现了IoC。然而由于AspecJ横空出世了，我们又多了一种手段：接口作为占位符, 而没有实现类(当然有实现)。这是我在看到partech的sunflower的代码后才想到的!虽然我在<<AOSD：应用AOP实现业务逻辑>>一文中已经想到了一些,然而还是没有partech来的狠!
下面是一个简单的例子：
Order类

package placeholder;

import java.util.Date;