domain model，又稱為領(lǐng)域模型，是Java企業(yè)應(yīng)用討論的一個(gè)熱門話題，JavaEye也曾經(jīng)多次圍繞這個(gè)話題討論，我們來看個(gè)簡單的例子：



我們先看看用ruby如何實(shí)現(xiàn)系統(tǒng)的領(lǐng)域模型：

class User < ActiveRecord::Base
  has_and_belongs_to_many :kinds
  
  has_many :tasks, :dependent => :destroy do
    def processing_tasks
      find :all, :conditions => ["start_time <= ? AND end_time is null", Time.now]
    end
  end
  
  def apply_task(task_name)
    self.tasks << Task.new(:name => task_name, :start_time => Date.today)   
  end   
    
  def self.all_processing_tasks
    Task.find :all, :conditions => ["start_time <= ? AND end_time is null AND user_id is not null",Time.now]
  end
end

class Task < ActiveRecord::Base
  belongs_to : owner, :class_name => 'User', :foreign_key => 'user_id'
  belongs_to :kind
  
  def self.current_month_tasks(kind)
    kind.tasks.current_month_tasks 
  end
end

class Kind < ActiveRecord::Base
  has_and_belongs_to_many :users
  
  has_many :tasks do
    def current_month_tasks
      month_begin = Date.today - Date.today.mday + 1
      month_end = Date.today - Date.today.mday + 30
      processing_tasks = find :all, :conditions => ["start_time <= ? AND end_time is null ", month_begin]
      processed_tasks = find :all, :conditions => ["end_time >= ? AND end_time <= ? ", month_begin, month_end]
      all_tasks = processing_tasks.clone
      all_tasks << processed_tasks unless processed_tasks.size == 0
      return all_tasks, processed_tasks, processing_tasks
    end
  end
  
  def add_batch_task_to_users(task_name)
    self.users.each do |user|
      task = Task.new(:name => task_name, :start_time => Date.today) 
      user.tasks << task
      self.tasks << task
    end  
  end
end

class Department
  def self.employee(username, department)   
    User.create(:name => username, :department => department)   
  end  
  
  def self.total_salary(department)
    User.sum :salary, :conditions => ["department = ?", department]
  end
end

1、某部門錄用一名新員工

Department.employee("robbin","開發(fā)部")

2、某部門員工總薪水總和

Department.total_salary("開發(fā)部")

3、某員工已經(jīng)開始但尚未結(jié)束的任務(wù)

user.tasks.processing_tasks

4、給某員工分配一項(xiàng)任務(wù)

user.apply_task("學(xué)習(xí)Java")

5、所有用戶當(dāng)前已經(jīng)開始但尚未結(jié)束的任務(wù)

User.all_processing_tasks

6、對某一類別,給所有和此一類別相關(guān)的員工,批量新增一批任務(wù)

kind.add_batch_task_to_users("學(xué)習(xí)單元測試")

7、針對任務(wù)的統(tǒng)計(jì)功能，給定某類別,統(tǒng)計(jì)當(dāng)月總的任務(wù)數(shù),已完成任務(wù)數(shù),未完成任務(wù)數(shù)

Task.current_month_tasks(kind)

這里值得注意的是，RoR可以很方便的采用充血的領(lǐng)域模型，所有的業(yè)務(wù)邏輯都可以放在相關(guān)的domain model里面。這里的user，task和kind都是對應(yīng)于數(shù)據(jù)庫表的領(lǐng)域模型，而department是不對應(yīng)數(shù)據(jù)庫的純業(yè)務(wù)邏輯的domain model。總共4個(gè)ruby文件，4個(gè)domain model，55行代碼，所有要寫的代碼都在這里了，代碼量確實(shí)非常少，每個(gè)domain model的顆粒度都比較大。

然后我們再看看如何用Java：

public class User {
    private Long id;
    private String name;
    private String password;
    private String gender;
    private String department;
    private int salary = 0;
    private List<Task> tasks = new ArrayList<Task>();
    # omit getter/setter methods ......
}

# omit User's ORM Mapping file

public class Task {
    private Long id;
    private String name;
    private int duration = 0;
    private User owner;
    # omit getter/setter methods ......
}

# omit Task's ORM Mapping file

public class Kind { 
    ......
}

# omit Kind's ORM Mapping file

public interface UserDao {
    public void addUser(User user);
    public loadUserById(Long id);
    # omit CRUD and other persistent methods ......
    public List<User> findByDeparment(String department);
}

public interface TaskDao {
    # omit CRUD and other persistent methods ......
}

public class UserDaoImpl {
    # omit implementations ......
}

public class TaskDaoImpl {
    # omit implementations ......
}


public class UserService {
    private UserDao userDao;
    public setUserDao(UserDao userDao) { this.userDao = userDao; }
    public int workload(User user) {
        int totalDuration = 0;
        for (Task task : user.getTasks()) {
            totalDuration += task.duration;
        }
        return totalDuration;
    }
    public employee(String username, String department) {
        User user = new User();
        user.setName(username);
        user.setDepartment(department);
        userDao.addUser(user);
    }
}

public class TaskService {
    private TaskDao taskDao;
    public void setTaskDao(TaskDao taskDao) { this.taskDao = taskDao }
    public applyTask(String taskName, User user) {
        Task task = new Task();
        task.setName(taskName);
        task.setUser(user);
        taskDao.addTask(task);
    }
}

public class DepartmentService {
    private UserDao userDao;
    public void setUserDao(UserDao userDao) { this.userDao = userDao; }
    private UserService userService;
    public void setUserService(UserService userService) { this.userService = userService; }
    public int totalSalary(String department) {
        ......
    }
    ......  
} 

# omit IoC Container weaving configuration's file

