正儿八经 - 资深软件工程师

在看《少有人走的路：心智成熟的旅程》这本书之前，从来没细究自律的概念，就觉得自律就是自我约束，比如一天50个俯卧撑，不能因为某天朋友叫打游戏就把这50个省了，一定得做。这就是我理解的自律，但是看了《少有人走的路》之后，书中对自律的定义，我觉得我还是太年轻了，想的太粗糙。首先这本书正文没开始之前就说了，每个人或多或少的心里都有病，只是轻重和早晚不同而已。

如果从规避、逃避问题就是人类心理疾病的根源这个点来讲的话我是认同的，至少我没发现我也不认为，这个社会上存在有人是从来没有规避和逃避过问题的。所以如果你承认自己有这样的问题，那你还是看看这本书吧，以下是我的一些摘抄，算不上笔记。

首先要想心智走向成熟，你得学会自律。

自律是解决人生问题最主要的工具，也是消除人生痛苦最重要的方法

首先什么是自律？

所谓自律，就是主动要求自己以积极的态度去承受痛苦，解决问题。

自律有四个原则：推迟满足感、承担责任、忠于事实、保持平衡

• 推迟满足感

  不贪图暂时的安逸，先苦后甜，重新设置人生快乐与痛苦的次序：首先，面对问题并感受痛苦;然后，解决问题并享受更大的快乐。在充满问题和痛苦的人生中，推迟满足感是唯一可行的生活方式。

对于这个点我是深有体会的，我妈从小就教育我，先苦后甜，所以小的时候特别想早点长大，因为太穷了生活也太痛苦了，觉得长大了应该就是甜了，当然事实是脸被打的piapia的。现在想想其实小时候的想法不就是为了逃避问题么。所以其实所谓的先苦后甜，指的不是时间的先后，而是解决问题之前和之后。所以核心在于你得面对问题并解决它才有所谓的先苦后甜。不过要注意：解决问题缺乏耐心、想让问题马上解决这样的态度是不切实际的。另外根据破坏性的是希望问题自行消失，这显然是自欺欺人，问题永远都在，如果不解决它将阻碍你心智的成熟。所以唯一能做的时直面问题，并尽可能早的面对问题。

• 承担责任

  这是我的问题要由我来解决。力图把责任推给别人或组织，就意味着我们甘愿处于附属地位，把自由和权力拱手交给命运、社会、政府、独裁者和上司。

这一点我认为是比较重要的一点，承担责任对于我，稍微值得高兴的是，我一直在努力学会承担责任并做到不逃避责任，当然这样的选择对自已是相当痛苦的。因为你会发现在如今的社会，你所在的圈子，有越来越多人的在想办法规避或者逃避责任，为什么？因为他们不愿意承担不想承担。因为承担可能就代表着认输，代表着损失，代表着受虐。所以你可以想象如果你选择了不逃避责任可能不仅仅是你承担一些痛苦，可能还会招来白眼、孤立….。所以我觉得大多数国人的生活质量是上来了一些但是心智成熟方面还是有很大的提升空间。不过我还是想说自己的问题自己解决，勇于承担该承担的责任最起码你会让自己看上去没那么逗比和拙劣。

• 忠于事实

  我们要实事求是，越是了解实事处理问题就越得心应手，对事实了解的越少，思维就越是混乱。

  我们对现实的观念就像是一张地图，凭借着这张地图我们才能了解人生的地形、地貌、和沟壑，指引自己的道路。如果地图准确我们就知道自己的位置也知道要到什么地方，以及怎样到达；如果地图失真，漏洞百出，我们就会迷失方向。所以我们需要让自己的地图足够准确足够完整，怎么做呢？努力程度越高地图会越大越完整，对事实认知的更加清楚，准确性就会更高。

