【架构师成长之路】

项目中的“坏”味道

1. 可维护性差：大量的第三方模块影响核心代码的稳定性
2. 可扩展性差：业务逻辑与数据存储相互依赖，无法复用
3. 可测试性差：庞大事务脚本与基础设施强耦合，无法单元测试。
   最后的结果：业务发生几次迭代后，这段代码就将成为一个可怕的黑洞。

1. 如何构建高质量应用？

高内聚、低耦合

2. 三大设计原则？

1. 单一职责原则：一个类只负责单一职责，另一种理解也就是一个类应该只有一个引起它变化的原因。
2. 开放封闭原则： 对扩展开放，对修改关闭。
3. 依赖反转原则：程序之间应该只只依赖于抽象接口，而不要依赖于具体实现(java特性-多态体现)。

3.DDD妙招

1. 使用充血模型的实体对象，描述核心业务能力。

系统能做什么事情，一目了然。

public class Account {
	private Long id;
	private Long accountNumber;
	private BigDecimal available;

	public void withdraw() {
		// 转入操作
		available = abailable + money;
	}

	public void deposit(BigDecimal money) {
		//转出操作
		if (available < monrey ) {
			throws new InsufficientMoneyException();
		}
		abailable = available - money;
	}
}

充血模型(引起实体变化的因素放入实体中) ——> 贫血模型POJO（Martin Fowler 提出）MicroService ——> 贫血失忆症

public interface AccountRepository {
	// .....
}

public class AccountRepositoryImpl implments AccountRespository {
	@Autowired
	private AccountDao accountDAO;
	@Autowired
	private AccountBuilder accountBuilder; // 仓库工厂

	@Override
	public Account find() {
		AccountDO accountDO = accountDAO.selectById(id);
		return accountBuilder.toAccount(accountDO);
	}
	@Override
	public Account find(Long accountNumber) {
		AccountDO accountDO = accountDAO.selectByAccountNumber(AccountNumber);
		return accountBuilder.toAccount(accountDO);
	}

	@Override
	public Account save(Account account) {
		AccountDO accountDO = accountBuilder.fromAccount(account);
		if (accountDO.getId() != null) {
			accountDAO.insert(accountDO);
		} else {
			accountDAO,update(accountDO);
		}
		return accountBuilder.toAccount(accountDO);
	}
}

2. 构建防腐层 隔离外部服务(众人皆醉我独醒)

public interface BusiSafeService{
	// ....
}

public class BusiSafeServiceImp implements