Olá,
Para mim, Domain Model é um conceito não exatamente um padrão.
num Domain Model você deve mapear entidades do seu processo (físicas ou abstratas) num modelo de classes que colaboram entre sí.
Segundo estes princípio, um sistema com requisitos de caixa de banco pode ter a estrutura que você, falou, mas lembre-se que tudo depende do ponto de vista do sistema. O sistema pode tratar todos os clientes como uma coisa só, sejam empresas multinacionais ou assalariados, ou pdoe ter um modelo onde estas entidades têm caractéristicas diferentes em dados e comportamento (não no valor dos seus dados, mas, por exemplo, uma regra de empréstimo muda).
Até aí tudo se parece muito com uma estrutura de entidades num SGBD (exceto pelas regras). A diferença é que objetos são ativos e não passivos como tabelas. Eles colaboram entre si, não ficam pulando de função em função, não se expõem aos outros mais do que devem (sua interface).
No livro, Fowler recomenda que você evite criar um modelo destes para aplicações muito simples (porque só o trabalho de modelar um domínio seria maior que a aplicação em si IMHO, como em muitos softwares CRUD que existem).
Tendo suas classes que realmente efetuam as ações do seu sistema, você pdoe definir Façades para sua lógica de negócio, evitando que seus clientes (um front-end gráfico, uma aplicação web, um outro sistema) saiba como os objetos estão implementados. Isso é o embrião de uma camada de negócios/domínio.
Modelar um sistema com objetos simples que se relacionam para cumprir tarefas é perfeito para realizar testes unitários e verificar se seu sistema está fazendo o que devia mesmo antes de se pensar numa arquiteutra de banco de dados ou uma interface de usuário para ele. Apenas crie casos de teste que manipulam seus objetos como você quiser.
Associados com Data Mappers (famigerados DAOs segundo a Sun), que recebem objetos de domínio a serem persistidos, um Domain Model bem feito constitui a camada de negócios de um sistema orientado à objetos atualmente.