1.环境: vs Service Port为443和80,vip为10.160.100.66,pool为10.160.45.42/43的8080.80的vs重新到443. 2.问题: 单独访问源站都没问题,但是直接访问vip会出现访问过程中突然退出到登录首页的现象. 3.解决: 在vip的resource中添加会话保持即可.

本系列文章 DDD实战进阶第一波(一):开发一般业务的大健康行业直销系统(概述) DDD实战进阶第一波(二):开发一般业务的大健康行业直销系统(搭建支持DDD的轻量级框架一) 近年来,关于如何开发基于业务的软件系统与产品一直是软件行业的一个重要内容.对于架构师与软件开发人员来说,开发此类系统头痛的问题大概是以下几个方面: 1.如何将需求准确的转为软件的设计? 2.系统的架构与代码如何有效的体现我们的设计? 3.如何将领域逻辑与技术分离? 4.如何能够让团队人员的开发能够专注与业务,而不是技术本身

前面我们花了14篇的文章来给大家介绍经典DDD的概念.架构和实践.这篇文章我们来做一个完整的总结,另外生成一个Api接口文档. 一.DDD解决传统的开发的几大问题: 没有描述需求的设计模型:而是直接通过数据库表的方式体现,也就是需求与设计是脱节的. 编码的架构也没有与设计和需求对应起来. 业务逻辑与技术混在一起:业务逻辑可能直接调用的数据访问,这样把业务逻辑与数据访问的技术混在一起. 开发没有层次感和节奏感:系统没有一个统一的约束,开发人员没有一个统一的节奏,这主要体现在随意的编码. Bug 定

了解了DDD的好处与基本的核心组件后,我们先不急着进入支持DDD思想的轻量级框架开发,也不急于直销系统需求分析和具体代码实现,我们还少一块, 那就是经典DDD的架构,只有了解了经典DDD的架构,你才能知道具体在哪层要实现哪些功能,编写哪些代码,具体在开发DDD的轻量级框架与具体模块代码实现时,才能做到有的放矢. 在这里需要说明的是,我们的大健康行业直销系统有一定的业务复杂性,没有高并发.高性能的需求,所以无论是经销商上下文.产品上下文还是订单上下文的具体实现, 我们都将遵循经典DDD架构,而不是

要实现软件设计.软件开发在一个统一的思想.统一的节奏下进行,就应该有一个轻量级的框架对开发过程与代码编写做一定的约束. 虽然DDD是一个软件开发的方法,而不是具体的技术或框架,但拥有一个轻量级的框架仍然是必要的,为了开发一个支持DDD的框架,首先需要理解DDD的基本概念和 核心的组件. 一.什么是领域驱动设计(DDD) 首先要知道DDD是一种开发理念,核心是维护一个反应领域概念的模型(领域模型是软件最核心的部分,反应了软件的业务本质),然后通过大量模式来指导模型设计 与开发. DDD的一般过程是

前一篇文章我们完成了产品上下文的领域层,我们已经有了关于产品方面的简单领域逻辑,我们接着来实现产品上下文关于仓储持久化与应用层的用例如何来协调 领域逻辑与仓储持久化. 首先大家需要明确的是,产品上下文的领域逻辑是系统的核心,它不应该依赖仓储,而仓储应该要依赖领域层,这样仓储才可以把领域逻辑执行完后,才可能将 领域对象持久化到数据库中,这一点与传统的架构有本质的区别. 一般我们会在解决方案中建立一个项目,这个项目就是包含了所有聚合的仓储实现,具体不同上下文的仓储实现,可以在这个项目下建立不同的文件

