在领域驱动设计（Domain-Driven Design, DDD）中，分层架构模式通常包含表示层、应用层、领域层和基础设施层，各层之间有一种明确定义的关系和依赖性。这种分层设计有助于实现业务逻辑与技术细节分离，让开发人员能够聚焦于领域逻辑的设计和实现。

依赖管理策略

1. 依赖方向：依赖关系由表示层向领域层和基础设施层单向传递。表示层依赖应用层来处理用户请求，应用层又依赖领域层来实现业务逻辑，而领域层和应用层都可能依赖基础设施层来访问外部资源如数据库或其它服务。
2. 接口和抽象：为避免紧耦合，各层之间的通信应通过接口或抽象类完成。例如，领域层可以定义一些数据访问接口，而具体的实现则由基础设施层提供。这种方式允许领域层不需要关心数据具体如何存取，从而达到解耦目的。
3. 领域服务：对于那些不直接属于任何实体或值对象的功能，可以抽象成领域服务。这些服务位于领域层，但为了保持领域实体的纯净，领域服务通常不会直接持有个体的实现细节，而是通过接口或抽象类进行交互。

避免‘贫血模型’的问题

‘贫血模型’是指领域对象缺乏足够的行为，仅仅包含属性和getter/setter方法，使得领域逻辑分散在应用程序的各个角落，这与DDD中推崇的丰富领域模型背道而驰。避免‘贫血模型’的方法有：

1. 丰富领域对象行为：将相关的业务逻辑封装进领域对象中，使得每个对象不仅仅是数据的容器，同时也实现了与之相关的逻辑。例如，一个Order对象不应该仅仅包含诸如产品列表、总金额等字段，还应该有如addProduct()、calculateTotal()等方法来完成订单相关的业务操作。
2. 领域事件：通过领域事件来响应领域内的变化，而不是在外部监听并响应。这有助于将业务规则的执行点保持在领域模型内部，例如，当一个订单状态改变时，可以通过发布一个OrderStatusChanged事件来触发一系列的后续操作，而这些操作的实现细节则由监听该事件的服务负责。
3. 领域服务：如前所述，对于不适合放入实体的行为，可以通过领域服务来封装。领域服务同样遵循领域逻辑，但不直接包含在任何特定的对象中，而是作为一个独立的服务存在，帮助协调多个对象间的工作。
4. 重构现有模型：如果已经存在‘贫血模型’的代码库，可以通过逐步重构，将业务逻辑从应用层或基础设施层迁移到领域对象内部。这个过程需要细心规划，确保不会因重构引入新的问题。

综上所述，在领域驱动设计中采用有效的依赖管理和避免‘贫血模型’的策略，可以构建出更加健壮、易于维护且符合业务需求的软件系统。