其实这一部分还提到一个概念叫移情，这个移情可不是移情别恋的移情，书中对其的说明我大概的传递一下：一个人把年幼时对世界的感知以及对世界作出的反应方式，照搬到成年后的环境中，虽然这些方式已经不再适用于新的环境。我觉得通俗点说就是活在自己的世界逃避现实，对外界的变化视而不见听而不闻。这样的人是拒绝更新自己的地图的，那当然就会经常迷路。所以可以看出面对现实不像想象的那么简单，现如今又有多少人愿意面对现实，忠于事实，并迎接挑战呢？迎接挑战是唯一能确定我们的地图是否与事实符合的方法。埋头刷抖音刷头条，各种交友软件各种游戏中各种直播中扮演着牛逼哄哄的样子，沉迷于虚假的舒适中，不想奋斗不想上班不想努力，一问他会有一堆的原因，买不起房，政府没用，没有技术等等，那你都知道这么多问题围绕着你了，你他么还不想办法解决，在等什么呢？等着被抛弃被奴役？

要想在组织或集体中发挥大的作用，就要注重表达意见的时间、场合和方式。换句话说，一个人应该有选择的表达意见和想法

• 保持平衡

  这一条其实更多是教我们怎么基于前面几条讲的做到自律，即自律本身就是把持得当。

这一点没什么好说的，说白了主要还是自己把握好度，比如对待生气的事情，什么情况下改表现出发怒，什么情况下改表现出隐忍…..
文中有一小节讲到放弃与新生，要学会必须放弃旧的、过时的观念和习惯诸如生活环境、个人欲望、处世态度这样的东西，才能得到心智的成熟，才能获得新生。说的有点玄，不过确实是如果你始终执念于你的某些过时的观念或者习惯，容易让自己以及周边的人陷入痛苦。因为这意味着你不想放弃，哪怕那是不好的，这往往会为自己以及周边人带来痛苦或者伤害。所以需要学会在不同的人生阶段放弃某些东西，比如身为父母的阶段，要学会放弃父母的权威等。最终你获得的永远比放弃的多。

书中的部分句子

“我是个有价值的人”-像这样对自我价值的认可，是心里健康的基本前提，也是培养自律的根基。对自我价值的认可是自律的基础，因为当一个人觉得自己很有价值时，就会采取一切必要的措施来照顾自己。自律是自我的照顾，自我珍惜，而不是自暴自弃。

自律能让我们承受问题带来的痛苦，并最终解决问题。

你不能解决问题，你就会成为问题。

*为了躲开责任带来的痛苦，数不清的人甘愿放弃权力，实则是在逃避自由 - 《逃避自由》 *

这段时间被“中美贸易战”的各种文章和声音吵得恶心，不知道为毛那么多喊麦式的文章后面还有那么多跟着喊麦的吃瓜群众，那么没有营养的内容一个个读的陶醉不已，不得不感叹现如今信息传播的可怕。我看了篇说实话的文章，结合着那篇文章我也在这儿发表发表比较粗犷的感言。

醒醒吧，我其实搞不懂，中国人哪来那么深厚的底气，觉得自己哪哪都是牛x的，谁都干不过，后来经过中美贸易战这段时间，我大概知道，各种所谓的大V、自媒体、甚至所谓的官媒，都他么传递着各种鸡汤、各种所谓的正能量、各种吹嘘、各种爱国情怀、各种川普吓得尿裤子….。一遍又一遍一波又一波的洗脑着咱们老百姓，这种就是典型的误人子弟，害人害己，关键是老百姓也爱信也爱看啊。中兴那么明显的例子，大家都装作看不到。平时营收上百亿上千亿的企业，人就跟你断个芯片啥的，你就歇菜了，典型的外强中干，这应该让国人意识到，我们与美国在高新技术领域的差距还是比较明显的，当然如果再给个10来年，可能就赶上了，但是人美国不干啊，为什么这个时候弄你，因为他们顿悟了啊，发现被中国忽忽悠悠的就改革开放了40年，再不下手弄就真的弄不动了。

