关于领域驱动设计的一些疑问点

看了一篇文章，大约内容是实现转账业务来说明DDD设计，然后代码如下

【如下代码实现业务：查找账号，判定是否账号余额等信息，可用金额信息等，然后最大转账额判定，然后什么可用转账额判定，然后记录明细】
public class AccountingServiceImpl implements AccountingService {

public void transfer(Long srcAccountId,Long destAccountId,BigDecimal amount) throws AccountingServiceException {

Account srcAccount = accountRepository.getAccount(srcAccountId);

Account destAccount = accountRepository.getAccount(destAccountId);

if(!srcAccount.isActive() || !destAccount.isActive())

throw new AccountingServiceException(AccountingService.ACCOUNT_IS_NOT_AVAILABLE);

BigDecimal availableAmount = srcAccount.getBalance().substract(srcAccount.getFrozenAmount());

if(availableAmount.compareTo(amount)<0)

throw new AccountingServiceException(AccountingService.BALANCE_IS_NOT_ENOUGH);

srcAccount.setBalance(srcAccount.getBalance().sbustract(amount));

destAccount.setBalance(destAccount.getBalance().add(amount));

}

}


文章作者巴拉巴拉说了一大堆什么业务逻辑判定多，什么代码多，什么DDD好处多，然后修改了DDD模式，然后贴出了部分代码。
public class AccountingServiceImpl implements AccountingService {

public void transfer(Long srcAccountId,Long destAccountId,BigDecimal amount) throws AccountDomainException {

Account srcAccount = accountRepository.getAccount(srcAccountId);

Account destAccount = accountRepository.getAccount(destAccountId);

srcAccount.transferTo(destAccount,amount);

}

}

然后巴拉巴拉如下内容：
我们可以看到，使用领域驱动设计至少会带来下述优点：
业务逻辑被合理的分散到不同的领域对象中，代码结构更加清晰，可读性，可维护性更高。
对象职责更加单一，内聚度更高。
复杂的业务模型可以通过领域建模（UML是一种主要方式）清晰的表达，开发人员甚至可以在不读源码的情况下就能了解业务和系统结构，这有利于对现存的系统进行维护和迭代开发。“”



我是没看明白，说了半天文章，只看到代码从一个应用层被且到了领域的实体接口里，这就介绍完了。


我就没明白，领域驱动就是分解应用层的一些业务判定逻辑转移到领域的实体接口里（并且实现）？最终的这些各种场景判断不还是免不了这些代码么？