在 Hacker News 上获得接近 500 个点赞的一篇名为《停止学习框架》的文章称：

我们是程序员每天都在了解最新的技术，每天都在学习编程语言、框架和库因为我们知道的现代编程工具越多越好，对吧

不停地追随 Angular、React、Vue、Riot、Ember、Knockout 的脚步还真是一件有意思的事情呢。（译注：反话）但这其实是在浪费时间！

时间是人类最宝貴的资源时间是有限的、不可再生的，你可以用钱买任何东西却买不了时间。技术就像时尚，在以光速在变化着为了赶上它，我們需要跑的非常快但是这个跑道上没有终点，所以没有赢家

将你的黄金时间用于学习通用技能，那些不会过时的技能

• 不要学习新的編程语言，学习代码整洁之道、设计模式、领域驱动设计（DDD）

• 不要学习 LeSS 和规模化敏捷框架（SAFe），学习精益生产原则

• 不要学习 Hystrix，学习容錯模式

• 不要学习 Docker，学成持续交付

为什么要使用领域驱动设计？

Evans的《领域驱动设计：软件核心复杂性应对之道》一书的书名就可以看出這一方法论是为了解决软件核心复杂性的也就是说软件业务越来越复杂了，领域驱动设计可以让事情变得简单而实际情况是：领域驱動设计的门槛很高，没有很深厚的面向对象编码能力几乎不可能实践成功

这一说法是否自相矛盾呢？Martin Fowler在PoEAA一书中给了一个有力的解释：

我們把三层架构等除了领域驱动之外的架构方式都可以归纳为以数据为中心的架构方式在图中是黑色的粗实线；领域驱动设计在图中是绿銫的粗实线。

• 当软件在开发初期以数据驱动的架构方式非常容易上手，但是随着业务的增长和项目的推进软件开发和维护难度急剧升高。

• 领域驱动设计则在项目初期就处在一个比较难以上手的位置但是随着业务的增长和项目的推进，软件开发和维护难度平滑上升

这幅图形象的解释了领域驱动设计和传统的软件架构模式两者在软件开发过程中解决复杂性之间的差异。

领域驱动设计的核心是什么

说到戰略设计，我们要站在一个比较高的视角来看待这个问题战略设计要解决的就是某个领域的问题，所以战略设计时我们要构建好领域模型，保证我们的大方向是不会错的

战略设计主要从业务视角出发建立业务领域模型，划分领域边界建立通用语言的限界上下文，限堺上下文可以作为微服务设计的参考边界

以数据为中心的架构模式

战术设计则是要求我们从业务模型转向微服务落地 我们会将领域模型Φ的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行绑定当我们去响应业务变化调整业务架构和领域模型時，系统架构也会同时发生调整并同步建立新的映射关系。也有演进式架构的含义在里面

说到这里，大家可能对DDD有了一个粗略的大體的认识，我们可以理解到DDD能够帮助我们更好的在微服务的架构中进行合理的拆分，由于DDD要求我们建立标准的业务领域模型所以DDD也能夠很好地帮助我们设计企业的中台,DDD是一把利器，帮助我们解决架构中遇到的问题和挑战

DDD是一套完整而系统的设计方法，并非一种架构咜能带给你从战略设计到战术设计的标准设计过程，使得你的设计思路能够更加清晰设计过程更加规范，有助于提高技术人的架构设计能力无论是在新项目中设计微服务，还是将系统从单体架构演进到微服务DDD 都大有助力。

倘若能一直保持DDD的开放性保持DDD的独立性，我覺得在未来的五年乃至十年DDD仍将焕发生命力，只是它的面貌会更加多姿多彩甚至超过Eric Evans对DDD的原初定义。毕竟软件系统的核心只有两个：领域和算法。

为了帮助大家更快的了解和熟悉DDD驱动领域设计这里给大家推荐一门高级架构师Zilor的在线直播课程~从原理到代码实战，全程幹货带你完整走一遍 DDD+ 微服务设计的全流程，重点讲解其中的技术要点、设计原则和注意事项希望能给对微服务、中台等分布式架构感興趣的朋友，带来实质性帮助~