去看看中美的贸易额你就知道，很明显的中国对美国的依赖更强，如果真的继续干下去，大家都等着勒紧裤腰带过日子吧。继续干下去，受伤的都是老百姓。当然美国也会有损失但是相较而言，中国是更吃亏的。所以求那些所谓的各种扯淡大V之流，别他么再瞎歪歪挣流量了，坐下来静静的想想怎么让国人能对自己的国家有更准确的认知。我也希望我们老百姓能有时间看看一些国外的报道，以及国内有正经背景的经济学家、社会学家等发表的文章或者演讲、采访等，少他么花时间在抖音啊、今日头条等App上。

我之前看王煜全先生的一个采访，我觉得他说的挺有道理，主要内容是：中美贸易战实际就是你打我一拳我踢你一脚，如果不想办法解决问题，最后就会变成互殴，这样又受伤（受伤最多的还是老百姓）又解决不了问题。正确的解决方式是，找到问题的解决办法。为什么美国会出手，很明显是不满是抱怨中国不地道嘛，那咱们就坐下来好好谈谈，怎么滴能解他的怨气嘛。或者委婉点，川普不是代表工人阶级嘛，美国不是就是就业问题很严重吗，那咱们中国政府牵头推一批一批的企业去美国建厂提供就业嘛，我们就是在国外建的厂太少了，所以影响力太小，你想想如果我们在美国早早建立了很多企业，提供了大批就业，川普还敢通过现在的方式弄我们么？还没出手，估计国内就一波波游行示威了。别不信，中国很多企业是有能力在美国建厂的，只是缺少经验，同时缺少政府的支持。比如曹德旺先生就是比较成功的例子。

其实你看那小日本为啥那么恬不知耻的跟着美国，毫无节操，地地道道的狗腿子，因为人家知道美国能弄它，而且他禁不住弄。当然我们不需要像日本那样，而且也不会也不能像日本那样。我们有底气啊，有人，有地盘，有一大堆钱砸出来的黑哥们，有党，有钱，某些方面还是有技术的。所以不需要像日本一样。但是我们得有自己的认知，不天天一副无敌是多么寂寞的样子，老祖宗几千年传下来的，我们要谦虚，谦虚使人进步。

本文纯属扯淡，随便看看。

前段时间读了《乔布斯传》这本书，一是因为好奇这个人，二是因为想了解下苹果的历史。不得不承认，苹果的产品应该是目前世界上最好用的产品之一，至少我是这么认为的。

这本书看的过程中其实会觉得有些无聊，不是说书不好，基本上都是源于个人的原因，一个可能是本身我不是乔布斯的信徒，再一个是因为看这本书会对我有一种局限，局限来源于从小到大接触的教育、社会环境、人文环境等有关，读了该书，我就有种感觉如果乔布斯或者是书中提及的与乔布斯有交集的一部分人，如果生在中国。我估计绝对会首先被贴上一个问题少年、怪胎等标签，然后遭受各种来自老师、同学、亲戚朋友等的白眼，大家根本不会看到或者不会在意他们身上的闪光点或者天赋，早就把他们扼杀的不能再扼杀了。当然这是我的个人见解不代表广大群众，下面简单的记录一下这本书带给我的感悟。

拿取

从书中能拿取到对我有启发的如下：

1. 专注

   乔帮主以及他招揽的那帮人，那种对自己所做的事的那种专注，真的是你从字里行间都能感受到强大的力量，专注到最后就是成功。所以你自己选择了你现在做的事，那就保持专注吧，至少你提高了成功的机率。

   这个点是我需要提升的，我只好码代码时最专注的，其它事情好像都容易走神，所以我现在都在自我训练。
   自己每天定个目标列表，必须完成，在有限的时间，你不专注根本完不成，完不成，你看到你的目标全是没划掉的那种感觉很憋屈。

2. 现实扭曲立场

   说的通俗点我觉得是一种感染力、一种吸引力，他就像太阳一样，不但发光发热而且你不自觉的还得围绕着他转，他会让你相信他并跟着他干。其实在书中这个“现实扭曲立场”这个词语不一定就是褒义的，有的人就比较反感，因为他们有时候会感觉一种压迫感。我们事业部的ceo在我看来就是有点“现实扭曲立场”的感觉，总是自信并能感染人，给人一种力量。我希望今后我也能给人一种感染力和自信，那其实是挺美好的一件事。

