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