一个简单的菜单管理，我却迷茫了，求解惑

一、需求
    做一个简单的CMS，关于菜单部分的需求。
    系统管理员输入账号密码登陆后台系统后，首页面显示布局为：顶部水平显示一行导航菜单，左边栏显示树形菜单，点击不同的导航菜单，左边栏显示不同的树形菜单。中间是工作区。
    系统管理员在导航菜单中点击菜单管理，左边栏显示：
   
    导航菜单
       |——所有导航菜单
       |——添加导航菜单
    树形菜单
       |——所有树形菜单
       |——添加树形菜单

    点击添加树形菜单，工作区弹出添加页面，从上到下要求包括：
   
    所属导航菜单（点击下拉列表，必填）
    父菜单（点击下来列表，可以不选表示没有父菜单）
    菜单名（必填，必须中文，2-8字，不能与现有树形菜单同名）
    url（必填）
    排序（整数型，必填）

    提交后，要验证导航菜单和父菜单是否存在。
    其他更详细的描述略之。

二、需求分析（场景在前面有描述，下面有所省略，主要围绕添加树形菜单）
    1.业务建模
        (a)业务用例：管理菜单
    2.用例分析
        用例：管理菜单
        业务活动：添加树形菜单，修改树形菜单，删除树形菜单，查询所有树形菜单，查询所有导航菜单，根据菜单名查询导航菜单，根据菜单名查询树形菜单
    3.系统建模
         用例：把上者的业务活动的节点作为一个系统用例
         用例关系：菜单管理include（添加树形菜单include（查询所有导航菜单，查询所有树形菜单，根据名字查询导航菜单，根据名字查询树形菜单））
         系统架构：B/S，REST，MVC...
         系统范围：...
         ...

三、概要设计
    1.领域模型：导航菜单，树形菜单
    2.包+类：
          menu
           |—controller
           |     |—TreeMenuController.class
           |—service
           |     |—MenuManager.class
           |—dao
           |   |—TreeMenuDAO.class
           |   |—NavMenuDAO.class
           |—entity
                |—TreeMenu.class
                |—NavMenu.class

     PS:1.原谅我用贫血模型 2.po和dto几乎一样，用entity算了
                

    3.领域类：NavMenu，TreeMenu
    4.领域类关系：NavMenu(1) —关联— (n)TreeMenu 树形菜单中 父菜单(1) —父子— (n)子菜单
    5.类图：...
    ...

四、困惑
    说困惑之前说说我的想法。
    1.因为TreeMenu需要依赖NavMenu，所以模块划分的时候，抽象一个层次为Menu
    2.同样考虑，抽象为MenuManager来做服务接口。
    3.MenuManager依赖DAO接口，不依赖具体实现，具体实现类通过外部框架进行注入，从代码层面上解耦。
    困惑来了。
    1.采取的是贫血模型，如果我要用充血模型，请问怎么做？我尝试过，可是感觉失败了。我自己的做法是：
    menu
     |—application
     |       |—TreeMenuController.class
     |       |—TreeMenuVO
     |       |—NavMenuVO
     |       |—NavMenuService.class
     |       |—TreeMenuService.class
     |       |—impl
     |            |—TreeMenuServiceImpl.class
     |            |—NavMenuServiceImpl.class
     |—domain
     |     |—NavMenu.class
     |     |—NavMenuRepository.class
     |     |—TreeMenu.class
     |     |—TreeMenuRepository.class
     |—infrastructure
              |—NavMenuDAO.class
              |—TreeMenuDAO.class
              |—NavMenuPO.class
              |—TreeMenuPO.class
              |—TreeMenuAssembler.class
              |—NavMenuAssembler.class
              |—impl
                  |—NavMenuDAOImpl.class
                  |—TreeMenuDAOImpl.class

    几点说明：TreeMenuVO、NavMenuVO是DTO，TreeMenuPO、NavMenuPO是持久化对象，他们都由TreeMenuAssembler和NavMenuAssembler负责组装，po数据从数据库查出来，然后将数据装配到domain里，最后继续装配到vo里。反之亦然。

    依赖关系：controller——>service——>repository——>dao

    这么下来后感觉怪怪的，多了好多类，不知道这样算不算DDD。算不算领域模型驱动。囧。望朋友能够指正。
   
    2.对于TreeMenuService来说，它有个操作，添加树形菜单，需要去查询获取所有的导航菜单，那么这个查询操作属于NavMenuService的职责吗？当然，它一定属于NavMenuDomainObject的。假设它也属于NavMenuService的方法，那么我想问，TreeMenuServie可以调用NavMenuService的方法吗？或者我是否改抽象出一个MenuService来？

    补充：service主要作为事务边界和代理domain面向用户的接口，在其内部非简单代理domain的逻辑方法里，负责对多个domain的操作逻辑。而domain内部也有逻辑，但是这种逻辑仅与当前所在domain实例有关，不能与多个domain有关，如果是多个有关的话，应该要封装在service中。
    系统的dao，service都要面向接口编程，由外部框架进行依赖的注入。
    系统应该是按模块来进行包的组织。模块之间不能有任何的依赖，只能依赖公共组件。任何模块单独拿出来都能独立运行。
    前面说的menu就是一个模块。