前一篇文章我们介绍了如何将创建产品的领域逻辑与产品的持久化仓储通过上架产品的用例组织起来,完成了一个功能.在实际的项目中,多种前端的形态比如PC Web. 微信小程序.原生APP等要调用后端的功能,通常要将后端的功能包装成RESTFUL风格,这样前端就可以使用Http Get或Post方式调用后端的功能,所以这篇文章我们先来完成后端 的Asp.net Core WebApi,通过WebApi将上架产品的功能暴露出去. 实现上下产品接口: [Produces("application/json&q

这篇文章其实是大健康行业直销系统的番外篇,主要给大家讲讲如何在领域逻辑中,有效的处理业务逻辑条件判断的最佳实践问题. 大家都知道,聚合根.实体和值对象这些领域对象都自身处理自己的业务逻辑.在业务处理过程中,通常会有一些条件判断,当满足这些条件时,会进行不同的后续处理.在传统的实现中,可以通过If Else条件语句进行判断,但If Else语句在复杂领域中来检查是否满足一些业务条件存在以下的问题: 1.      无法很好的显示表达业务条件本身. 2.      无法对多个条件在不同需要的地方进行

直接在浏览器中访问如下地址"http://CRMHOST/organization/tools/diagnostics/diag.aspx"(这里的CRMHOST和organization替换成你自己的系统地址及组织名),会看到如下截图的界面,其中列出了CRM的延迟测试,带宽测试,包括脚本的一些性能测试,点击run就能看到具体信息,当你的延迟大于150毫秒带宽值小于50KB/S时意味着你的访问效率就会降低了.

上一篇文章我们讲了经典DDD架构对比传统三层架构的优势,以及经典DDD架构每一层的职责后,本篇文章将介绍基础结构层中支持DDD的轻量级框架的主要代码. 这里需要说明的是,DDD轻量级框架能够体现DDD的思想即可,没必要做得很重,你也可以根据理解,自己实现支持DDD的框架. 1.实体.聚合根与值对象的顶层体现 实体顶层定义: public interface IEntity { string Code { get; set; } Guid Id { get; set; } } Id是一个未来存储到

周三去某在线旅游公司面试.被问到了一个关于数据量大的优化问题.问题是:一个主外键关联表,主表有一百万数据,外键关联表有一千万的数据,要求做一个连接. 本人接触过单表数据量最大的就是将近两亿行历史数据(某运营商一业务一年数据)做查询,所有查询相关列必须做索引,而且还要保证不会出现全表扫描情况.也从来没有试过把这么多数据全部拿出来放内存中.只好回答说“再怎么做优化估计都不行,这数据量太大了,性能肯定吃不销.我只能告诉尽可能的添加过滤条件,不要一次用这么多的数据来做连接,能分批做就分批做吧”. 面试人

有一个问题就是现在我的业务分配在多个Pod上,那么如果我某个Pod死掉岂不是业务完蛋了,当然也会有人说Pod死掉没问题啊,K8S自身机制Deployment和Controller会动态的创建和销毁Pod来保证应用的整体稳定性,那这时候还会有问题,那就是每个Pod产生的IP都是动态的,那所以说重新启动了我对外访问的IP岂不是要变了,别急,下面我们来解决下这个问题. 可以通过Service来解决如上所遇到的问题,那么什么是Service呢? Service是kubernetes最核心的概念,通过创建

前言 面试官经常会问平时访问正常的网页突然变慢是什么原因引起的,说明下你排查的思路:我认为这种问题很能考察一个人的综合知识面,既能融通的贯彻知识点,也能展看对每个知识点进行详细的考问. 下面我按我自己理解的思路来整理下(若有补充请留言) 1.是否服务器的出口的带宽不够,可能突然访问量过大,并发比较高造成带宽不够用 2.如果你平时浏览正常的web加载不出来,稍微等会看看是不是出现类似404.502等这种错误大体可以判断是哪个位置出现了错误 404:(未找到) 服务器找不到请求的网页:看下服务端路径

一.static关键字 1.用法 Static是一个修饰符,用于修饰成员,包括成员变量和成员函数.当成员被静态修饰后,就多了一种调用方式,除了可以被对象调用外,还可以直接被类名调用.System.out..println("I am stacit method!") 2.特点 2.1 随着类的加载而加载,也就是说静态会随着类的消失而消失,说明它的生命周期最长. 2.2 优先于对象存在:静态是先存在的,对象是后存在的. 2.3 被所有对象共享 2.4 可以直接被类名所调用 3.静态使用注

从这篇文章开始,我们根据前面的DDD理论与DDD框架的约束,正式进入直销系统案例的开发. 本篇文章主要讲产品上下文中的领域层的主要实现,先简单讲下业务方面的需求:产品SPU与产品SKU,产品SPU主要是产品的名字和相关描述, 产品SKU包括产品SPU的多个规格,每个规格有不同的价格与PV值.从我们对DDD概念的理解,产品SPU与产品SKU属于同一个聚合,产品SPU是聚合根. 产品上下文主要实现产品的上架功能,为了实现上架功能,我们首先要实现产品上下文的领域POCO模型与领域逻辑, 我们将产品的P

上篇文章主要讲述了经销商上下文的需求与POCO对象,这篇文章主要讲述该界限上下文的仓储与领域逻辑的实现. 关于界限上下文与EF Core数据访问上下文参考产品上下文相应的实现,这里不再累述. 因为在经销商上下文中有两个聚合,一个是经销商聚合,一个是登录聚合,所以我们需要实现两个仓储接口: 1.经销商仓储接口定义: public interface IDealerRepository { void CreateDealer<T>(T dealer) where T : class, IAggre

上一篇文章我们主要讲了订单上下文的领域逻辑,在领域逻辑中完成了订单项的计算逻辑.订单的计算逻辑以及如何生成相应的实体code,这篇文章我们通过 在应用服务中实现一个下单的用例,来将这些领域逻辑以及仓储整合起来,完成一个下单的用例. 先看下单用例主体的代码: public class CreateOrderUseCase:BaseAppSrv { private readonly IOrderRepository iorderrepository; private readonly IDealer

在本系列前面的文章中,我们主要讨论了产品上下文与经销商上下文相关的实现,大家对DDD的方法与架构已经有了初步的了解. 但是在这两个界限上下文中,业务逻辑很简单,也没有用到更多的值对象的内容.从这篇文章开始,我们来讲讲订单界限上下文实现的内容, 里面的业务逻辑相对复杂一些,而且有大量值对象的引入来进行逻辑的处理. 订单上下文的需求主要是生成相应的订单项,每个订单项中有相关的订单产品和购买数量并生成订单项总额.订单项总PV,同时订单项总额 和订单项总PV会累加到订单总额和订单总PV中,同时会根据订单

上一篇文章主要讲了经销商注册的仓储和领域逻辑的实现,我们先把应用服务协调完成经销商注册这部分暂停一下,后面文章统一讲. 这篇文章主要讲讲经销商登录的仓储和相关逻辑的实现. 在现代应用程序前后端分离的实现中,通常不是将用户登录的信息存储在服务器端Session,因为会存在服务器Session无法传递的情况,也存在WebApi调用时 无法通过Authorize Attribute判断用户是否已经登录并获取用户身份信息的问题.所以现代应用程序都是由服务器后端返回Token给客户端,客户端将Token存

前两篇文章主要实现了经销商代注册的仓储与领域逻辑.经销商登录的仓储与相关逻辑,这篇文章主要讲述经销商代注册的用例与经销商登录的查询功能. 一.经销商代注册用例 在经销商代注册用例中,我们需要传递经销商的基本注册信息,这个信息是做成了DTO对象. 1.经销商注册的DTO对象: public class AddDealerDTO { public string Name { get; set; } public string Tel { get; set; } public decimal EleM

前一篇文章主要讲了订单上下文的POCO模型,其中订单与订单项中有大量的值对象.这篇文章主要讲讲这些值对象以及订单项.订单相关的领域逻辑. 1.ProductSKUs值对象领域逻辑:ProductSKUs值对象用于订单项实体中,它的信息应该来源于产品上下文的ProductSKU实体. public partial class ProductSKUs { public ProductSKUs() { } public ProductSKUs CreateProductSKUs(ProductSKU