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