你好，我是知瑕，前阿里巴巴技术专家，曾参与多个开源项目的研发工作，在分布式系统设计应用上有着较为丰富的经验。
在学习《如何落地业务建模》这门课之前，我已经实践了一段时间的DDD建模了。在实践过程中发现自己理论知识储备不足，经常在一些似是而非的问题上纠结徘徊，得不出结论，比如第6讲提到的分层问题。因此，就迫切希望能多掌握一些理论知识以指导实践。
极客时间推出的这门课，正好弥补了我平时因为项目紧、经常需要 on call，导致没有那么多时间静下心来去啃大部头，以系统学习理论知识的缺憾。这里也感谢徐昊老师精心设计了这道既有理论又有实践、内容充实的饕餮大餐。
好了，废话不多说，我们直奔主题，先来分享一下我学习这门课的方法。
建模是一门技艺，所以我的看法是，需要通过大量的、不断的刻意练习，才能把这门技艺练会。需要强调的是，刻意练习不是简单的重复，而是针对一项希望掌握的建模方法，专注的、有目的性的进行练习，并在这个自我训练的过程中找不足，不断改善和提高，直至完全掌握并运用自如。
所以针对老师在课程中讲授的一些建模方法，我经常会在项目开发的过程中，挑选一些熟悉的模块，然后尝试运用这些建模方法去重构这些模块。
比如第4讲介绍的关联对象，在使用贫血模型的项目中，有很多实体对象都可以使用这个方法来重构。而且因为逻辑简单，这种重构引入新Bug的概率并不高。更重要的是，这些练习都是在正常项目开发过程中“顺便”且“刻意”进行的，并不会影响项目进度。总之，量大、风险可控，可以让我短时间内安全的、专注的、大量的练习这种建模方法，并不断改进使用方法，直至完全掌握。
再比如说，在实际项目开发过程中，我们会经常遇到需求不能理解到位、项目总是延期等糟心事。那么除了发发牢骚，我们也可以尝试使用所学的理论知识，去分析这些问题背后的原因，寻找解决问题的根本方法。就像第2讲提到的对统一语言的思考。“纸上得来终觉浅，绝知此事要躬行。”我们也可以通过践行这些理论来深化、修正自己对这些理论的理解。
当然，在刻意练习的过程中，我认为也要避免教条主义。所有的理论和技巧都有它的适用范围和前提条件，老师在课程中讲授的一些技术非常超前，对使用者及其团队有着很高的要求，但是可能限于篇幅，课程中并没有作太多的阐述。
比如第11讲提到的 HATEOAS，很多年前我刚接触 RESTful 时就专门了解过这项技术，惊叹于它的美好愿景，也曾经尝试使用这项技术去解决一些问题。然而在实践过程中，我发现这项技术对团队整体认知水平还是有很高的要求的，因此强行使用这项技术，会引起很多不必要的纷争。说来惭愧，我这么多年还没有成功落地过这项技术。
除了学习方法外，我再分享几个在学习过程中让我颇受启发的点。
富含知识的模型容易造成上下文过载，导致认知困难，阻断知识提炼的循环。而角色对象通过将实体在不同上下文中的逻辑封装在不同的角色对象中，来解决上下文过载问题。进一步地，上下文对象通过显式地对上下文进行建模，将跨域业务逻辑和上下文依赖封装到领域对象中，以更彻底地解决上下文过载问题。这种基于角色封装不同业务逻辑的做法在开源系统中非常常见，Hive、HBase、HDSF 都是这种做法。
不过在业务系统中，大家似乎更习惯于使用贫血模型，将数据封装在实体中，将逻辑封装在领域服务中。所以《富含知识还是代码坏味道》这一讲，让我开始反思这种做法的合理性。
虽然使用贫血模型在业务需求变化迅速，追求短平快的大环境下，确实是比较现实的做法。然而很多时候，当我们达到业务目标后就放任这种松散的模型存在，很少再想着在这个基础上进一步提炼知识，那么这种惰性通常就会是系统腐化的开端。流水不腐，户枢不蠹。只有开启知识消化的循环，才能保证业务系统不会腐化。
记得第一次在我们组里分享DDD分层架构的时候，有位同学就非常敏锐地指出了这个分层的问题：基础设施层和领域层说是完全解耦的，实际上却完全依赖。我当时很认同他提出的这个问题，但也确实没法很好地予以解释。
而老师在第6讲直截了当地指出“基础设施不是层”，当真是醍醐灌顶！传统分层下领域层和基础设施层之间会产生“不正当”的依赖关系，破坏领域层的稳定性。那么通过基础设施层提取出具备业务含义的能力接口，并将其纳入到领域层，消除基础设施层；再将其转变为能力供应商，使其参与各层逻辑，就可以完美地解决这个问题了！
几个月前我换了团队，团队中的技术方和业务方在业务理解上存在巨大的鸿沟，业务方描述的需求，技术方很难马上理解到位；而技术方的模型对业务方也不够友好，很难将技术模型和业务需求对应起来。
于是我们团队日常工作中的绝大部分时间，都花费在了低效且劳神的沟通上，将缺少统一语言带来的问题展现得淋漓尽致，也使得统一语言成了我最近几个月感触最深的一个部分。
统一语言可以更加客观地还原业务团队内部技术方与业务方之间的生产关系，帮助清除双方有意无意创造的“隐秘的角落”，打破双方的边界，发挥彼此的创造性和能动性，为业务带来更多的可能性。统一语言是共识的沉淀，也是共识的开端，推动和构建统一语言，才能有效地沉淀领域知识，更快更好地完成业务目标。
然而，建立统一语言是困难的，需要技术方和业务方在“建立统一语言”这件事情上有共同的意愿，并有意识地进行协作。
不幸的是，繁重的业务目标如同达摩克利斯剑一样悬挂在整个业务团队上面，业务方和技术方都会把关注点放在业务目标这个结果上。业务方大佬说“我要业务结果”，技术方 Leader 振臂高呼“谁阻碍了业务就干谁”。双方的 Leader 虽然在“要完成业务目标”这一点上达成了一致，但却没人愿意坐下来，冷静分析造成团队当前效率低下的深层原因，更没有人愿意投入时间来引导团队各方有意识地沉淀和构建统一语言。
所以就像徐昊老师在评论区说的那样，建立统一语言，从把业务方和技术方叫到一间屋子里开始。
在第18讲，老师列举了微服务的9种特征，其中特别强调了两点，一个是服务按业务能力划分组织，一个是服务以产品而非项目进行研发。
忽略前一种，所谓的微服务就是分布式服务；忽略后一种，所谓的微服务就是微工作组。分布式服务是一种正常的模式，在很多业务团队是非常适用的。而微工作组这种模式就非常有问题，它增加了很多不必要的沟通，让服务之间在生命周期上紧密耦合，使得微服务丧失了意义。
实际上，分布式服务和微工作组这两种伪微服务的模式，我在之前的工作中都有接触过。课程中对这两种模式的总结，也跟我实际的工作体验完全一致。因而我也认同课程中所说的，产品化是解决微工作组模式的根本途径，真正的微服务团队很少需要与外部沟通。
此外，课程还批判了过分强调复用而放弃服务对业务能力封装的模式，并称之为“傻服务”。徐昊老师对这种模式的评价十分幽默诙谐，这里摘录一下：
当服务没有封装业务能力，而架构师又对复用充满雄心的时候，经常会出现傻服务。这不光服务傻，人也不太机灵。
总结来说，通过使用学到的理论知识来有意识地分析实际工作中碰到的、观察到的现象，很多困惑就都迎刃而解了，解决起来也更有方向了。同时，通过文字输出的方式来总结学习心得与体会，或者学完课程后在评论区留言提问，这个过程也是刻意练习的一部分，并且是颇有成效的。
这门课内容十分丰富，以上列举的是让我比较有感触的几个点，仅仅是课程中很少的一部分，并且也不是最核心的内容。
课程涵盖的范围很广也很有深度，值得细细咀嚼。其中传授的建模方法和技巧，还需要多一些刻意练习，将理论知识与平时的工作相结合，才能进一步领悟。长路漫漫，与各位同学共勉！
好了，我的分享就是这些。你在学习专栏的过程中，有没有什么学习方法和心路历程呢？欢迎你写在留言区，很期待能跟你进一步交流、讨论！