回顾
领域驱动是十五年前，由Eric Evans提出的解决软件工程复杂性问题的方法，作者从自己多年软件开发的角度出发，通过引入领域驱动设计的概念以及一系列战略设计模式和战术方法，为混沌的软件开发领域带来了一缕阳光。
在过去的许多年，我经历了从技术岗位到管理岗位的变化，也深深的意识到，每一个软件的设计与实施过程之艰辛，缺乏一些科学的管理方法，只会让人疲于奔命，毫无积累，尤其是对于开发过程而言，看似枯燥乏味的编码过程，却充满了更大的变数。
例如，在以前传统企业开发中设计系统架构时，往往会使用三层架构，用户界面层，业务层，数据访问层上手就来，但是却看似三层分立，但是由于开发者开发过程中出现的一些不规范问题，容易在用户界面层和数据层中堆积大量的冗余代码，而中间的业务层反而非常单薄，代码行很少，仅仅只是实现对象的输出而已。用户界面层和数据访问层就很容易成为腐化代码，随着需求的变更，容易变成大泥球系统。
尤其是那些核心模块的用户界面层代码，轻易就突破了上千行，甚至上万行，这些代码并非完全都是由于不规范的操作造成的，一定程度上也是由于个别开发者的代码不规范，形成的破窗效应。不管发生了什么，这些代码最终成为一座屎山。如果再加上古人写的存储过程，对不起，我选择自闭。
屎山的命运往往都是一样的，要么重构成功，得以逆天改命，要么被公司抛弃，成为企业发展过程中的一座重要里程碑，要么跟着公司一起，成为创业者的黄粱美梦。 是什么造成了屎山？是需求吗？
需求控制或不控制？
用户需求就像一个关在笼子里的狮子，控制或不控制，这是个问题。
对于互联网公司而言，一定程度上来说，需求来源于产品经理的灵感乍现，或来源于对竞品(被抄袭品)功能的把握，不同产品经理对于产品的规划总是不尽相同，以及老板和用户的反馈也是产品需求变化的原因，需求的累积也会让开发者为了修改而疲于奔命，而且面向互联网的产品往往比项目型软件成品面向更大的群体，拥有更长的生存周期，开发者为了应对需求而不节制的更改，容易成为试错，甚至会影响企业的生存。
所以使用领域驱动设计方法对后端的结构进行改造甚至中台化改造成为一种非常有效的解决方案，而对于面向用户的前台，以及为前台而生的BFF则由于更侧重于用户数据交互，而被排除于领域控制之外，(即 Backend For Frontend)（当然，过度的依赖前端表现层，也容易造成前端代码的冗余，事实上前端和客户端代码也最容易成为屎山，这是后话，就不赘述了。）
除互联网公司需要领域驱动的方法外，传统软件企业也同样需要，在企业发展过程中，积累的无数项目，大部分项目都存在一些普遍性的共性，那就是为了盲目追求实现，而忽略了软件代码的健壮性和可维护性，能否把功能强推下去，取决于项目经理对于甲方的控制力，一旦掌握优秀沟通技巧的关键岗位离职，这些项目都将成为一个个不知何时会爆发的地雷。软件企业项目的复杂性，有别于互联网企业的面对业务快速裂变带来的变化，往往更侧重于业务层面的规模复杂，一个系统的大几百个功能点，如何保证质量，时间，成本三者的平衡，这是个恒古不变的问题。
需求让软件充满变数、而规模、质量属性也同样会影响到软件的变化，要打破僵局，或许，领域驱动看似是一种不错的选择。
看似破解之道
然而，领域驱动的实践过程却充满坎坷，主要在于 Evans的原书，知识密度之稠，远甚于开发者热衷的技术话题。要解决某些技术问题，依托互联网的资源，或许能很快找到解决问题的方法，但是面对领域驱动设计，却让人望而生畏，许多人都说虽然听说这个概念的时间不在短暂，但是却总觉得没有入门。
单纯的从概念上看，引入的统一语言，领域存储库，实体，值对象，聚合根，限界上下文，上下文映射等名词，理解上似乎很容易，但是要付诸实践却并非易事。尤其还需要把这些东西引入到企业实战过程，更是难上加难。领域驱动设计方法，并不像那些技术书籍一般，拿着书上的方法，总能在自己公司找到可以实践的点。 Evans的书也好，其他书也好，都只是方法，而不是一套行之有效，马上就能使用的方案，需要团队花费大量时间去应用实践。
例如，一种最常见的领域驱动架构的实践是简单四层的领域驱动分层结构，在不能有效理解关注度分离的前提下，架构代码同样能成为屎山，而且似乎由于开发者知识传承的缺失，极其容易让人难以理解和更不用说代码质量的提升，只能成为倡导者实现个人价值提升的练兵场。
个人想法
我个人认为，领域驱动设计方法，作为一种解决复杂问题的应对之道，确实值得企业对其持续关注，但是否有一种能够便捷的方法，让参与者能够更快的将这么好的方法论在产品研发过程中融汇贯通，形成更高效的应用过程呢，下面是我根据一些讨论和学习过程，形成的一点思考，希望能给大家带来一丝启发。
1，如何开始改变企业文化？这是来自于《实例化需求》中提出的一个问题，作者的原意是认为要实践TDD，需要进行文化变革，事实上实践DDD或许同样如此。康威定律指出：一个组织拿出的技术方案设计，实际上是一个组织沟通方式的体现。你的组织真的准备好开始接受这种思想的考验了吗？这是个问题。
2、确保你得到管理层的支持。这也是来自于《实例化需求》中的原话，毫无疑问，如果缺乏管理层的认可和支持，过程变更成功的几率几乎为零。
3、忘掉敏捷、忘掉领域驱动、忘掉概念。由于领域驱动设计方法的看似晦涩难懂，容易让组织实践领域驱动的人陷入学院派或教条主义的误区，这表现在：组织者更倾向于使用专家给出的标准术语对领域驱动设计的方法进行解读而缺乏与企业实际相结合的形式。我个人认为，为了更好的推广领域驱动设计的应用过程，不应该局限于教条主义，不要过分关注于概念、框架或自动化的工具，而是把领域驱动设计过程，解释成一种发现需求、解释需求之间的相关性、收集实例、设计测试、以及形成可自解释的开发代码的过程。
4、从一个小项目和简单项目开始，探索建立一套行之有效的方法。从一个业务结构清晰、容易细分出应用场景和业务活动的项目出发，避免陷入大项目难以控制边界的过程，而且大项目如果没能更好的实施，只会一发不可收拾。有网友说，由于项目需求的极度不确定性，所以他觉得有必要引入领域驱动设计的方法来解决这个问题，我个人认为，这样的做法只会导致项目更加一发不可收拾，尤其是在一个学习能力并不好的组织中开展领域驱动设计实践、且大家都对这套理论一知半解的前提下。
5，从产品语言中提炼统一语言。axure软件的流行，让通过原型文档这种可视化需求表达成为主流。原型语言与需求的高度贴近，也便于产品研发团队从中形成统一语言。
6，形成可用的产品术语表。从统一语言出发，形成可以指导编程的术语表，并形成对应的中英文对照表，可以便捷的为开发过程提供变量命名的规则，尤其是许多开发者本身的英语水平就不是特别好，如果形成这样的规则，或许能为代码的开发过程带来许多便利。
7，从统一语言和需求中提炼用例图。按照张逸老师的说法，用例或用户故事应该满足6w特性，可以尝试站在用例的角度思考这样的问题：
- 到底谁是用户？需要执行这一活动的角色到底是谁？
- 为什么需要查询功能？
- 究竟要查询什么样的内容？
- 为什么需要了解分配给我的任务情况？
8，从用例图和业务流程中识别限界上下文。没必要一开始就采用四色建模法，采用比较简单的领域场景分析的用例分析方法进行分析，同样是不错的选择，例如从分析业务活动间的语义相关性，也是一种值得尝试的方法。
总结
人生三境界：看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水。大概技术领域也同样如此。
回到一个古老的问题，有人问：如何给一个变量命名，词穷了怎么办？专家的回答是，按领域驱动设计的方法对变量进行命名。这就是实践领域驱动设计的大师高论，已经到了看山还是山的地步。而普通开发者们，总是看了几篇领域驱动设计的文章，就会以为嗯，我遇到的这些问题，用领域驱动能解决，然后，就陷入一堆概念之中不可自拔。
实践是检验真理的唯一标准，唯有真的使用一个项目开始实践，才能真正体会领域驱动设计的精髓。领域驱动设计思想，是一种充满魅力的软件理论方法，然而要把这套理论真的用起来，依然需要经历一个从新手到高级新手，再到胜任者、精通者和专家的学习过程。本文也同样属于一位处于新手村学习者的个人见解，班门弄斧，期待能抛砖引玉，措辞多有不当，还望海涵。
参考资料：1、Eric Evans《领域驱动设计·软件核心复杂性应对之道》
2、张逸 《GitChat讲座：领域驱动设计实战》
3、Gojko Adzic《实例化需求》
ps:我本不想打广告，不过我觉得张逸老师的课程确实讲得挺不错的，有兴趣可以关注一下。