3. 简单

   这个对我们这行的来说，其实这个一直是我们的最大的追求，我们现在所做的一切努力都是为了让事情变得更简单，能更快响应外界的变化。乔帮主一直在追求这样一种极致的简，为此付出了多少人力物力都不管。所以很多时候面临问题时，你得想办法把他简单化，复杂化其实很简单但是最后很痛苦，简单化他很难但是很舒畅。

   特别是在我们工作中往往都会让问题变得越来越复杂化，其实我们停下来，静静思考一下，分析清楚利害关系，往往有个更简单的解法。

4. 营销

   从书中你会发现其实乔帮主真的时一位营销专家或者叫产品推广专家，每次发布的产品，文案、发布会都会亲自参与，对产品你说他吹毛求疵都忍了，一个广告方案他也能吹毛求疵。当然最终的结果大家应该印象都很深，苹果的广告用美轮美奂、创意十足…等词语来形容都不过分。包括苹果的发布会的造势、发布会的主题、演讲内容、方式等都是精心设计的。所以每次苹果有新产品发布都是世界的一场大讨论，当然买那么好核心在于产品好，但是不得不说苹果那么有影响力有很大的一部分原因是因为推广的好。包括公司困难时他重新回来，为了挽救当时的苹果，他定的广告方案完全就唤起了大家对苹果的热情，所以你不得不服他在营销推广方面的实例，

   所以现在真没有酒香不怕巷子深了，好东西就是要秀出来，对待自己也是，老是抱怨自己默默无闻，那你想过没有如果你通过很多方式输出自己认为好的东西，并且帮助一些人，到时候你会发现你其实还是挺牛的（哈哈，当然前提是你自己得有实力），别觉得自我营销就是一个贬义词。

5. 完美

   乔帮主一直追求——产品必须是科技和人文的完美融合。这种始终如一对完美的追求，才有了现在的苹果，但是在现在的社会好像追求完美变成了不太像褒义词的褒义词，总感觉如果说出这个词语马上就会有人给你怼回来。我觉得追求完美他就是一个褒义词，我们应该提倡，但是执着与完美可能就容易陷入痛苦。

6. 坚持

   从书中你可以看到乔帮主有一种盲目的坚持，最大的体现就是在于他的癌症，很多人都讲，如果他不那么坚持对待工作而选择懈怠癌症这件事，可能结果没那么糟。所以我会这么认为：可能做到“坚持”和知道什么该坚持什么不该坚持相比较的话，做到坚持肯定更容易一点点，大家都知道力得用对。

前后端关于CMDB的交互决定选用GraphQL，因为第一次听说就抓紧时间了解了以下是个什么东西。

GraphQL干嘛的？

GraphQL语言致力于提供一种直观的弹性语法系统，用以描述客户端程序设计时的数据需求以及数据交互行为。

说的直白点就是能让API设计变得更加的灵活，你想要什么数据就给你什么数据，不多不少。

实践

目前只有CMDB那一块使用的GraphQL，其它的前后端交互还是用的传统的方式。

不过这并不影响我对它的兴趣，新东西总是喜欢琢磨琢磨，更何况GraphQL有大厂的背书，那证明它的潜力是巨大地。

• 传统的api设计，如果想要多种场景公用一个接口，比如都是获取用户信息，A场景需要name，B场景需要name+sex，C场景需要name+introduction，很显然都是获取用户信息，但是每个场景要求的数据不一样，如果简单粗暴的直接返回整个用户信息，很显然不太科学，极端一点假设用户有20个字段，调用方只需要一个字段，你给20个字段完全是浪费，另一种方案是写三个接口，但是三个接口很显然太冗余了，所以通常是公用一个接口，但是共有一个接口就肯定免不了一堆逻辑判断,此外，这样还会造成不同业务之间的耦合，每次发布都需要各个业务场景一起测试和回归。

这种时候痛点就出现了，不重用接口则没法提高开发效率，重用接口则会有这些问题。

