背景:
最初,设计了一个简单的需求,然后不断的增加需求,向复杂的真实世界靠拢,而代码修改又是在原有基础之上。
==》软件的业务由简单转变为复杂
正确的做法:
1.两顶帽子
每次新需求,首先要调整程序结构,该解耦的解耦,该拆分的拆分,再实现新的功能。这样才能保证代码质量。
每一次设计都为当次需求进行设计,使其刚刚好满足当前的需求。
2.开放封闭原则
功能扩展是开放的,代码修改时封闭的,即不在原有代码上直接修改,而是新增一个地方。
微服务,DDD的关系:辅助
微服务设计原则:小而专。
DDD思想可以解决“专”
整洁架构
案例
先进行需求分析,设计领域模型
订单操作:下单、付款、查看订单状态…
新增折扣的需求
付款和折扣的关系?
单一职责原则
将软件变化是由于同一个原因的代码放在一起
即,修改需求,只需要更改一个模块。
过去,职责的理解,做一件事,与这个事情相关的所有事情都是它的职责范围内。
当付款变化时,折扣是不是会变?不是
当折扣变化时,付款是不是会变?是
当限时折扣变化时,限量折扣是否会变?不是
当限量折扣变化时,限时折扣是否会变?不是