Java版本的實(shí)現(xiàn)代碼大家都比較熟悉，因此絕大部分代碼都省略了。Java版本需要3個(gè)持久對象，3個(gè)映射XML文件，3個(gè)DAO接口和實(shí)現(xiàn)類，4個(gè)Service和實(shí)現(xiàn)類，和一個(gè)IoC的bean組裝文件，總共21個(gè)文件，全部邏輯寫完整，代碼行數(shù)至少上千行。

通過對比，我們可以看到Java比較流行的實(shí)現(xiàn)是貧血的模型，按照面向?qū)ο蟮幕�本原則，對象的狀態(tài)應(yīng)該和它的行為封裝在一起，因此Java多出來的這些XXXService是一些從純理論角度而言應(yīng)該放入其相應(yīng)的持久對象中去。但是Java實(shí)現(xiàn)充血模型從技術(shù)上有一定的難度，如何Service方法挪入到持久對象中呢？如何解決Dao的注入問題？如何解決domain logic方法的事務(wù)封裝問題？前者可以通過AspectJ的靜態(tài)織入來解決，后者也許可以通過織入或者annotation聲明來解決。但不管怎么說，Java從技術(shù)上很難實(shí)現(xiàn)充血模型，而且即使實(shí)現(xiàn)充血模型，也會導(dǎo)致一個(gè)Java類好幾百行代碼的狀況，其代碼的可閱讀性，模塊解藕能力都會變得很差，因此我們認(rèn)為Java不適合充血模型，在表達(dá)復(fù)雜的業(yè)務(wù)邏輯的能力上，Java要比ruby差很多：

結(jié)論：
對于Java來說，更加適合采用貧血的模型，Java比較適合于把一個(gè)復(fù)雜的業(yè)務(wù)邏輯分離到n個(gè)小對象中去，每個(gè)小對象描述單一的職責(zé)，n個(gè)對象互相協(xié)作來表達(dá)一個(gè)復(fù)雜的業(yè)務(wù)邏輯，這n個(gè)對象之間的依賴和協(xié)作需要通過外部的容器例如IoC來顯式的管理。但對于每個(gè)具體的對象來說，他們毫無疑問是貧血的。

這種貧血的模型好處是：
1、每個(gè)貧血對象職責(zé)單一，所以模塊解藕程度很高，有利于錯(cuò)誤的隔離。
2、非常重要的是，這種模型非常適合于軟件外包和大規(guī)模軟件團(tuán)隊(duì)的協(xié)作。每個(gè)編程個(gè)體只需要負(fù)責(zé)單一職責(zé)的小對象模塊編寫，不會互相影響。

貧血模型的壞處是：
1、由于對象狀態(tài)和行為分離，所以一個(gè)完整的業(yè)務(wù)邏輯的描述不能夠在一個(gè)類當(dāng)中完成，而是一組互相協(xié)作的類共同完成的。因此可復(fù)用的顆粒度比較小，代碼量膨脹的很厲害，最重要的是業(yè)務(wù)邏輯的描述能力比較差，一個(gè)稍微復(fù)雜的業(yè)務(wù)邏輯，就需要太多類和太多代碼去表達(dá)(針對我們假定的這個(gè)簡單的工時(shí)管理系統(tǒng)的業(yè)務(wù)邏輯實(shí)現(xiàn)，ruby使用了50行代碼，但Java至少要上千行代碼)。
2、對象協(xié)作依賴于外部容器的組裝，因此裸寫代碼是不可能的了，必須借助于外部的IoC容器。

對于Ruby來說，更加適合充血模型。因?yàn)閞uby語言的表達(dá)能力非常強(qiáng)大，現(xiàn)在用ruby做企業(yè)應(yīng)用的DSL是一個(gè)很熱門的領(lǐng)域，DSL說白了就是用來描述某個(gè)行業(yè)業(yè)務(wù)邏輯的專用語言。

充血模型的好處是：
1、對象自洽程度很高，表達(dá)能力很強(qiáng)，因此非常適合于復(fù)雜的企業(yè)業(yè)務(wù)邏輯的實(shí)現(xiàn)，以及可復(fù)用程度比較高。
2、不必依賴外部容器的組裝，所以RoR沒有IoC的概念。

充血模型的壞處是：
1、對象高度自洽的結(jié)果是不利于大規(guī)模團(tuán)隊(duì)分工協(xié)作。一個(gè)編程個(gè)體至少要完成一個(gè)完整業(yè)務(wù)邏輯的功能。對于單個(gè)完整業(yè)務(wù)邏輯，無法再細(xì)分下去了。
2、隨著業(yè)務(wù)邏輯的變動，領(lǐng)域模型可能會處于比較頻繁的變動狀態(tài)中，領(lǐng)域模型不夠穩(wěn)定也會帶來web層代碼頻繁變動。

附件是完整的RoR版本的項(xiàng)目示例代碼。要運(yùn)行它，需要安裝MySQL數(shù)據(jù)庫(InnoDB表類型)，Ruby和Ruby on rails環(huán)境。在MySQL數(shù)據(jù)庫中分別創(chuàng)建demo數(shù)據(jù)庫和demo_test數(shù)據(jù)庫，修改demo\config\database.yml中的MySQL數(shù)據(jù)庫配置，改成你的數(shù)據(jù)庫密碼。然后在項(xiàng)目跟目錄下面執(zhí)行：
rake db:migrate
rake db:test:clone_structure
rake test
即創(chuàng)建開發(fā)環(huán)境數(shù)據(jù)庫，創(chuàng)建測試環(huán)境數(shù)據(jù)庫，和執(zhí)行所有的單元測試。領(lǐng)域模型代碼位于demo\app\models目錄下面；單元測試代碼位于demo\test\units目錄下面