写点什么

架构师训练营第 2 期 第 10 周总结

用户头像
月下独酌
关注
发布于: 2020 年 12 月 28 日

1、我也遇到过不少这种情况:需求越提越多,即使砍掉部分实际不是需求的需求,项目内为此变更的代码也日益增多,甚至很多时候将错就错变成了成本最低的方案,项目失去原样。这就是课程说的,设计没法维持原来的逻辑一致性。等到积重难返,不得不重构,若仍然不改变指导思想,只是死循环。


2、领域驱动设计,是重视了上面的这种场景,提出的解决思路,要从源头把控,把项目能够约束在合理的框架内。从(业务需求)领域出发,划分为多个子类,且划分原则,以及未来目标都是子类领域概念要始终保持一致。关于这些个子域的边界,则用限界上下文控制。从编程的角度来讲,编写抽象方法,子类继承会引用去实现,是稳定的;而重新新增处理方法的,或者违背里式替换原则的,极具个性化,不稳定。


3、注意重点是从业务上提取而来的需求,而不是业务本身。


4、但要不要用微服务?

微服务不是万能的,我们想要将系统模块解耦,但没法先入为主,为微服务而微服务。

前提是必须能重构出独立业务模块,然后纳入技术因素考量,判断服务划分出模块的可行性。商讨过程中如果发现存在服务功能因需求多变,谨慎处置该部分。


用户头像

月下独酌

关注

还未添加个人签名 2019.07.22 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第2期 第10周总结