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

一、需求
    做一个简单的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就是一个模块。

楼主，这一个狠简单的东西，何必想复杂？

看菜单管理表面是简单，但是通过建模到实现不容易。虽然小，但是按照RUP的过程来走的话，属于软件开发方法学的一个落地实践。是检验方法学掌握程度的一个途径。
可能我在帖子里说的不够清楚，我的困惑是对于Service这种层次里，允不允许相互调用？还有在这个场景里，贫血模型，充血模型哪个会比较适合？单讨论结果没意思，讨论下结果是怎么得出的，它内部的逻辑怎么样的。

有人非得让简单问题复杂化，你能有啥想法捏？果断隐藏。

弄这么复杂干嘛， 好好学习一下领域驱动吧

楼上的说的没错，楼主确实把问题复杂化了。
菜单ID 菜单名称 父菜单ID URL访问路径 排序值 菜单说明 这几个点单的属性就构成了一个菜单对象。

两级 嵌套循环
多级 递推

至于前台采用的是 树？ 横向菜单？ 左边ul li类的 导航菜单？这关数据库什么事？这些只与你前台页面的逻辑相关。

回复LS的所有人，我表示比较无奈。我知道问题确实很简单，但是一定需要提出一个很难很复杂的问题才能用来讨论领域驱动开发吗？

也许是我把简单问题复杂化了，但是我不是为了解决这个菜单管理问题。我实在是对领域驱动实践知之甚少。

本来是想通过一个简单的问题，去讨论领域模型开发的实践过程，只是没想到各位看官这么不淡定，仅看到问题的简单性，就不屑于进一步的讨论，反而在纠结一些表面的东西。

此时我内心是很复杂的。

树形菜单、和横向菜单是有区别的，前者具有层级关系，而且是递归父子关系。在建模的时候肯定会影响到数据库表的设置。后者导航菜单只是一列菜单而已。菜单与菜单之间没有任何关系。

另外，可能确实是我表达出来的不够清晰，其实我想讨论包括我困惑的地方不是菜单管理这个功能实现的问题。而是实现方式的选择问题，对于解决这个问题的方式，我想能有很多种，可以采用面向过程，面向对象，而对于代码编写来说，可以不考虑任何系统的扩展性、复用性等等去写，也可以分好层次，高内聚低耦合的设计代码结构。但是，你在实践这些东西的时候，究竟是基于什么样的开发方法学？我想它应该是一个值得讨论的事情，而不应该是大家都这么做我也就这么做了。你要说我把菜单管理问题复杂化了，我想你是过于关注菜单管理这四个字眼了。如果在菜单管理功能的实现上找到合适自己的开发方法过程。我想对于解决其他问题，不管多复杂，多简单，都是适用的，我们都知道，一个复杂的问题总是可以通过某种手段层层分解为一个个简单的问题。那么在解决这些简单的问题是你是否一样像现在这样不屑之呢？

抱歉说的有点多了。

生搬硬套设计模式，所谓的XXX驱动，只能带来负面效果
我个人还是推崇简洁设计风格，simple is powerful……

这么深奥，学习下