评论

2 楼 laiweiweihi 2011-10-10  

ltian 写道

看了一下，胡说几句。

1.这个充血模型应是领域模型驱动，虽然多了很多类，但是层次分清了，好处在于将来任意一层发生变化时，重构代码量比较小，业务逻辑清晰，出现问题容易定位和调整。在简单业务逻辑下可能会略显啰嗦，但是一旦业务逻辑复杂之后，便会体现其巨大优势（在于积累领域业务知识和可复用代码资产，更易于阅读和维护，将数据库操作隔离在特定层中等等好处）。

2.查询获取所有的导航菜单，那么这个查询操作属于NavMenuService的职责吗？当然，它一定属于NavMenuDomainObject的。这个我有异议：

NavMenu是聚合了其他类的根类，因此对业务逻辑类进行包括查询在内的管理职责一般交给Repository（负责访问数据，装配和发装配PO与BO），业务逻辑类本身不负责这个工作。聚合的根类可以根据业务逻辑关系查找其所聚合的其他类，比如查找TreeMenu。聚合的根类查找其所聚合的其他类也可以通过其他类的Repository类来进行，一般来说Repository类不对展现层暴露。


因此，还缺了一个工厂类，用于提供根据类型查找Repository类的工厂。通过这个工厂的接口，业务逻辑类可以在任何需要的代码中找到其所聚合或使用的其他业务类。

NavMenuService是对domain 及以下层次的封装。主要对展现层，或者其他外部模块提供访问的服务。他可能是对domain （BO）或者Repository类，所提供的功能进行简单逻辑组合或代理。细节性的业务逻辑应不在此类中实现，该类可以作为主框架程序。

3.整体命名未彰显层次概念，命名有待优化。从命名上看未能很好体现规划明确类层次，展现层、业务逻辑层、Repository、持久化层命名不够清晰。

4.从业务模型上看，NavMenu 和TreeMenu都是一个东西，应该可以抽象为一个叫Menue的类，而不是两个类。这会大量减少类及代码量。

哈，大哥哥一出手果然不凡，多谢如此认真的回帖。真心感谢。

1 楼 ltian 2011-10-10  

看了一下，胡说几句。

1.这个充血模型应是领域模型驱动，虽然多了很多类，但是层次分清了，好处在于将来任意一层发生变化时，重构代码量比较小，业务逻辑清晰，出现问题容易定位和调整。在简单业务逻辑下可能会略显啰嗦，但是一旦业务逻辑复杂之后，便会体现其巨大优势（在于积累领域业务知识和可复用代码资产，更易于阅读和维护，将数据库操作隔离在特定层中等等好处）。

2.查询获取所有的导航菜单，那么这个查询操作属于NavMenuService的职责吗？当然，它一定属于NavMenuDomainObject的。这个我有异议：

NavMenu是聚合了其他类的根类，因此对业务逻辑类进行包括查询在内的管理职责一般交给Repository（负责访问数据，装配和发装配PO与BO），业务逻辑类本身不负责这个工作。聚合的根类可以根据业务逻辑关系查找其所聚合的其他类，比如查找TreeMenu。聚合的根类查找其所聚合的其他类也可以通过其他类的Repository类来进行，一般来说Repository类不对展现层暴露。


因此，还缺了一个工厂类，用于提供根据类型查找Repository类的工厂。通过这个工厂的接口，业务逻辑类可以在任何需要的代码中找到其所聚合或使用的其他业务类。

NavMenuService是对domain 及以下层次的封装。主要对展现层，或者其他外部模块提供访问的服务。他可能是对domain （BO）或者Repository类，所提供的功能进行简单逻辑组合或代理。细节性的业务逻辑应不在此类中实现，该类可以作为主框架程序。

3.整体命名未彰显层次概念，命名有待优化。从命名上看未能很好体现规划明确类层次，展现层、业务逻辑层、Repository、持久化层命名不够清晰。

4.从业务模型上看，NavMenu 和TreeMenu都是一个东西，应该可以抽象为一个叫Menue的类，而不是两个类。这会大量减少类及代码量。