百家之言，源自网络，好文共赏。
软件系统的核心只有两个：领域和算法。
在 Hacker News 上获得接近 500 个点赞的一篇名为《停止学习框架》的文章称：
我们是程序员，每天都在了解最新的技术，每天都在学习编程语言、框架和库，因为我们知道的现代编程工具越多越好，对吧？
不停地追随 Angular、React、Vue、Riot、Ember、Knockout 的脚步还真是一件有意思的事情呢。（译注：反话）但这其实是在浪费时间！
时间是人类最宝贵的资源。时间是有限的、不可再生的，你可以用钱买任何东西，却买不了时间。技术，就像时尚，在以光速在变化着。为了赶上它，我们需要跑的非常快。但是这个跑道上没有终点，所以没有赢家。
将你的黄金时间用于学习通用技能，那些不会过时的技能。
-
不要学习微服务框架，学习演进式架构（Evolutionary Architecture）。
-
不要学习新的编程语言，学习代码整洁之道、设计模式、领域驱动设计（DDD）。
-
不要学习 LeSS 和规模化敏捷框架（SAFe），学习精益生产原则。
-
不要学习 Hystrix，学习容错模式。
-
不要学习 Docker，学成持续交付。
-
不要学习 Angular、React 和 Vue，学习 Web、HTTP 和 REST。
为什么要使用领域驱动设计？
从Eric Evans的《领域驱动设计：软件核心复杂性应对之道》一书的书名就可以看出这一方法论是为了解决软件核心复杂性的。也就是说软件业务越来越复杂了，领域驱动设计可以让事情变得简单。而实际情况是：领域驱动设计的门槛很高，没有很深厚的面向对象编码能力几乎不可能实践成功。
这一说法是否自相矛盾呢？Martin Fowler在PoEAA一书中给了一个有力的解释：
我们把三层架构等除了领域驱动之外的架构方式都可以归纳为以数据为中心的架构方式，在图中是黑色的粗实线；领域驱动设计在图中是绿色的粗实线。
- 当软件在开发初期，以数据驱动的架构方式非常容易上手，但是随着业务的增长和项目的推进，软件开发和维护难度急剧升高。
- 领域驱动设计则在项目初期就处在一个比较难以上手的位置，但是随着业务的增长和项目的推进，软件开发和维护难度平滑上升。
这幅图形象的解释了领域驱动设计和传统的软件架构模式两者在软件开发过程中解决复杂性之间的差异。
领域驱动设计的核心是什么？
战略设计：
说到战略设计，我们要站在一个比较高的视角来看待这个问题，战略设计要解决的就是某个领域的问题，所以战略设计时，我们要构建好领域模型，保证我们的大方向是不会错的
战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。
以数据为中心的架构模式
战术设计 :战术设计则是要求我们从业务模型转向微服务落地 我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行绑定。当我们去响应业务变化调整业务架构和领域模型时，系统架构也会同时发生调整，并同步建立新的映射关系。也有演进式架构的含义在里面。
说到这里，大家可能对DDD有了一个粗略的，大体的认识，我们可以理解到，DDD能够帮助我们更好的在微服务的架构中进行合理的拆分，由于DDD要求我们建立标准的业务领域模型，所以DDD也能够很好地帮助我们设计企业的中台,DDD是一把利器，帮助我们解决架构中遇到的问题和挑战。
领域模型
DDD的优势及未来
DDD是一套完整而系统的设计方法，并非一种架构。它能带给你从战略设计到战术设计的标准设计过程，使得你的设计思路能够更加清晰，设计过程更加规范，有助于提高技术人的架构设计能力。无论是在新项目中设计微服务，还是将系统从单体架构演进到微服务，DDD 都大有助力。
倘若能一直保持DDD的开放性，保持DDD的独立性，我觉得在未来的五年乃至十年，DDD仍将焕发生命力，只是它的面貌会更加多姿多彩，甚至超过Eric Evans对DDD的原初定义。毕竟，软件系统的核心只有两个：领域和算法。