随笔分类 - 企业架构、设计模式
摘要：
在使用minikube学习的时候，会出现你在mac上安装的minikube默认是最新版本，但是实际情况是需要安装低一些版本。可以按照k8s官方文档安装的时候指定不同安装版本，如果很慢或者无法访问直接走github安装也行。 curl -LO https://github.com/kubernetes
阅读全文
在使用minikube学习的时候，会出现你在mac上安装的minikube默认是最新版本，但是实际情况是需要安装低一些版本。可以按照k8s官方文档安装的时候指定不同安装版本，如果很慢或者无法访问直接走github安装也行。 curl -LO https://github.com/kubernetes
阅读全文
摘要：
背景 通过脚本改变评分 背景 近期有一个需求，需要对优惠券可用商品列表加个排序，只针对面值类的券不包括折扣券。 需求是这样的，假设有一张面值券 50 块钱，可用商品列表 A 100、B 40、C 10，当用户查询当前券可用商品列表的时候优先将卡券可以直接抵扣且不需要用户在额外支付的商品排在前面。 C
阅读全文
背景 通过脚本改变评分 背景 近期有一个需求，需要对优惠券可用商品列表加个排序，只针对面值类的券不包括折扣券。 需求是这样的，假设有一张面值券 50 块钱，可用商品列表 A 100、B 40、C 10，当用户查询当前券可用商品列表的时候优先将卡券可以直接抵扣且不需要用户在额外支付的商品排在前面。 C
阅读全文
摘要：
最近一段时间内结束了数据库表拆分项目，这里做个简单的小结。
本次拆分主要包括订单和优惠券两大块，这两块都是覆盖全集团所有分子公司所有业务线。随着公司的业务飞速发展，不管是存储的要求，还是写入、读取的性都基本上到了警戒水位。
订单是交易的核心，优惠券是营销的核心，这两块基本上是整个平台的正向最核心部分。为了支持未来三到五年的快速发展，我们需要对数据进行拆分。
数据库表拆分业内已经有很多成熟方案，已经不是什么高深的技术，基本上是纯工程化的流程，但是能有机会进行实际的操刀一把机会还是难得，所以非常有必要做个总结。
阅读全文
最近一段时间内结束了数据库表拆分项目，这里做个简单的小结。
本次拆分主要包括订单和优惠券两大块，这两块都是覆盖全集团所有分子公司所有业务线。随着公司的业务飞速发展，不管是存储的要求，还是写入、读取的性都基本上到了警戒水位。
订单是交易的核心，优惠券是营销的核心，这两块基本上是整个平台的正向最核心部分。为了支持未来三到五年的快速发展，我们需要对数据进行拆分。
数据库表拆分业内已经有很多成熟方案，已经不是什么高深的技术，基本上是纯工程化的流程，但是能有机会进行实际的操刀一把机会还是难得，所以非常有必要做个总结。
阅读全文
摘要：
最近的工作我在做一个有关于消息发送和接受封装工作。大概流程是这样的，消息中间件是采用rabbitmq，为了保证消息的绝对无丢失，我们需要在发送和接受前对消息进行DB落地。在发送前我会先进行DB的插入，单表插入，所以在性能上也是能接受的，单表插入做了压测基本上是一到两毫秒的时间，加上消息的发送（有ACK）再加上集群是两个节点的高可用（一个磁盘持久化节点），单台TPS基本上是在2000-3000左右。这对于我们的业务场景来说是够用了。一旦当消息丢失或者由于网络问题、集群问题业务不会中断，消息就算发不出去也没关系，我们会进行消息的补偿或者同步api调用补偿。这是架构设计的必须要考虑的A计划、B计划、C计划，这是敬畏或者危机意识。
阅读全文
最近的工作我在做一个有关于消息发送和接受封装工作。大概流程是这样的，消息中间件是采用rabbitmq，为了保证消息的绝对无丢失，我们需要在发送和接受前对消息进行DB落地。在发送前我会先进行DB的插入，单表插入，所以在性能上也是能接受的，单表插入做了压测基本上是一到两毫秒的时间，加上消息的发送（有ACK）再加上集群是两个节点的高可用（一个磁盘持久化节点），单台TPS基本上是在2000-3000左右。这对于我们的业务场景来说是够用了。一旦当消息丢失或者由于网络问题、集群问题业务不会中断，消息就算发不出去也没关系，我们会进行消息的补偿或者同步api调用补偿。这是架构设计的必须要考虑的A计划、B计划、C计划，这是敬畏或者危机意识。
阅读全文
摘要：
从事.NET开发到现在已经有七个年头了。慢慢的可能会很少写.NET文章了。不知不觉竟然走了这么多年，热爱.NET热爱c#。突然想对这一路的经历进行一个总结。 是时候开始下一阶段的旅途，希望这些文章可以在发挥点价值作用。 架构设计： ElasticSearch大数据分布式弹性搜索引擎使用 （推荐） D
阅读全文
从事.NET开发到现在已经有七个年头了。慢慢的可能会很少写.NET文章了。不知不觉竟然走了这么多年，热爱.NET热爱c#。突然想对这一路的经历进行一个总结。 是时候开始下一阶段的旅途，希望这些文章可以在发挥点价值作用。 架构设计： ElasticSearch大数据分布式弹性搜索引擎使用 （推荐） D
阅读全文
摘要：
DDD本身的技术就不介绍了，本篇文章要分享下我在推广DDD或者说实施DDD的过程中的心得和宝贵的经验。事实证明，这是可行的方案。用好DDD是一回事，推广DDD是另外一回事。也许已经有一套客观理性的推广技术的方案，但是我只能说DDD非常特殊。
我们都知道自己用好DDD问题不大，让一两个人用好DDD也问题不大。你也许代码控制能力很强，也或者你的组员对DDD都有兴趣，在你的领导下，你让他们编写DDD模式的代码，问题也不大。但是作为一名架构师我们的职责是要推广或引进适合本公司业务模式的某种技术或者最佳实践。你或许推广性能优化、界面设计等等，这都没问题。但是让你推广一些有着很强主观意识在里面的东西其实很难。因为每个人的思维模式不同，对
阅读全文
DDD本身的技术就不介绍了，本篇文章要分享下我在推广DDD或者说实施DDD的过程中的心得和宝贵的经验。事实证明，这是可行的方案。用好DDD是一回事，推广DDD是另外一回事。也许已经有一套客观理性的推广技术的方案，但是我只能说DDD非常特殊。
我们都知道自己用好DDD问题不大，让一两个人用好DDD也问题不大。你也许代码控制能力很强，也或者你的组员对DDD都有兴趣，在你的领导下，你让他们编写DDD模式的代码，问题也不大。但是作为一名架构师我们的职责是要推广或引进适合本公司业务模式的某种技术或者最佳实践。你或许推广性能优化、界面设计等等，这都没问题。但是让你推广一些有着很强主观意识在里面的东西其实很难。因为每个人的思维模式不同，对
阅读全文
摘要：随着现在的企业应用架构都在向着SOA方向转变，目的就是将一个庞大的业务系统按照业务进行划分，不管从公司的管理上、产品的开发上，这一系列流程来看，都是正确的。SOA确实带来了解决现在大型企业级应用系统快速膨胀的解决办法。
但是本文要说的是，我们都将目光转向到了后端，也就是服务端，而将精力和时间都重点投在了后端服务的架构设计上，渐渐的忽视了显示端的架构设计。然而显示端的逻辑也越来越复杂，显示端轻薄的架构其实已经浮现出难以应付后端服务接口快速膨胀的危险，服务接口都是按照指数级增加，基本上每一个新的业务需求都是提供新的接口，这没有问题。按照服务的设计原则，服务接口就应该有着明确的作用，而不是按照代码的思维来考虑接口的设计。
但是由此带来的问题就是组合这些接口的显示端的结构是否和这种变化是一致的，是否做好了这种变化带来显示端逻辑复杂的准备。
阅读全文
随着现在的企业应用架构都在向着SOA方向转变，目的就是将一个庞大的业务系统按照业务进行划分，不管从公司的管理上、产品的开发上，这一系列流程来看，都是正确的。SOA确实带来了解决现在大型企业级应用系统快速膨胀的解决办法。
但是本文要说的是，我们都将目光转向到了后端，也就是服务端，而将精力和时间都重点投在了后端服务的架构设计上，渐渐的忽视了显示端的架构设计。然而显示端的逻辑也越来越复杂，显示端轻薄的架构其实已经浮现出难以应付后端服务接口快速膨胀的危险，服务接口都是按照指数级增加，基本上每一个新的业务需求都是提供新的接口，这没有问题。按照服务的设计原则，服务接口就应该有着明确的作用，而不是按照代码的思维来考虑接口的设计。
但是由此带来的问题就是组合这些接口的显示端的结构是否和这种变化是一致的，是否做好了这种变化带来显示端逻辑复杂的准备。
阅读全文
摘要：一直都在谈论面向对象开发，但是开发企业应用系统时，使用面向对象开发最大的问题就是在于，多个对象之间的互操作需要涉及数据库操作。两个业务逻辑对象彼此之间需要互相调用，如果之间的互相操作是在一个业务事务范围内的，很容易完成，但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了。
在以往，我们使用过程式的代码（事务脚本模式），将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中，就算你适当的提取重复代码，效果也不大，因为你永远都..
阅读全文
一直都在谈论面向对象开发，但是开发企业应用系统时，使用面向对象开发最大的问题就是在于，多个对象之间的互操作需要涉及数据库操作。两个业务逻辑对象彼此之间需要互相调用，如果之间的互相操作是在一个业务事务范围内的，很容易完成，但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了。
在以往，我们使用过程式的代码（事务脚本模式），将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中，就算你适当的提取重复代码，效果也不大，因为你永远都..
阅读全文
摘要：对软件开发方法论有兴趣的博友应该发现最近“领域驱动设计”慢慢的被人发现被人实践起来，园子里也慢慢有了DDD的学习气氛和宝贵实战经验的分享。其实之前我也痴迷于DDD，为什么会痴迷于它并不是因为它是所谓的新技术，也不是因为各种对它的炒作，而是我觉得我找到了能解放我们进行企业业务系统开发的方法论。
DDD可以很好的指导我们开发可靠的软件系统，尤其是现在的企业业务复杂多变的情况下，使用DDD可以很好的随着业务变化不断的重构现有的领域模型，最为重要的是我觉得DDD是能够很好的实施敏捷价值观的软件开发方法论。
阅读全文
对软件开发方法论有兴趣的博友应该发现最近“领域驱动设计”慢慢的被人发现被人实践起来，园子里也慢慢有了DDD的学习气氛和宝贵实战经验的分享。其实之前我也痴迷于DDD，为什么会痴迷于它并不是因为它是所谓的新技术，也不是因为各种对它的炒作，而是我觉得我找到了能解放我们进行企业业务系统开发的方法论。
DDD可以很好的指导我们开发可靠的软件系统，尤其是现在的企业业务复杂多变的情况下，使用DDD可以很好的随着业务变化不断的重构现有的领域模型，最为重要的是我觉得DDD是能够很好的实施敏捷价值观的软件开发方法论。
阅读全文
摘要：要想正确的设计系统架构就必须能正确的搞懂每个架构模式的用意，而不是胡子眉毛一把抓。现在有一个现象是什么呢，项目的结构从表面上看是很不错，层分的很合理，其实对业务系统来说也就那么几种层设计方法，但是现在很多项目的逻辑架构的设计不是理想，有很多概念大家并不是很了解，当然也许每个人对技术的追求不同罢了。不管你追求不追求，事实我们还是要去往正确的方向努力才对的。
阅读全文
要想正确的设计系统架构就必须能正确的搞懂每个架构模式的用意，而不是胡子眉毛一把抓。现在有一个现象是什么呢，项目的结构从表面上看是很不错，层分的很合理，其实对业务系统来说也就那么几种层设计方法，但是现在很多项目的逻辑架构的设计不是理想，有很多概念大家并不是很了解，当然也许每个人对技术的追求不同罢了。不管你追求不追求，事实我们还是要去往正确的方向努力才对的。
阅读全文
摘要：接触分层架构有段时间了，从刚开始的朦朦胧胧的理解到现在有一定深度的研究后，觉得有必要将自己的研究成果分享出来给大家，互相学习，也是对自己的一个总结。
我们每天面对的项目结构可以说几乎都是分层结构的，或者是基于传统三层架构演变过来的类似的分层结构，少不了业务层、数据层，这两个层是比较重要的设计点，看似这两个层是互相独立的，但是这两个层如何设计真的还有很多比较微妙的地方，本文将分享给大家我在工作中包括自己的研究中得出的比较可行的设计方法。
阅读全文
接触分层架构有段时间了，从刚开始的朦朦胧胧的理解到现在有一定深度的研究后，觉得有必要将自己的研究成果分享出来给大家，互相学习，也是对自己的一个总结。
我们每天面对的项目结构可以说几乎都是分层结构的，或者是基于传统三层架构演变过来的类似的分层结构，少不了业务层、数据层，这两个层是比较重要的设计点，看似这两个层是互相独立的，但是这两个层如何设计真的还有很多比较微妙的地方，本文将分享给大家我在工作中包括自己的研究中得出的比较可行的设计方法。
阅读全文
摘要：在一般的函数调用情况下，我们都习惯性的将参数传入到某个被调用的方法，这可能就是我们考虑调用方法的惯用思维，但是现在的C#语言得到了很大的提升，我们可以很自然的使用委托来减少函数之间的参数依赖；有时候会经常看见一个函数的内部逻辑并没有使用到传入的某个参数，而传入的真正目的是为了再传入到本函数需要调用的另外一个函数中去；
阅读全文
在一般的函数调用情况下，我们都习惯性的将参数传入到某个被调用的方法，这可能就是我们考虑调用方法的惯用思维，但是现在的C#语言得到了很大的提升，我们可以很自然的使用委托来减少函数之间的参数依赖；有时候会经常看见一个函数的内部逻辑并没有使用到传入的某个参数，而传入的真正目的是为了再传入到本函数需要调用的另外一个函数中去；
阅读全文
摘要：最近一段时间结束了一个小项目的开发，觉得有些好东西值得总结与分享，所以花点时间整理成文章； 大多数情况下我们都知道这些概念，面向接口编程是老生常谈的话题了，有几年编程经验的都知道怎么运用；单元测试其实在前几年不怎么被重视，然而最近逐渐的浮现在我们眼前，而且被提起的频率也大了很多了，包括重构、可测试性都慢慢的贴近我们，我们只有亲自动手去使用它才能领悟其精髓；
阅读全文
最近一段时间结束了一个小项目的开发，觉得有些好东西值得总结与分享，所以花点时间整理成文章； 大多数情况下我们都知道这些概念，面向接口编程是老生常谈的话题了，有几年编程经验的都知道怎么运用；单元测试其实在前几年不怎么被重视，然而最近逐渐的浮现在我们眼前，而且被提起的频率也大了很多了，包括重构、可测试性都慢慢的贴近我们，我们只有亲自动手去使用它才能领悟其精髓；
阅读全文
摘要：本来这篇文章是“[置顶].NET领域驱动设计—实践(穿过迷雾走向光明)”一文的一部分但是由于时间关系，完整的示例并没有跟文章同步发布，说实话时间太紧，写示例的目的是想全面的且细致的阐述DDD的分析、设计各个环节的最佳实践；原本想将文章的示例做好后在发布，但是由于工作关系和一些私人原因可能有一段时间不更新博客，又不想这篇文章拖的太久，所以我总结了两点比较有价值的地方分享给大家，目的不是让大家能会使用DDD来设计系统，而是能有一个突破点来衡量DDD到底比传统三层好在哪里，因为大部分人还没有DDD的开发经验所以能体会到应该没有相关途径；
阅读全文
本来这篇文章是“[置顶].NET领域驱动设计—实践(穿过迷雾走向光明)”一文的一部分但是由于时间关系，完整的示例并没有跟文章同步发布，说实话时间太紧，写示例的目的是想全面的且细致的阐述DDD的分析、设计各个环节的最佳实践；原本想将文章的示例做好后在发布，但是由于工作关系和一些私人原因可能有一段时间不更新博客，又不想这篇文章拖的太久，所以我总结了两点比较有价值的地方分享给大家，目的不是让大家能会使用DDD来设计系统，而是能有一个突破点来衡量DDD到底比传统三层好在哪里，因为大部分人还没有DDD的开发经验所以能体会到应该没有相关途径；
阅读全文
摘要：这一篇文章我早准备写的，迟迟未写的原因是它过于抽象不太容易表达，也很难掌握；之前对它的理解还处于比较简单的功能性上，但是最近随着对领域驱动设计及架构的研究，设计思想有了一个提升对它的理解也有了一个更清晰的轮廓，所以才敢下手去写，这么好的一篇文章不能搞砸了； “钝化语句” 简单描述：将基于栈的调用抽象成基于我们自己构建的虚拟运行时调用；
阅读全文
这一篇文章我早准备写的，迟迟未写的原因是它过于抽象不太容易表达，也很难掌握；之前对它的理解还处于比较简单的功能性上，但是最近随着对领域驱动设计及架构的研究，设计思想有了一个提升对它的理解也有了一个更清晰的轮廓，所以才敢下手去写，这么好的一篇文章不能搞砸了； “钝化语句” 简单描述：将基于栈的调用抽象成基于我们自己构建的虚拟运行时调用；
阅读全文
摘要：通过上一篇的“.NET框架设计—常被忽视的C#设计技巧”一文来看，对于框架设计的技巧还是有很多人比较有兴趣的，那么框架设计思想对于我们日常开发来说其实并不是很重要，但是对于我们理解框架背后的运行原理至关重要；当我们使用着LINQ灵活的语法的同时我们是否能理解它的背后运行原理、设计原理更深一点就是它的设计模式及复杂的对象模型； 从一开始学习.NET我就比较喜欢框架背后的设计模型，框架提供给我们的使用接口是及其简单的，单纯从使用上来看我们不会随着对框架的使用时间而增加我们对框架内部设计的理解，反而会养成一样拿来即用的习惯，我们只有去了解、深挖它的内部设计原理才是我们长久学习的目标；因为框架的内部设计模式是可以提炼出来并被总结的； 这篇文章总结了几个我最近接触的框架设计思想，可以称他们为模式；由于时间关系，这里只是介绍加一个简单的介绍和示例让我们能基本的了解它并且能在日后设计框架
阅读全文
通过上一篇的“.NET框架设计—常被忽视的C#设计技巧”一文来看，对于框架设计的技巧还是有很多人比较有兴趣的，那么框架设计思想对于我们日常开发来说其实并不是很重要，但是对于我们理解框架背后的运行原理至关重要；当我们使用着LINQ灵活的语法的同时我们是否能理解它的背后运行原理、设计原理更深一点就是它的设计模式及复杂的对象模型； 从一开始学习.NET我就比较喜欢框架背后的设计模型，框架提供给我们的使用接口是及其简单的，单纯从使用上来看我们不会随着对框架的使用时间而增加我们对框架内部设计的理解，反而会养成一样拿来即用的习惯，我们只有去了解、深挖它的内部设计原理才是我们长久学习的目标；因为框架的内部设计模式是可以提炼出来并被总结的； 这篇文章总结了几个我最近接触的框架设计思想，可以称他们为模式；由于时间关系，这里只是介绍加一个简单的介绍和示例让我们能基本的了解它并且能在日后设计框架
阅读全文
摘要：本文中的内容都是我无意中发现觉得有必要分享一下的设计经验，没有什么高深的技术，只是平时我们可能会忽视的一些设计技巧；为什么有这种想法是因为之前跟一些同事交流技术的时候会发现很多设计思维被固化了，比如之前我在做客户端框架开发的时候会去设计一些关于Validator、DTO Transfer等常用的Common function，但是发现在讨论某一些技术实现的时候会被弄的云里雾里的，会自我郁闷半天，不会及时的明白对方在说的问题； 后来发现他们一是没有把概念分清楚，比如.NETFramework、C#、VisualStudio，这三者之间的关系;二是没有理解.NET中各个对象的本质含义，比如这里的特性(Attribute)，大部分人都认为
阅读全文
本文中的内容都是我无意中发现觉得有必要分享一下的设计经验，没有什么高深的技术，只是平时我们可能会忽视的一些设计技巧；为什么有这种想法是因为之前跟一些同事交流技术的时候会发现很多设计思维被固化了，比如之前我在做客户端框架开发的时候会去设计一些关于Validator、DTO Transfer等常用的Common function，但是发现在讨论某一些技术实现的时候会被弄的云里雾里的，会自我郁闷半天，不会及时的明白对方在说的问题； 后来发现他们一是没有把概念分清楚，比如.NETFramework、C#、VisualStudio，这三者之间的关系;二是没有理解.NET中各个对象的本质含义，比如这里的特性(Attribute)，大部分人都认为
阅读全文
摘要：在开始这篇富有某种奇妙感觉的文章之旅时我们先短暂的讨论一下关于软件开发方法论的简要： 纵观软件开发方法论，从瀑布模型、螺旋模型、RUP(统一软件开发过程)、XP(极限编程)、Agile(敏捷开发)一路走来，他们的好他们的美，我想接触过的人都会口口称赞，都是大师们一身的经验结晶最后沉淀为专业的技术方向、技术领域，带领我们软件开发者们永无止境的前进，目睹一场又一场的美景一桌又一桌盛宴。他们在不断的开辟新的领域，称为伟大的科学家一点都不为过。
阅读全文
在开始这篇富有某种奇妙感觉的文章之旅时我们先短暂的讨论一下关于软件开发方法论的简要： 纵观软件开发方法论，从瀑布模型、螺旋模型、RUP(统一软件开发过程)、XP(极限编程)、Agile(敏捷开发)一路走来，他们的好他们的美，我想接触过的人都会口口称赞，都是大师们一身的经验结晶最后沉淀为专业的技术方向、技术领域，带领我们软件开发者们永无止境的前进，目睹一场又一场的美景一桌又一桌盛宴。他们在不断的开辟新的领域，称为伟大的科学家一点都不为过。
阅读全文
摘要：原则对于任何一项技术实现来说都是至关重要的，在设计某一个系统功能的时候我们讲究的是设计原则： 【单一职责原则Single Responsibility Principle、里氏替换原则Liskov Substitution Principle、依赖倒置原则Dependence Inversion Principle、接口隔离原则Interface Segregation Principle、迪米特法则Law Of Demeter、开闭原则Open Close Principle】。 在架构设计的时候我们也讲究架构原则：
阅读全文
原则对于任何一项技术实现来说都是至关重要的，在设计某一个系统功能的时候我们讲究的是设计原则： 【单一职责原则Single Responsibility Principle、里氏替换原则Liskov Substitution Principle、依赖倒置原则Dependence Inversion Principle、接口隔离原则Interface Segregation Principle、迪米特法则Law Of Demeter、开闭原则Open Close Principle】。 在架构设计的时候我们也讲究架构原则：
阅读全文
摘要：到了这里我们似乎隐隐约约的能看见LINQ的原理，它不是空中花园，它是有基础的。在上面的一系列新特性的支持下，微软通过大面积的构建扩展方法使得上述特性能连贯的互相作用，形成自然的集成查询框架。上面的这些特性都属于语言为了LINQ而做的增强，也可以说是设计者们在不断的探索新的比较符合现代开发体系的语言特性，也越来越多的支持函数式的编程特性，比如DLR的引入对Python、Ruby函数式脚本语言的强大支持，后面也会越来越多的支持其他的函数式脚本语
阅读全文
到了这里我们似乎隐隐约约的能看见LINQ的原理，它不是空中花园，它是有基础的。在上面的一系列新特性的支持下，微软通过大面积的构建扩展方法使得上述特性能连贯的互相作用，形成自然的集成查询框架。上面的这些特性都属于语言为了LINQ而做的增强，也可以说是设计者们在不断的探索新的比较符合现代开发体系的语言特性，也越来越多的支持函数式的编程特性，比如DLR的引入对Python、Ruby函数式脚本语言的强大支持，后面也会越来越多的支持其他的函数式脚本语
阅读全文