DDD、中台和微服务对应关系

April 23rd, 2021 by JasonLe's Tech 536 views

DDD 的子域分为核心域、通用域和支撑域。

划分这几个子域的主要目的是为了确定战略资源的投入,一般来说战略投入的重点是核心域,因此后面我们就可以暂时不严格区分支撑域和通用域了。领域、中台以及微服务虽然属于不同层面的东西,但我们还是可以将他们分解对照,整理出来它们之间的关系。

如果将企业内整个业务域作为一个问题域的话,企业内的所有业务就是一个领域。在进行领域细分时,从 DDD 视角来看,子域可分为核心域、通用域和支撑域。从中台建设的视角来
看,业务域细分后的业务中台,可分为核心中台和通用中台。

从领域功能属性和重要性对照来看,通用中台对应 DDD 的通用域和支撑域,核心中台对应 DDD 的核心域。从领域的功能范围来看,子域与中台是一致的。领域模型所在的限界上下文对应微服务。建立了这个映射关系,我们就可以用 DDD 来进行中台业务建模了。

中台如何建模?

中台业务抽象的过程就是业务建模的过程,对应 DDD 的战略设计。系统抽象的过程就是微服务的建设过程,对应 DDD 的战术设计。下面我们就结合 DDD 领域建模的方法,讲一下中台业务建模的过程。

第一步:按照业务流程(通常适用于核心域)或者功能属性、集合(通常适用于通用域或支撑域),将业务域细分为多个中台,再根据功能属性或重要性归类到核心中台或通用中台。核心中台设计时要考虑核心竞争力,通用中台要站在企业高度考虑共享和复用能力。

第二步:选取中台,根据用例、业务场景或用户旅程完成事件风暴,找出实体、聚合和限界上下文。依次进行领域分解,建立领域模型。由于不同中台独立建模,某些领域对象或功能可能会重复出现在其它领域模型中,也有可能本该是同一个聚合的领域对象或功能,却分散在其它的中台里,这样会导致领域模型不完整或者业务不内聚。这里先不要着急,这一步我们只需要初步确定主领域模型就可以了,在第三步中我们还会提炼并重组这些领域对象。

第三步:以主领域模型为基础,扫描其它中台领域模型,检查并确定是否存在重复或者需要重组的领域对象、功能,提炼并重构主领域模型,完成最终的领域模型设计。

第四步:选择其它主领域模型重复第三步,直到所有主领域模型完成比对和重构。

第五步:基于领域模型完成微服务设计,完成系统落地。

PE、PB、PS、ROIC、WACC、PCF含义

April 10th, 2021 by JasonLe's Tech 1,852 views

PE:市盈率 = 股价 / 每股盈利

PB:市净率=股价 / 每股净资产

PS:市销率=股价 / 每股收入=总市值 / 销售收入

ROIC(投资资本收益率)ROIC衡量的是企业全部投资资本的运用效率,而不考虑企业所使用资金来自于股东或是债权人。ROIC以投资资本代替ROE中的所有者权益作为分母,以息前税后利润(NOPLAT)代替净利润做分子。

WACC(加权平均资本成本)

WACC代表公司整体平均资金成本,可用来衡量一个项目是否值得投资;项目的回报必须不低于WACC。计算WACC时,先算出构成公司资本结构的各个项目如普通股、优先股、公司债及其他长期负债各自的资金成本或要求回报率,然后将这些回报率按各项目在资本结构中的权重加权,即可算出加权平均资本成本。

计算公式=(债务/总资本)*债务成本*(1-企业所得税税率)+(股权/总资本)*股权成本

PE:Price/Earnings 市盈率 也有叫做PER的,Price/Earnings Ratio
本益比,价格收益比,市盈率
   市盈率反映市场对企业盈利的看法。市盈率越高暗示市场越看好企业盈利的前境。对於投资者来说,市盈率过低的股票会较为吸引。不过,在讯息发达的金融市场,市盈率过低的股票是十分少见。单凭市盈率来拣股是不可能的。投资者可以利用每股盈利增长率(Rate of EPS Growth),与市盈率作比较。对於一间增长企业,如果其股价是合理的话,每股盈利增长率将会与市盈率相约。公式:市盈率 = 股价 / 每股盈利.如果企业每股盈利为5元,股价为40元,市盈率是8倍。

PB:Price/Book value :平均市净率
股价 / 账面价值
其中,账面价值的含义是:总资产 ? 无形资产 ? 负债 ? 优先股权益;可以看出,所谓的账面价值,是公司解散清算的价值。因为如果公司清算,那么债要先还,无形资产则将不复存在,而优先股的优先权之一就是清算的时候先分钱。但是本股市没有优先股,如果公司盈利,则基本上没人去清算。这样,用每股净资产来代替账面价值,则PB就和大家理解的市净率了。  

