领域驱动设计

DDD是领域驱动设计的简写。前段时间听群友说行业里少有DDD的代码案例，进而对DDD没有一个感性的认识。我想这是行业里普遍存在的现象吧。所以，我就有了写此文的想法。 本文开篇介绍了行业里比较普遍的代码风格，接着，我采用DDD风格对其进行修改。 我无意说服读者要按照我认为的DDD的风格来写代码，只是想告诉大家，这个世界上，还存在另一种代码风格。 如果各位觉得这样的风格好，可以尝试一下。非常欢迎大家反馈，平时太少人和我交流这些了。 文章标题说的是“同事的代码”，其实只是为了让此文更具传播，没别的意思。 如果你觉得此文对你有帮助，麻烦转发。干货好文不易。谢谢。 本文虽是以Java语言为案例演示，也希望对其它语言的读者朋友有帮助。 行业里普遍的代码风格，简称A风格 代码结构如下： ├── domain domain模块被同事认为是用于存放专门和DB打交道的类的地方 - src/main/java/com/xx/domain/account/repository/AbcLoginInfoRepository.java - src/main/java/com/xx/domain/account/AbcLoginInfo.java ├── repository-impl - 包路径太长省略/AbcLoginInfoRepositoryImlp.java ├── server - src/main/java/com/xx/server/login/LoginService.java - src/main/java/com/xx/server/login/LoginController.java - src/main/java/com/xx/server/login/AuthCodeVo.java - src/main/java/com/xx/server/login/UserInfoVo.java - src/main/java/com/xx/config/AbcWebMvcConfigurer.java Server模块 A风格下，整个业务系统的业务逻辑都在此模块中。 LoginController.java 实现http服务： @Controller @RequestMapping public class LoginController { @Autowired LoginService loginService; // 省略一些不重要的代码 @GetMapping(value = "/login") @ResponseBody public UserInfoVo login(String code) throws IOException { UserInfoVo userInfoVo = loginService.login(code, httpServletResponse); httpServletResponse.sendRedirect("/"); return userInfoVo; } @GetMapping(value = "/logout") @ResponseBody public boolean logout() { return loginService.logout(httpServletRequest,httpServletResponse); } } UserInfoVo.java是返回给前端的用户信息的结构体： ...

笔者2011年入行时，运气好，遇到了我的恩师simon杨。 当时，我们几个还不知道什么叫SSH（Spring、Struts、Hibernate）的毕业生和一个高级程序员基于DDDLib就开始实践领域驱动设计。现在想想还是觉得不可思议。一毕业就开始接触这门DDD技艺。 我记得当时simon杨经常谈如何利用抽象、解耦，在不增加复杂性的同时实现简单性、一致性、灵活性、可扩展性。至于如何实现CRUD，那是具体实现的问题，可以放在最后做。当他谈到某个精妙的设计时，眼神里都满是光。 在他的教导下，我就开始似懂非懂地读《领域驱动设计》、《企业应用架构模式》、《敏捷软件开发——原则、模式与实践》等这些高层设计类的书籍。 也许你会说，对于一个刚毕业的人学习这些“高层”设计，是不是太早了，毕竟你连CRUD都还不熟练。 在我工作10年之后看来，越早学习这些，越好。当你习惯使用CRUD的思维方式来看所有的问题时，你的思维方式已经固化，是很难接受DDD这套思维方式的。我尝试过说服不同工作经验的人使用DDD，无果。 2013年，在国内，也只有Jdon网站讨论DDD。而我们已经跟着simon杨在项目上实践DDD两年了。 2014年左右，为了验证了我是否真的理解DDD，我利用一次比赛的机会采用DDD的方式设计了一个BlackJack的游戏的核心。到此，我才算是对DDD有了一个更深入的理解。 但是，在2014年以后到现在的2021年，我就再也没有接触过DDD的项目了。而我，只能在自己的工作内容范围内实践，比如某个功能、某个模块。 值得说的是，我最近3年做的是DevOps相关的工作，但是DDD的思维方式依然能帮助我很好的完成工作。 比如在实现流水线时，将构建工具逻辑与流水线流程逻辑解耦、在设计 版本号时，将构建工具本身的版本号与流水线流程生成的版本号分离。 如果你不熟悉DevOps也没有关系，你只需要知道DDD贯穿着整个系统设计的每一个细节。 现在市场上把DDD吹得很高大上，似乎只有在架构上做DDD，才叫DDD。又或者非得和微服务关联在一起，才叫DDD。 其实不然，DDD的原意是领域驱动设计。只要你是使用领域知识来驱动你的设计，这个设计可以是方法级别的设计、类级别的设计、前端UI的设计等一切设计，你都可以叫DDD。 也许，这样的话听起来就像“色即是空，空即是色”一样让人不知所云。 没办法，10年了，我也没有找到非常好的让人一下就懂这种思维方式的方法。 如果非得要我介绍一下DDD的思维是什么，我觉得就是：不停地问问题是什么，解决方案是什么。然后优先从问题域着手设计。在确定问题域设计得差不多了，才开始实现解决方案。 这里要提个问，如果拿到一个需求时，先设计MySQL的表结构，再根据表结构导出类。这样的方式符合DDD的思维方式吗？如果不符合，与DDD的思维方式有什么区别？ 最后，我想说的是《领域驱动设计》我读过3遍了，也实践这么多年了，我依然记不清“战略设计”、“柔性设计”等这些术语的准确定义。我也建议各位不要去记那些术语的定义，更不要去争论那些术语的定义，而是要从DDD的原意开始去理解DDD。也就是每当遇到一个术语，你就提问：它是帮助你领域驱动设计的呢。