接到一个需求，领导让从业务建模、技术建模、模块拆分、微服务设计、数据库表设计，在公司设计平台上都走一遍。需求交付又有时间节点，时间有点紧

在公司设计平台上建模做了一个初版，今天领导检查的时候，提了很多意见，领导还是有点东西的。领导也在考虑沟通问题，之前都是一起线下过设计。这次他把问题整理好了发我，我再回检，明天再和他线下对下

需求实现的时候，公司推荐两种架构选择。一个是传统的mvc三层架构模式，一个ddd四层架构模式。三层架构主要用于简单的业务场景，业务简单，主要是数据库的操作。ddd四层机构主要是应用于复杂的业务场景，比如需要和外部系统交互，接收消息中间件消息，需要调用外部接口，需要使用缓存中间件，业务逻辑复杂等。

如果需要调用外部接口，需要设计防腐层。ddd四层架构的domian领域层的support包或者领域服务定义接口，基础设施层实现接口，访问外部接口，实现防腐

业务逻辑复杂：三层架构，所有业务都散在在service层，service层逻辑过多，臃肿，不易维护。可以把业务逻辑沉淀到领域对象中，集中管理，拆分service业务逻辑

一、业务建模

角色：

　　有个角色我定义的是xx微服务，领导觉得可以再具体点xx系统

命令：

　　我开始以为四层架构的命令是领域对象的方法，命令是一个实体，封装了要做的事情，类似于DTO，不过主要是封装要做的事情需要的字段。有个命令我写的是名单写入数据库，业务建模不应该和技术关联起来。可以修改成保存要迁移的名单

　　需求地图识别的时候，识别了很多命令。因为我因为命令是对象的一个方法，就没有把命令放到领域对象里面。其实，命令是一个领域对象的职责边界里面的东西，是一个单独的类，类似于DTO，封装了命令的字段。比如取消订单命令，CancelCommand是一个单独的类，里面有要取消的订单id。

领域对象识别：

　　之前有个类似的需求实现，我参考的之前的实现写领域对象。之前的实现方案有，通过多种条件过滤用户。我把数据库里面查询的表，直接作为领域对象。其实抽象都是客户，不用新建其他xx客户

还有些其他的意见，明天再梳理下和领导对下。ddd四层架构在公司应用应该比较久了，看代码提交记录，应该有几年了。确实比mvc三层架构要好一些，在解耦、防腐、维护、扩展这些确实要好一些