组件化、复用，这几乎是所有开发者追求的东西。Web Components就是为此而提出。可以使用来创建封装功能的定制元素，可以在你喜欢的任何地方重用，不必担心代码冲突。

这样的理念和Vue十分相似，专注于组件。所以Web Components或许是未来的方向！我在这里写一些Web Components的例子，供学习与参考！

围绕业务概念建模

原文：经验表明，围绕业务的限界上下文定义的接口，比围绕技术概念定义的接口更加稳定。针对系统如何工作这个领域进行建模，不仅可以帮助我们形成更稳定的接口，也能确保我们能够更好地反映业务流程的变化。使用限界上下文来定义可能的领域边界。

这个原则关于微服务如何确认边界，主张以业务而非技术作为划分基准。缘由我有不同的理解。在互联网涉及的业务中，很大一部分都是原来有的，互联网使它更加简单。例如仓储系统，现实中仓储不是随着互联网的出现而发展的，它拥有悠久的例子，古代的粮仓也是呀。而我们设计服务最佳的方式，将现实中映射过来，当然也需要结合网络优点适当调整。

前言

Git LFS一直都想尝试，但，GitHub上

1G的存储，1G的带宽是，这量实在是。。。在2月26日，Netlify宣布了流量限制100G，也宣布新的功能，图像转换功能为流量限制做铺垫，以及这个转换功能所附带的大文件存储。一半伤心一半心动。虽然转换功能也有限制，2500次每月（同一次相同转换会缓存，只消耗1次次数），所以对于大部分中小型网站来说都够用了，当然100G的带宽，也是一样。

作为转换功能基础的文件存储，则没提及，可能无限制吧。所以是时候升级啦。

删除图文化的教材，我认为 Outline Manage 是很简单的，你可能只需要懂一点点服务器就行了，你可能好奇我为什么要删除这篇文章，所以我在这回答两个问题

Q：为什么要搭建 VPN？

A：这对于程序员来说，答案是一致的。我们需要外部的资源，可能是文档，可能是lib，可能是问答社区。然而合规的搭建 vpn 需要满足两个条件，第一是企业，第二有外贸。这对于我们个人学习为目的是不可能申请下来的。所以才需要私自搭建

Q：那么为什么要删除教程？

A：我也一度以为，“墙”的存在，造就了诸多不便，它至少使中国的软件方面学习难度高了数倍。但近年来发生了很多事，我看到了美国这类的国家，对于中国进行诸多污蔑，并不是没人为中国发声，而是你能在推特上看到内容，基本都是被控制的。我就遇到过被推特删评的情况，这就是所谓的“民主”与“自由”。所以，如果你找到这篇文章，仅仅是希望访问外网的资讯，而不是用于其他目的（目前也就程序员有这需求吧），那么我拒绝提供相关教程，如果你是程序员，那么看我的另一篇文章，相信对于你来说这不会很难

另一篇VPN教程

在今天，加入了Google Ads，不过更多的是想体验一下广告的收益以及对页面浏览的影响。我使用的是自动广告，但自己访问，完全没有任何广告的影子，不知道是不是配错了。如果亲们访问时对你们造成了影响（或者发现了广告的影子），可以截个图，通过右下角的Chatra联系我。

对页面访问有影响的话会下掉广告，毕竟没国际信用卡，就算赚了也取不出来。
去掉去掉，毕竟每天只有1-2pv，一个月也就半百人访问这个小破站，而且谷歌广告需要点击才收费，点击一次3毛。。。。(2019.1.15写)

另外页面会使用Google分析。。。这个可能对国内用户访问造成影响，请尽量在VPN下访问该站点，vultr与outline是不错的方案，或者可以看一下我的VPN教程

又双叒叕加回来啦😂—2019.7.28

缘由

有时候不想打开电脑修改文章，所以需要一个管理页面代替电脑操作（简单的能修改），一般而言，存在两种方案实现它

• 调用GitHub（或者其他Repo）的Api，获取与修改文件
• 通过Git命令获取修改以及推送文件

但无论那种都存在安全问题，如果在本地操作，那么完全没必要管理站点，不是本地的话且使用静态托管的话（如GitHub Page），如何确保是自己修改呢？这就需要一个安全服务，但本身只是偶尔修改使用，撘一个安全服务似乎不划算，所以这件事就一直搁置着

前段时间，我将静态服务迁移到了Netlify，发现它居然提供了CMS用于管理静态资源，我体验了Gatsby的例子，能上传媒体文件，能添加与修改文章，相对的安全性（Netlify会获取你的Git仓库很多权限，但我不认为它会做恶意破坏的行为）…满足了我的要求。

一些重要的，有争议的点

• 边界 - 《领域驱动设计》
• 服务版本管理
• 公用数据
• 安全性
• 报表

再过去的一段时间，感觉一直在原地踏步，虽然偶尔也有写几篇文章，但几乎都是在翻旧账

但总不能一直这样下去吧

所以准备在接下来有所改变

新的域名（dnocm.com）,我会再近期将其他站点迁移到这上面

新的博客Lofter，准备写一些其他兴趣相关的（Code外，动漫、游戏？），虽然目前还是零记录

新的CI/CD，使用Netlify做静态托管，能自动https，GitLab 3年前就开始讨论与准备集成Let’s Encrypt，但。。。

新的邮箱（有新域名自然换啊），i@dnocm.com欢迎联系

新的封页（https://www.dnocm.com/cover）,可能调整到根路径下，打算用Web Components重写，打算中。。。

大半年前就写过一篇文章[《测试驱动开发(TDD)的实践》](https://www.dnocm.com/articles/almond/test-driven development/)，关于测试的。时至今日，我仍然坚信测试是软件开发一重要环节，它在绝大多数情况下，保障了系统的质量与稳定性。

但当时所搭的框架存在一些不足，当然主要是由于Asciidoctor。这是一个足够完善的标记语言，但也足够复杂。然而大多数情况下我们并不需要这些语法，Markdown正好足够。

事实上，当时我最先尝试的也是Markdown，使用Spring Restdoc中推荐的Slate方案，来解决Markdown无法包含问题。缺点是它运行使用的Ruby，与我所学的完全不同（Java、Js）。但最近看到了另一个文档工具Docsify，它也添加了包含功能，它足够简单，以至于看几遍例子就完全学会，虽然也有缺点，SEO方面，但内部接口文档，你会在乎这个么？下面是一个例子整合Restdoc与Docsify

背景

在微服务中，单个服务的升级改善是不可避免的，虽然改动最终引起Rest接口变动并不多，但仍然会出现。在《微服务设计》中，提供了两种处理方案：

1. 不同的接口共存
2. 同时运行多个版本服务

这本书的作者Sam Newman，他认为这两种方案都是可行的，但更倾向于不同接口共存。也提出了三点主要原因

• 当出现问题时，不同的接口共存可以更快的修改新老版本的代码并一同部署，而另一种就比较麻烦了
• 方案二维护困难，同时存在多个版本服务，对运维来说具有较大的挑战性
• 持久化层可能是一样的，方案二却有不同版本的实现，会导致潜在的复杂性

但我更倾向于方案二，该方案的实际使用者主要是Netflix（Spring Cloud便是基于他开源的微服务框架研发的），在现阶段（2018年）相对于作者的年代（2015年），技术上已经有了较大的变化。微服务的设计已经在很多公司大规模的推行及使用，变得更加成熟。作者所提出的前两点问题已经有了比较好的方案减少影响