这个时候GraphQL就体现它的优势了，我认为它的出现就是为了解决上面的痛点。出现上面的问题的根本原因我认为在于，前端不能直白的告诉后端我要什么数据，必须通过后端经过对应的翻译转换，因为前端没有合适的方式来告诉我们A只需要name，B只需要name+sex，它可能就给我们一个userId然后给个businessCase然后我们根据businessCase来进行逻辑判断，进行数据查询，进行数据筛选以及过滤。

GraphQL

花点时间写这个，是因为觉得GraphQL算是开阔了我的技术视野，我们其实还用的很浅，他的一切皆是图、API无版本（某些场景）的思想，以及schema、别名、片段、指令、mutation、元字段等概念让GraphQL灵活的像猴哥，至少目前我们没有遇到有什么场景是满足不了的，至少对于技术浅薄的我来说是有开到脑洞。

我为什么要放弃RESTful，选择拥抱GraphQL

graphql工具社区

学习地址：

这是我用nodejs实现的很简单的demo：

这是通过howtographql搭建的demo

https://flaviocopes.com/graphql-vs-rest/

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

这两天看了有人推荐的约翰·伯格在BBC的纪录片《观看之感》，这部纪录片开始通过讲艺术中的绘画（油画），然后讲解油画的内容，最后过渡到当今（70年代）社会的海报（广告）。

我这人是个粗人反应也比较慢，看到最后瞬间才如醍醐灌顶般了解这个纪录片讲述的东西，想在这儿写下感想….

但是资历太浅写不出来，后面想通了再回来补，现在就记录下现下我的思考。

感触

一听到艺术都觉得那是个高层次的是在生活之上的，其实可能不是我们传颂的那样，它的内容最终都是反馈到世俗生活中的，所以这样传统的认知是值得商榷的（约翰·伯格甚至是批判这种认知），整个纪录片我得到的信息是，告诉我一个词叫“欲望”，其实不管是油画还是其复制品还是现在的海报背后都隐藏着人们对某一方面的欲望。

所以其实你会发现现实中很多东西其实是被设计的，在比较深层次的地方他们可能会很可怕的引导你的思维方式、你的诉求、你的认知…，表面上可能会影响你穿什么、吃什么、喜欢什么…，这让我想到了一本书《娱乐至死》，大家有兴趣可以看下我觉得很有意义的一本书。

节目最后伯格大叔也说了，纪录片仅代表他的观点，具体怎么看还是取决与我们自己。所以我们活着一定要多些思考，多换角度思考，多想想为什么，不要轻易听信别人，也不要懒得思考…

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。

以前我对code review是抗拒的，原因在于两方面：

1. 总感觉有点脱光了让人看的感觉，没脸。
2. 觉得是浪费时间，研发周期时间都不够还做什么code review。

不过后来发现之前的自己是多么愚蠢

Why

• 倒逼团队成员写出更有质量的代码

  （基于编码规范等），让代码可以更好的组织起来，有更易读，有更高的维护性，同时可以达到知识共享，找到bug只是其中的副产品

• 确认自己的设计和实现是一个清楚和简单、正确的

  并且通过review找到问题代码，减少错误和暗坑

• 让更多的人了解你所写的模块，并能促进相互学习对方的长处和优点。

• 提前暴露影响性能和安全的问题

When

• 自动化测试之后，提测之前
• 前后端联调之后（如果自动化测试还没实现）

What

评判标准

• 编码规范（比如后端《阿里编程规范》，前端ESLint）
• 需求覆盖度是否100%
• 测试用例覆盖度至少满足80/20原则

How

• 提升团队意识，让大家知道code review的好处和重要性，切忌别把时间安排与code review拿在一起说，它们是两回事，时间够不够条件够不够跟code review好不好无关。
• code review落实到产线的专项目标，指定责任人。
• 组件core view 团队，定义code view的关注点，持续改进。

首先为什么需要详设？

