设计方法(域驱动或服务驱动)

时间:2010-08-04 12:13:47

标签: java architecture domain-driven-design

我的问题陈述是:

我想编写设计文件管理(添加,复制,删除等操作)。有两种方法:

  1. 服务驱动方法
  2. 写入仅包含文件属性的文件VO。例如,

    
    public Class File {
        private boolean hidden;
        private boolean read;
        private boolean write;
    
        public boolean isHidden() {
            return hidden;
        }
        public void setHidden(boolean hidden) {
            this.hidden = hidden;
        }
        public boolean isRead() {
            return read;
        }
        public void setRead(boolean read) {
            this.read = read;
        }
        public boolean isWrite() {
            return write;
        }
        public void setWrite(boolean write) {
            this.write = write;
        }
    }
    

    并为文件相关操作分离服务。对于例如:

    
    public Class FileService {
            public boolean deleteFile(File file) {
                //Add delete logic.
            }
            //Same way you can add methods for Add and copy file.
    }
    
    1. 域驱动方法(我可能在这里错了。)
    2. 文件VO包含所有属性和所需操作:

      
      public class File {
          private boolean hidden;
          private boolean read;
          private boolean write;
      
          public boolean isHidden() {
              return hidden;
          }
          public void setHidden(boolean hidden) {
              this.hidden = hidden;
          }
          public boolean isRead() {
              return read;
          }
          public void setRead(boolean read) {
              this.read = read;
          }
          public boolean isWrite() {
              return write;
          }
          public void setWrite(boolean write) {
              this.write = write;
          }
              public boolean deleteFile() {
                  //Add delete logic.
              }
              //Same way you can add methods for Add and copy file.
      }
      

      那么这种方法的优点和缺点是什么?

2 个答案:

答案 0 :(得分:6)

在面向对象的语言中,将逻辑放在类本身而不是服务类中是典型的方法(以及更好的IMO)。它遵循“告诉,不要问”原则,例如,通过告诉文件删除自己,而不是要求某些服务删除它。这背后的主要原因之一是允许继承。例如,如果你有一个File的子类,并希望在删除它之前让它写一条日志消息,那么对服务类来说就很难了,因为你需要为每个子类使用不同的服务类。

就面向服务的方法而言,这通常被认为是更高层次的(即面向服务的架构)。考虑一个金融股票系统,您可能有“买入股票”服务和“卖出股票”服务。拥有一个与个别类别相对应的服务类(即一个知道如何买卖股票的股票服务)不会非常面向对象。

您的系统中也可能有一个服务层,它提供与其他外部服务(即数据库)的集成点,但同样,我不认为这就是您在这里所说的。所以,我可以坚持在File类本身中封装逻辑的方法。

答案 1 :(得分:4)

如果没有太多关于您正在设计的系统的信息,那么很难发音。对我而言,选择取决于系统边界。

如果您需要提供作为服务公开且外部消费者可访问的API,请转到解决方案1,这是唯一的方法。如果你的系统是一个库,其API将由其他应用程序在内部使用,那么在解决方案2中寻找一个丰富的域模型,它就是更多的OO。您不希望使用没有真正原因的服务,管理器和实用程序类来扩展您的API。

但是,再一次,在不知道你的最终目标的情况下,很难说。