一拍即合
上一篇《.Net微服务实战之技术选型篇》，从技术选型角度讲解了微服务实施的中间件的选择与协作，工欲善其事，必先利其器，中间件的选择是作为微服务的基础与开始，也希望给一直想在.Net入门微服务的同行有一个很好的方向。
在此篇重新整理了一下整个微服务项目的demo，希望对有需要的朋友起到一定的帮助：https://github.com/SkyChenSky/Sikiro
那么我在公司实施微服务的时候，也不是一拍脑袋想上就上的。刚入职公司的时候才3、4个人，产品给到我的规划只有一个很简单的系统
包含权限、客服IM、内容管理三个模块，我当时想着优先证明我们的开发能力和效率，于是使用简单的单体架构不到三个星期项目就完成了。产品在我们开发的期间把整个项目的规划和平台系统的划分给梳理了一遍
终于让我有一个很明确的技术实施方向，同时公司的人力成本预算也批了下来开始进行团队扩招。
于是我与老领导商量了一下，在现在这个情况，无论业务还是团队都具有使用微服务架构的可操作性，再采用部分DevOps的思想给与微服务实施的支持，能顺利的实施落地微服务问题不大。
我们俩讨论了一番，我有良好的微服务技术储备，他有很好的运维支撑，就这样咱两达成了共识。
于是我着手翻出了收藏已久的微服务中间件、架构分层、服务拆分的资料，从此开始了我的微服务实施之路。
PS:我们讨论实施微服务的时候除了以上冠冕堂皇的理由之外，其实还存有一点私心，就是现在企业招聘很多需要有实施微服务经验的人才，但是80%的项目和同行又是没有这样的实施必要与经验，这就是鸡生蛋和蛋生鸡的问题。
我毫无隐瞒的说出我们的私心并不是怂恿大家冒着风险去实施，而是希望大家通过分析现在团队的组织架构、技术储备、业务架构，在条件允许的情况下满足您的小小要求，微服务虽不是银弹，但我们也需要成长。
架构思维
抽象是作为架构思维的核心，使我们站在大局观察，屏蔽细节；这系统划分哪几个模块？模块之间的如何协作的？抽象又可以衍生出两种思想划分与协作。
划分的目的是为了定责与拆分，定责不是交通事故的定责而是划定职责，明确模块的使用场景，应该被什么依赖？应该依赖什么？拆分其实就是分而治之的思想，把一个复杂的大问题拆分成一个个简单而小的问题，化繁为简逐个击破自然就迎刃而解。
协作的目的是整合划分好的模块，被拆分的模块如果无法整合到一起，拆分则失去了他原有的意义。
不谋而合
技术服务于架构，架构服务于业务，业务服务于商务。所以有明确的业务蓝图才可以很好的规划架构方向；选择好合适的技术才能很好的支撑架构。
此时我们开始着手实施微服务，然而在实施时我们还会考虑一个比较核心点，究竟如何微？粒度究竟到什么程度？怎么明确依赖关系？大家或多或少都会听说身边同行有实施微服务的失败案例：拆分粒度过细导致系统复杂度过高；拆分粒度太粗又没达到微服务该有的效果等。
那么是否在业界有一套科学的指导方法论？我认为是有的，DDD战略设计与分层架构。
埃里克、埃文斯在2004年发表了《领域驱动设计》一书的，此后一直是雷声大雨点小，在2014年软件教父马丁花给微服务一个全面描述，让它走向一个高潮后，DDD终于赢来了他的春天。
为什么说DDD适合微服务呢？DDD是一种通过划分业务边界，将复杂的业务领域简单化的设计思想，也就是化繁为简。为什么在上文重点强调DDD战略设计？DDD分为战略设计与战术设计。
战略设计
主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的界限上下文，界限上下文可以作为微服务设计的参考边界。
战术设计
主要从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，例如我们常讨论的聚合根、实体、值对象、领域服务等代码逻辑的设计与实现。
从以上两点的描述可以看出，战略设计从业务视角出发，而架构服务于业务，两者都需要从业务出发，DDD战略设计与微服务都有同样的设计思想：分而治之、化繁为简，那么战略设计的思想完全可以作为微服务架构设计的指导思想，此时此刻此场景不谋而合。
分层&切割
也可以叫N层架构（N>=2），其实本质在于划分职责、隔离关注点，保证各层之间的差异足够清晰，边界足够明显，其特点自顶向下依赖，逐层传递。
