DDD的思考（一）

DDD-Domain-Driven Design 领域驱动设计。软件核心复杂性的应对之道。

领域：不同的业务方向都算是一个领域，比如Java,软件。在具体的项目上电商项目，库存算是一个领域，订单算是一个领域。

DDD这种概念早在2004年Eric Evans就提出了，多年来一直不温不火，直到微服务架构的逐渐成熟才开始走进大家的视野。

随着微服务项目的复杂度和技术增加，MVC这种传统的自顶向下的分层架构已经不足以治理和维护项目了。这个时候急需要一种大型微服务项目落地的方法论，DDD就出现了。

但是DDD只是一种很抽象的方法论，它并不像微服务的那些技术一样拿过来就可以使用，它在项目上使用，就需要按照这种方法论进行落地。

所以它的发展目前并不顺畅，有些人并不认可它，有些人却认为它是未来微服务的发展趋势，在落地过程中，很多项目做着做着就走形了。DDD的现状变成一百个人眼中有一百个DDD的落地实现方法。

关于DDD的思考？

如何提升软件质量。

我们在不同的业务可能使用了不同的技术方法，我们把技术方法整理成技术框架，希望在不同的业务场景都可以使用。

1）在单体架构时代，我们更注重封装。

2）在微服务时代，我们更注重封装，扩展之间的平衡。

但是在这种时代下，无论使用什么技术，我们对业务的理解，永远无法跟上业务的变化。一个复杂多变的业务经过若干次的迭代和人员的变更，复杂多变的业务足以摧毁前期任何的设计模型。

某次迭代中留下的隐患在以后的开发中就会变成滚雪球，将整个项目拖向泥潭。

3)后微服务时代，业务复杂，技术爆炸，敏捷当道，又如何保证软件开发质量呢。

4）项目长期迭代，如何保证软件质量不退化

举个栗子： 

电商商品详情页面来说，商品展示的内容一般变动是比较小的，可能前期做了一些措施，比如页面静态化处理，但是在项目使用了一段时间之后，可能加了一些新的需求，比如秒杀，团购，套餐，满减，活动，预售等等。这些都或多或少的影响到这个页面的展示，只要在某个迭代中某个开发人员打破了之前设计的静态页面的设计，比如页面发起了ajxa请求，那么后面的迭代就像滚雪球一样，会把这个页面的性能越拖越差。

就算对它做重构，对于客户方来说肯定不想花费人力来做的，他们只关心功能。如果一开始使用DDD,领域驱动设计，把复杂业务描绘成领域模型，用领域模型指导语言开发，这样业务的变化就能快速的映射到领域模型上，通过领域模型的指导就能以较低的成本推动项目向前迭代。这些对于越来越长的生命周期的项目来说是至关重要的。比如页面的这些变化都对应领域对象模型的一些行为。

微服务中就算把业务拆开了一个个小的模块作为单独的服务，并没有从本质上解决这个问题，只是单纯的把这个问题出现的时间向后推移了。然后也把问题推到了某个微服务里。

微服务其实也会面临一些问题：

微服务如何拆分。如果把微服务做到高内聚，低耦合。项目持续时间长，业务变更频繁，如何保证项目质量？如何控制微服务项目的成本？