最近在找工作，深知自己没多少斤两，也只能苦刷八股文。不过在很多招聘的信息中看到了领域驱动设计这个关键词。刚好之前公司实践过这个，也许这个是可以在面试中吹吹的东西。于是乎就努力回想了下之前的经历，希望能整理出点有用的东西。
领域驱动设计，简称DDD，说它是设计思想也好，方法论也好，哲学也好，最后的目的就是让代码能更好反映业务，同时还能控制业务和系统的整体复杂度。其实吗，各种架构、模式、模型什么的，都是在控制复杂度，因为这些复杂就是生产效率的敌人。
以往，如果让我去梳理一个复杂的业务系统。我肯定在了解业务后，提供各种解决的技术方案，然后就是重构。等重构完，确实整个系统的代码会干净、整洁很多。讲得高大上一点，就是耦合度低了，内聚高了，接口设计更合理了，代码可读性也高了。可是当几个迭代版本后，就会发现，似乎有慢慢的回到之前的模样了。这里的两个重点就是，第一、我们的改造方案虽然是基于业务，但是更多还是基于技术角度思考；第二、我们的代码无法一直保持这个良好的状态。我们的工作就在迭代、重构、迭代，再重构的循环中。那如果不重构呢，对于那些还在高速增长的业务系统，忽视技术债务，最终也只会把开发拖入泥潭。
DDD的目标就是解决代码无法随业务模型同步调整的问题。通过维护一套领域模型，让代码随着这套模型一起演进。新的业务功能进入系统时候，需要先融入到这套模型中，才考虑代码的实现。
听上去，除了DDD理念中的统一语言、划分领域，以及一些花哨名词和概念外，并没有什么新花样。其实很多高级开发或架构师，都在做差不多的事情，分析业务，然后根据业务对系统架构和代码做调整。问题是，很多开发留下了最后系统调整的方案，却没有将分析业务的成果留存，或者留存了也没有在后续持续更新，更别说以业务模型作为开发设计的中心。DDD则在需求设计、业务分析、领域模型设计、代码实现等各阶段，提供了一套行之有效的方法。保证领域模型紧随业务变化，代码符合领域模型。
扯了那么多，还是谈谈之前的落地经历吧。说叫落地实践，实际就是摸着石头过河。翻遍了网上的资料，除了大牛那两本后后的书外，很难找到完整的落地方案。很多就介绍了个大概，也没有了啥后续。所以实践就变成了摸索。相对于战略设计，战术设计可能是开发最擅长的，只要在摸清业务，确定领域模型的前提下，战术设计完全可以有开发单方面完成。那战略设计就成为了实践中的重点。团队还是选择了事件风暴这种方式来分析业务。事实也证明“事件风暴”确实很有效果。从事件和用户旅程出发，能很快让开发了解完整的业务。同时挖掘业务流程中，一些不怎么被开发关注的内容。分析完成业务后，后续就是划分领域和上下文，以及模型设计等工作。这个过程也是反反复复的，毕竟对于复杂系统，很难一次性掌握。
DDD的好处，网上随便找一篇文章都能说出一堆来。只是对于落地的难处却说的比较少。我这里就说下过程中遇到的难点。
第一、领域专家难寻
DDD的要求就是和领域专家一起来梳理业务。我们团队刚好在一个比较传统的，或者说行业内业务很成熟的系统中实践DDD，加上公司确实有这方面资源，可以轻松和领域专家一起工作。同时开展DDD实践的另一个团队，那就没这么好运了。对于互联网行业，很多新兴的业务，都是靠着一群富有创新力的人才创造出来的。领域内并没有专家可以找，唯一对业务了解的恐怕就是产品经历了。这种情况下，分析业务就完全靠开发和产品自己对业务的理解了。还有就是领域专家是甲方的，也很难说动甲方参与设计和讨论，特别DDD的模式下，需要长期参与其中。
第二、老板或领导的意愿
很多领导或老板，脑袋一热，就要上DDD，可能并没有了解清楚。当时DDD实践是，就会无形中拖慢整个开发流程。毕竟，对核心业务的每一次调整，都要从需求开始，在业务层面梳理清楚。不像以往的上来就写代码的模式。那些头脑一热的领导，往往会被劝退。在没有上级的支持的情况下，DDD是很难维持的。特别处于长期工期紧张的团队。
第三、人才储备
系统不断的迭代，DDD也不是一锤子买卖。必须有人来负责管理，让团队可以持续进行。团队的其他成员也需要有能力，有意愿支持这种形式。特别是在工期压力大的团队，很可能团队选择逃避这种复杂的设计方式。这种情况下，核心成员的离开，很可能导致后续没有人能接手，从而放弃DDD。
第四、没标准，没最佳实践
网上很多都是说自己实践过，但是也没说持续多久，效果如何，哪些问题，怎么解决这些问题。更谈不上最佳实践了。而DDD本身是方法论、是思想，并没有对过程和产物做标准化定义，那不同团队设计出来的方案各不相同，这也导致了很多东西无法有效推广。
以上都是我个人的一点想法。本人经验有限，可能很多考虑不成熟的地方。