肯定有人会喷，现在都谈敏捷了，你那是瀑布那一套了，现在谁还弄详设，然后就被鄙视了。如果是这样我就想问下，什么是敏捷？什么时候应该敏捷？先回答好了这两个问题再BB，哥也是经历过敏捷的人，13年在一家做数字工厂的创业公司，被公司副总忽悠做项目经理，当时作为一个码农的我来说，本身比较迷茫感觉天天敲代码不是我要的，觉得白富美离我太远。所以就想做产品经理，憧憬做一个响当当的产品出来，享誉中国，当然我得解释一下，此产品经理不是被玩坏的那种UE产品经理，而是正儿八经的产品经理。刚好遇到此副总，跟我聊了后就看上我了，美其名曰看上我的才，觉得我有当产品经理的潜力，然后我就飘飘然的去了。去了之后就让我先从项目经理干起，这儿的项目经理只管项目（需求调研、文档编写、项目资源协调…）不管技术。副总当时推得就是敏捷，因为本身干的是传统行业，一开始都是瀑布过来的，副总觉得瀑布有很多问题，所以准备推敏捷，我当时也是第一次接触敏捷，所以老大丢给了我一堆书，其中一本我记得是叫《敏捷项目管理》的书，然后就让我抱着啃，也恬不知耻的跟着其它项目组体验了敏捷的落地…。那段时间是我悠闲、迷茫的时光，一开始用latex跟公司弄宣传册，然后跟项目，去鸟不拉屎的地方，夏天跟客户喝着“枝江”聊着需求，其实挺怀恋的…。

扯远了，后来在现在的公司，公司又请人做了一次敏捷培训，内容其实跟我之前看的书差不多，只是里面有一个概念是我比较深刻的就是讲师说了一个词语叫“小瀑布”，大概意思就是取敏捷和瀑布的各一部分。为什么呢？就是因为传统的瀑布确实是太重周期太长了，而且对客户的要求高，因为瀑布都是白纸黑字写好合同定功能需求的。你想想客户如果没想好，那是不是就麻烦了。但是事实是往往客户是不可能百分百知道自己要什么的或者说不可能百分百描述清楚自己要什么的。这个时候敏捷就有优势了，敏捷在我看来其实就是工作理念的转变，讲求的是快速迭代，讲求用户参与，讲求跨职能，这样就能很大限度的避免走偏。

小瀑布在我们团队是咋用的呢，主要包括：

1. 首先团队是跨职能的，需求、产品、测试、研发都同属于一个团队，且团队的目标是一致的。
2. 前期除了User Story，还会进行需求评审，会出UCD文档，研发会出详设。
3. Daily Scrum不强制要求。
4. 没有Sprint Review

为什么我们会这样是因为我们本身不是一家互联网企业，对快速响应要求没那么高，我们是一家传统的toB企业，有自己的产品，很少接项目做，有稳定的渠道，不过也存在瓶颈，在这样的情况下，做新产品，我们则采取了现在的小瀑布的形式。至少目前来讲是很适合的。

ok，扯得有点多了，我们还是来说说详设。

0.1版详设

因为之前的详设没有一个特别正式的模板，接着0.2功能迭代需要写详设，领导让我和另外一个同事整一个详设的样板出来，跟领导过了几次，搜集了一下意见，最终中心思想只有一个，让新旧研发、测试、技术大佬都能看明白。

所以最终出的模板是这样滴：

这个模板稍微复杂了一些，但是他的好处在于说明了上下文，说明了依赖项，说明了核心逻辑，所以基本上出来的东西大家都能看懂，也能而且能评估难度和工作量等。

0.2版详设

这版详设是在产品0.3.3迭代后出现的修改，是在0.1基础上的一些精进，精进了依赖项和核心逻辑说明。

• 0.2把外部依赖项单独拎出来，这样能更加清晰表述自己所需要的支持，并且让对方知道。
• 0.2把核心逻辑也着重提出来，0.1核心逻辑更多在于文字描述和UML图，0.2的要求是用伪代码+UML的形式进行核心逻辑的说明，核心思想就是贴近代码让详设更加实用。

详设最实用的地方：是为了让你思考更加缜密，并且获得反馈。

未来的期望：

