
架构经验
文章平均质量分 79
架构师的工作、学习经历
葛飞文仓
一个有梦想的大叔程序员。
展开
-
DDD第三话:有界上下文协作
在真实业务中,有界上下文肯定不是独立的,必须彼此联系。在上面的模式中定义了不同的有界上下文的集成方式,并且相关的关联关系可以通过业务架构图展示出来。欢迎使用(哈普工具),让程序员的工作更有效率。您还可以关注微信公众号:HapTool。原创 2024-12-15 16:08:49 · 577 阅读 · 0 评论 -
DDD第二话:业务领域管理
一个模型不能没有边界而存在,它会扩展成为现实世界的复制品。这使得定义模型的边界——它的有界上下文——成为建模过程的固有部分。业务术语在边界上下文的范围内是普遍的,这种术语专注于描述被边界上下文所包含的模型。原创 2024-12-09 10:35:20 · 309 阅读 · 0 评论 -
DDD第一话:业务领域分析
通用域使用的是市场上常见的通用的解决方案,各个公司可能都在使用,往往不具有复杂度。支撑域的系统在复杂度上不好评判,有的公司使用常见方案来满足业务需求,有的公司则为了提供更高的竞争力,独自研发支撑域系统。核心子域是最重要、最不稳定、最复杂的。公司的业务活动一切都始于业务领域:即公司运营的领域和向客户提供的服务。领域分析的一个很好的起点是分析公司的部门和其他组织单位的基本结构。在寻找子域时,重要的是识别与软件无关的业务功能,将他们从核心业务范围中识别出来,并关注与您正在开发的软件系统相关的业务方面。原创 2024-12-07 14:26:57 · 992 阅读 · 0 评论 -
领域驱动探讨
大部分架构师都是从Data Modeling开始设计软件系统,少部分人通过Object Modeling方式开始设计系统。两种建模方式并不冲突,都很重要,但是从哪个方向开始设计,对系统最终形态有很大的区别。原创 2024-12-06 13:12:57 · 991 阅读 · 0 评论 -
金融业务系统对接第三方支付/银行放款经验
人生有时就是玩笑,自从多年前面试被多家支付公司拒绝后,本身不想再接触支付这个行业,没想到人生如戏,抬头都是冤家。反正都是生活,笑着面对吧,做好每个业务使用的支付系统,怎么说我也一直是支付公司的甲方不是。原创 2024-12-05 13:53:04 · 1185 阅读 · 0 评论 -
CAP原则和BASE原则
CAP和BASE是分布式系统中最常见的两个原则,我们常见的类似的Zookeeper,Eureka中间件,MySQL,Oracle数据库,或者是我们的分布式业务系统,其实都在这两个原则当中。CAP原则一致性(C:Conistency):分布式节点之间的数据或者状态应该保持一致。比如服务注册中间件中注册服务列表应该保持一致,数据库多个从库数据应该保持一致。可用性(A:Avai...原创 2019-12-17 15:51:20 · 3075 阅读 · 0 评论 -
本地项目初始化并提交到github上
作者习惯使用GitHub来管理自己写的代码,还有一些正在学习的开源项目。遇到几次的情况都是本地完成代码后,需要提交到GitHub上,特记录如下:本地项目名gitProject,进入到项目的根目录下,执行下面的git指令://初始化项目为git项目git init//添加所有文件到git管理git add .//提交代码到本地库, -m 后面的是Commit Messageg...原创 2019-09-03 13:39:01 · 298 阅读 · 0 评论