PS市销率=总市值/销售收入,P是股价,S是每股的销售收入,P/S或者用总市值除以销售额,这样算出的值叫PS。
PS即市销率估值法的优点是,销售收入最稳定,波动性小;并且营业收入不受公司折旧、存货、非经常性收支的影响,不像利润那样易操控;收入不会出现负值,不会出现没有意义的情况,即使净利润为负也可用。所以,市销率估值法可以和市盈率估值法形成良好的补充。市销率估值法的缺点是,它无法反映公司的成本控制能力,即使成本上升、利润下降,不影响销售收入,市销率依然不变。另外,市销率(PS)会随着公司销售收入规模扩大而下降;营业收入规模较大的公司,PS较低。用PS看企业潜在的价值,看它未来的盈利能不能大幅增长。PS低了就存在上升的可能。PS最低的股票是长线大牛股。

PCF 市销率=股价/每股现金流=市值/经营现金流

市现率,就是分母(其他指标中的利润或者营收)变成经营现金流。相比其他指标,现金流本身就足以精确的反映企业的财务健康状况,因为它简单地说明了流进、流出企业的现金是多少。

市现率的价值还在于现金流往往比收益更稳定。例如,它不会受到企业重组或者资产核销等非现金支出的影响。现金流的缺陷是没有考虑资产折旧,因此。这就导致资产密集型企业的现金流大多高于收益

逻辑卷扩容

November 24th, 2020 by JasonLe's Tech 1,224 views
  • umount原分区

umout /dev/mapper/datavg-lv_mysqldata,报target is busy.

  • 查看谁正在用这个分区

fuser -m -v /dev/mapper/datavg-lv_mysqldata

返回:

USER        PID ACCESS COMMAND

/dev/dm-2:           root     kernel mount /mysql_data

work       1910 ..c.. bash

  • kill占用分区的进程,kill 1910
  • 重新umount
  • fdisk格式化分区,fdisk /dev/sdb
  • 运行dmsetup ls

返回:

datavg-lv_mysqldata     (253:2)

centos-swap     (253:1)

centos-root     (253:0)

  • 删除datavg-lv_mysqldata

dmsetup remove datavg-lv_mysqldata

  • 先创建一个分区,比如/dev/sdb1,使用 pvcreate 命令创建物理卷,pvdisplay 查看物理卷信息:

pvcreate /dev/sdb1
pvdisplay

  • 使用 vgdisplay 查看卷组信息
  • 获取VG name, 比如centos
  • 使用 vgextend 命令把/dev/sdb1加入到centos:

vgextend centos /dev/sdb1

  • 使用 lvdisplay 查看逻辑卷信息:

lvdisplay

lvextend -l +100%FREE /dev/centos/root

xfs_growfs /dev/centos/root

超额收益

November 1st, 2020 by JasonLe's Tech 1,047 views
        首先,收益一般分为两部分,第一部分是跟着市场上涨和下跌的,这部分收益我们称为贝塔收益,比如持有沪深300ETF,然后沪深300指数涨了10%,你就赚了10%,这部分收益其实和能力无关,算是持有资产给的系统性收益吧。
        另外一部分是不随着系统变化的收益,我们称之为阿尔法收益(α),比如沪深300指数不涨不跌,但是你持有了一个什么沪深300增强基金,涨了+3%,这部分收益就是不随着系统收益来的收益,就是我们常说的阿尔法收益,也就是所谓的超额收益。
在对到基金上来,指数基金大多是跟着一个具体的市场指数,这个指数涨这个基金就涨,这种被动指数基金一般都是赚取的是贝塔收益(β)。而与之对应的主动基金,自然就是靠基金经理的能力来追求超额收益了。
        这里要说两件事情,第一是贝塔收益和阿尔法收益并不冲突,比如优秀的主动基金在市场行情上涨的时候大概率也会上涨,并且会同时有超额收益,这部分相当于赚了阿尔法+贝塔两种收益。
        第二个事情就是,这两个收益也没有优劣之分。这句话有两层意思,第一层意思是,不管是贝塔还是阿尔法,赚取的收益都对应着相应的风险,这一点是一样的。第二层意思是,不是说追求超额收益就会一定比市场的贝塔收益赚的多,主动基金可能跑赢指数,但是也可能跑输指数,尤其是牛市的时候。因此其实并没有优劣之分。
        那我们投资者应该怎么追求收益呢。其实看起来,大部人追求的都是在享受到贝塔收益的基础上也能有超额收益。因为贝塔收益其实并不由我们决定,市场涨不涨涨多少什么时候涨我们并不知道,但是只要我们在场,贝塔收益(当然也可能是亏损)就一定能享受到。那么超额收益,我们应该如何追求呢?
       当然这里先抛两个基本的原则,
  • 是收益风险同源,就是想要赚更多的超额收益肯定会承担更多的风险
  • 偏离度越高,超额收益的可能就越高。这个也好理解,买一个股票可能一个月翻倍,买下沪深300的全部股票,大概率也就是复制沪深300的走势了。