当然这版详设也不是最终版，以后会持续精进，最终的目标是直接不要文档。

甚至我们刚进的一个架构师提出的愿景是：全部用类似单元测试的代码+注释的形式写详设，详设是否存在问题，看单元测试是否通过，我觉得是很美好的…..路很长。

名词解释

Sprint

可理解为一个迭代

Scrum

Scrum 可以理解成是一个框架，此框架让产品管理和工作技术的相对成效更加清晰地显现出来，以便您可以持续改进产品、团队和工作环境。

Daily Scrum

每日站会

User Story

用户故事，可以理解为一个场景或者一条需求。

兽爷的《疫苗之王》原篇。做个保留，作为一名小女孩的爸爸，仅以此文诅咒他么的长生生物之类的不良商家以及背后的各种势力各种任务，滚你妈的祖宗十八代。诅咒他们得癌症了发现能治，然后吃药发现吃的是假药，然后就只有等死。气死老子了，一想到自己女儿就气不打一处来。

之前在12-Factors时提过我们在搭一个脚手架，这篇简单介绍一下，老话说得好再丑也要出来吓人嘛。

项目模块

项目模块是基于maven做的项目生成脚手架，基于此脚手架生成 maven 项目模块， 开发人员能快速的基于模版进行开发，减少前期熟悉开发框架时间。同时 也通过此模版来统一平台开发规范，实现工程能力提升，沉淀工程规范。

结构说明

• app-bom 工程依赖管理.

• app-manager 工程胶合层，service 层通用能力下沉，复杂 dao 组合.

• app-repository 数据操作层，与数据库进行交互.

• app-rpc-api 服务向外暴露的 rpc api 接口.

• app-service 服务业务逻辑实现.

• app-web 服务 restful 接口.

maven脚手架

最近项目的0.2阶段需要加上权限功能，产品方给了一个需求文档，让我们参与共创。所以借此梳理梳理权限的东西。其实万变不离其宗，我觉得基本上权限设计都是基于RBAC模型来设计的。

我认为的权限应该是分为两种：

• 应用权限。也就是我们通常说的系统权限，比如用户、角色、权限等等。
• 认证。通常说的是验证某个用户是否具有访问系统的权限，实现方案比如OAuth、OAuth2、Open API等等。

权限复杂度的设计依业务场景而定，我是基本上做的都是toB，所以权限这块会相对复杂些。不同的toB系统权限设计肯定也不同。不过我觉得大体可以分为三种toB权限设计场景。私有云、私有云（对客户定制开发并部署在客户现场 的我也归为私有云）、混合云。当然我比较熟的是公有云和私有云的，混合云的我还没涉及到过，不过我觉得是混合云应该和公有云的权限设计比较接近。

下图我参与过的某toB平台，我理解的权限设计。

租户那块为什么单独标注呢，租户是一个比较大的概念，通常表名一个公司或者个人。

下面是我另外参与的私有云项目的权限设计。

这个权限你会发现有一个域的概念，是因为我们的客户是集团性质的客户，会有总公司、分公司、事业部等概念，因为每个分公司或者事业部大体上都是独立运营的，但是他们又是属于一个集团，所以我们出现了域的概念。一个域可以理解为一个公司或者事业部但是我们不强关联，域是扁平的增加了灵活性。还有一点需要注意在这儿部门（组织）是不纳入权限的，我们使用角色来控制，为什么还需要部门，是为了让角色更丰满，部门可为角色打上标签，客户也好理解。同时也减少了复杂性。

名称解释

资源

因为要打造的是一个APM系统，所以里面会涉及到CMDB，资源这个名称就是CMDB来的当然一般我们叫CI（具体一个配置项，也叫CI实例），要详细讲就要讲到CMDB了，要讲CMDB那就复杂了，不是一两篇能说清楚的，后面有机会我会试着讲讲我理解的CMDB和CMDB在我们系统是怎么定义以及怎么用的。

RBAC

基于角色的访问控制，所以你会发现这个模型能满足大多数的权限设计。至少我没见过没有角色这个概念的权限设计。

google和博客说的更清楚