在过去的两星期里，一直在尝试了解如何从头开始设计一个系统的构架。虽然过去的那些岁月里，做过一些小的系统、小的软件，也尝试性的做过一些架构的设计。但是毕竟都是比较简单的系统，没有设计过一些复杂点的案例。暂时看不到有趣的新技术的出现，想着深入一些系统思想的同时，也想着自己设计一个复杂点的系统，然后实现。

架构设计初控

重新翻阅了一下一些架构设计的书，渐渐地发现之前的兴趣广泛对于思考架构设计，看上去似乎很有利，除了经验不足。经验不足说的是:

1. 没有深入思考一此复杂的架构
2. 接触的项目不够多(好的坏的都会成长的)
3. 没有设计过复杂点的系统

总论就是: 了解更多的开源系统的架构。这一类的书很多，如AOSA。还有，这一类的一些书在很大部分都是在瞎扯——多说无益。

让我们focus一下我们要做的事件：

1. 需求
2. 建模
3. 架构
4. 实现

理论上一个架构是不应该变化的。在一个不断不变化的时代，外加需求总会不断变化的，但是总有那么几种东西不会变化那么快:

1. 模式系统
2. 领域知识

其实，我想说的是那些东西可以借鉴现有的系统。更广泛地知识对于设计一个系统是有好处的，除此我们还需要了解更多的细节知识，如深入

• 设计模式
• 领域驱动设计
• 模式系统
• 设计原则
• 领域特定语言

等等。

在我们完成上面那些之后，我们就完成了系统二——一个无比臃肿的系统。接着我们就可以考虑对这个系统进行裁剪，做到不多不少的设计。

其他

微服务 & 宏服务

当然，我们不会讨论到微服务架构这种适合于大企业的架构blabla，毕竟在之前的文章中我们已经讨论过多次。而且，它的实质和我们之前看到的MicroKernel和Monolithic kernel没有太大的区别，最终Linux不还是用的宏内核，但是借鉴了微内核的思想。在这里，我们并没有说MicroServices不好，相反地对于复杂的系统还是应该用MicroKernel的思想，毕竟大企业是团队模块分工的。但是，对于自己设计一个系统来说，我们也是要借用微服务的一些思想啦~~。

其他

ps: 上面都是瞎扯，最主要的是实战。

架构设计是要敏捷的。

不敏捷的话怎么拥抱变化。