但是请记住第一条,偏离度越高,是超额收益的可能越高,而不是超额收益越好,偏离度越高承担的风险自然也是越大的。好啦,下面开始分享超额收益从哪里来。一般超额收益是从下面几个方面来的,当然也是一个递进的层次关系。
  • 第一层,行业内优选个股。比如同一个行业内,你能选出来A公司要比其他公司好,这个时候买入A公司,大概率就会获得超过该行业整体收益的超额收益。对应到基金里面,我们经常听到的基金公司的行业研究员就是干这个工作,研究某个行业内的不同公司的好坏来完成选股,从而来获得行业内选股的超额收益。
  • 第二层,行业轮动。你要问上面的行业研究员这个行业A好还是B好,他会很明确的告诉你,但是你要问他,这个行业啥时候涨?他就不一定知道了。行业之间的走势和轮动就要比上面优选个股要高一个层次,这个需要考虑比如行业的整个供应链、上下游传导,比如汽车行业就要考虑比如人口、历史汽车销量和折旧周期、油价、甚至高速公路、高铁等的开设维修,环保政策等等,如果预测出后市汽车行业销量要上涨,那肯定要先买比如汽车零部件供应商的股票,然后才是汽车厂商本身,然后才会轮到到比如油企、高速等。这个行业轮动是一般是由基金经理来做。这部分做的好了超额收益会高,相当于每次都享受了当前涨的最好的行业。
  • 第三个层面,仓位控制。比如市场高点就减仓,低点加仓,这是最简单的仓位控制。牛逼的人一般都是做大类资产配置,比如资金在A股、美股、港股、债券、黄金、甚至不用币种之间转换,这就是所谓的永不空仓。这个需要对整体宏观经济和不同资产都有掌握,如果只是仓位高点的控制,一般也是由基金经理来做。但是涉及到全球资产配置,这就不是单个基金经理能搞的了,一般都是金融大鳄弄的,比如之前做空泰铢引发亚洲金融危机的索罗斯就是这么干的。
         行业内选股,这就是我们常说的选股,仓位控制就是我们常说的择时,而第二个行业轮动,既包含了选股也包含了择时。听起来好像我们平时都是这么干的,但是据分析,就算是专业的基金经理,拉长周期来看,也就是在第一个层面优选个股上做确实不错,至于行业轮动和仓位控制,就算是专业的基金经理平均下来也是搞的细碎。所以前几年指数基金几乎完全碾压了主动基金。当然这几年主动基金有点抬头,看看后面会怎么样吧。
https://zhuanlan.zhihu.com/p/171641265

Springboot 拦截器的坑 WebMvcConfigurationSupport 失效

October 16th, 2020 by JasonLe's Tech 11,174 views

今天遇到一个拦截器失效的问题,具体看源码分析下。

环境:

springboot 2.x

spring 5.x

===================

拦截器创建的几种方式

  • extends WebMvcConfigurationSupport
  • implements WebMvcConfigurer

如果项目中出现了一次 extends WebMvcConfigurationSupport ,其他的 extends WebMvcConfigurationSupport 和 implements WebMvcConfigurer 会失效 。

先看下 WebMvcConfigurationSupport 这个类, addInterceptors 这个方法,默认继承的是 DelegatingWebMvcConfiguration,这个类就是获取 `所有 ` 实现 WebMvcConfigurer 的子类,调用他们的方法,如果有多个 通过实现 WebMvcConfigurer 创建的拦截器,是都可以生效的。

那多个 继承 WebMvcConfigurationSupport 为啥只有一个生效呢,答案在这个类WebMvcAutoConfiguration 的 ConditionalOnMissingBean 注解,只实例化一个Bean,多个继承也只有一个生效。
再看下 addInterceptors 啥时候触发的,获取拦截器的时候,获取过就不再获取了,所以 addInterceptors 在项目启动触发才有效。而 getInterceptors 这个方法是在 handerMapping映射的时候触发的(比如 RequestMappingHandlerMapping、BeanNameUrlHandlerMapping)。

解决方案

针对不同的场景解决方案也不一样,我想到的有3个方案。

  • 不继承 WebMvcConfigurationSupport ,拦截器全部通过实现 WebMvcConfigurer 接口(推荐)
  • 只继承一次 WebMvcConfigurationSupport ,在这个类管理所有的拦截器(不推荐,耦合性太高)
  • 针对我的场景,通过过滤器实现的。注入的代码就不贴了,before 和 fater 方法实现了类似拦截器的 preHandle 和 afterCompletion。有一点需要注意的是指定过滤器的排序(默认已经是最高了,可以忽略),由于过滤器是链式调用,如果想当拦截器用,必须指定最先加载,还有就是过滤器会拦截静态资源,做好对静态资源的放行。

 

https://www.lyscms.info/blog/detail/33A55BEE2FD94E66B40990EA4967D3F7

https://blog.csdn.net/pengdandezhi/article/details/81182701