迷途书童

就现阶段而言，DDD已经成为微服务设计的事实标准，也不排除未来可能是有更好的微服务设计标准。
这篇文章聚焦于传统的架构应该如何过渡到微服务架构。

• 传统三层架构
• 传统的DDD分层架构
• 依赖倒置的DDD分层架构
• DDD 五层架构
• DDD 六层架构
• 六边形架构
• 整洁架构-洋葱模型

一个系统能发展是有动力，如果要让系统发展的好则需要约束。就好像汽车的前进是靠发动机，汽车的减速靠的是刹车，汽车行进的方向靠的是方向盘。发动机是动力，刹车和方向盘是约束.
那么动力和约束与生活有什么关系呢？ 让我们从直觉和感性的角度来一场探索之旅吧

• 系统的动力
• 系统的约束
• 约束和动力之间的关系

现在谈到微服务，大多会提到DDD, 这两者之间有什么关系呢？让我在这篇文章里揭秘吧.

• DDD是什么？
• DDD设计的一些原则?
• 如何基于DDD实现一个服务?
• DDD的反面是什么？

DDD 是什么？

DDD(Domain Driven Design)是一种设计方法论，它提供了一种拆解知识和问题的方式.

DDD的背景

2004年Eric Evans 出版了《领域驱动设计》。微服务发迹于2014年。但这10年间DDD可以说是默默无闻，就好像一个妃子被打入冷宫一样，直到微服务出现，两者才喜结良缘，很难说谁成就了谁，两者是如此的契合.

微服务已经成为了后端开发的主流，也成为了后端初次见面打招呼的内容.
微服务三个字从这字面上可以理解，但它的内涵确实是各人有各人的理解，因为微服务本身并没有被严格的定义.噢，不， 它有被定义，只是在不同的时间段被不同的权威的人定义了，据可查的资料，大概有4位专家前后给出了不同的定义，所以大家都不知道真正的定义是什么了， 也不知道未来微服务的定义会变成什么样. 因为它没有像数学公式被严格的定义。

这篇文章不试图搞清楚微服务的确切含义是什么，因为这这样做是徒劳无功的。
本文试图探索

• 微服务大概是什么？
• 为什么是微服务？
• 要实现一个微服务，它应该具备哪些行为和特征？
• 微服务的未来
• 微服务带来的副作用

基本上，一说到react, 正常会有一个词随之而出现，那就是Redux. 它们是一对好基友。
这篇文章主要是聊聊下面一些话题

• 什么是Redux?
• 为什么是Redux?
• React和Redux的关系是什么？
• Redux的未来

什么是Redux?

Redux是一个存储数据的地方，这个地方你可以叫它为Store,或者JS对象，或者前端数据库，这些都是名，实际的内涵是存储数据.
既然是存储数据的地方， 那么接下来有几个问题就很自然了

• 数据有哪些实体？
• 数据的实体有哪些行为？ 增，删，改，查。
• 有哪些方式能获得这些数据？
• 如何避免不同的实体有相同的冗余数据？
  阅读全文 »

React作为前端主流的UI库，逐渐占据了前端的大半壁江山。所以哪个前端如果不知道React， 那基本上可以算是大大的落伍了.
在这里，主要聊聊

• 什么是React?
• 为什么是React?
• React是如何实现的？
• React的未来

什么是React?

React是一个UI库，所以 React的核心定位和使命是解决UI的问题.
传统意义上操作UI的做法是:

• 触发一个行为
• 以某种方式获取DOM
• 以某种方式更新DOM

分解是解决问题的一种有效方式之一。分解这两个字是如此的显而易见，小学生一听都知道分解是什么意思， 以至于不需要解释太多。
这篇文章主要探讨三方面内容

• 什么是分解？
• 为什么要分解？
• 如何分解一个系统？

什么是分解？

将一个事物按层次拆成层次1， 层次2，每个层次可以拆成要素1， 要素2，这就是分解。

网络上有一副有名的图片，形象的描述了数据，信息，知识，智慧的大体关系.

下面简单的谈谈我对这幅图片的个人理解.

• 数据
• 信息
• 知识
• 智慧

一般来说， 当我们说到前端， 往往是说Web端， 在某些公司， 有大前端的概念， 包括移动端.
整个前端发展史可以分为

• 农耕时期
• 工业化时期
• 信息化时期
• 智能时期

在设计软件模块的时候， 我们往往会遵循一些原则， 这些原则五花八门，有的是来自于面向对象领域， 有的是来自于纯设计领域。 有些原则在某些场景下会不灵光。 这篇文章主要就是聊聊这些原则。
在这里， 我将软件设计原则分为三类。

• 总的原则
• 通用的原则
• 特殊的原则