现在我们有一个项目，客户端主要分为两类功能，一类是许多类似网站后台似的管理程序，主要是增删改查，感觉用bs更好，另一类是完成图像处理的功能，其交互复杂性和计算要求更适合采用CS程序，而且整套系统中数据流转时bs程序和cs程序有很多业务数据是相关的，需要公共访问的类、接口等。
这时问题就来了，Entity一般都不是贫血的，包含了很多业务方法，但这些方法依赖于service、specification、valueobject等等领域概念，而且有的方法会调用基础设施的，这些基础设施可能根本不在客户端上，那我们B端和C端都要访问Entity，就会出现有的方法能够调用，有的方法根本不应该调，这Entity简直没法设计...
而且持久化的时候repository又不应该直接暴露给每个客户端，因为对于每种Entity全局应该只有一个仓库，所以可能要把这部分功能用webservice等远程访问方式封装，怎么感觉是支离破碎的呢。。。
换过来如果采用贫血模型，c端写一些面向过程式的业务逻辑，访问Entity，然后调用服务端，让服务端的repository维护一下持久化，也不会因为调用Entity的方法访问根本不在本地的基础设施了，但这样一来B端又很郁闷，因为Entity都是贫血的。。。！那还怎么用DDD，岂不是要事务脚本了？
上一个项目是纯BS架构的，应用DDD还是不错的，虽然有些设计还比较幼稚，但还是比以往面向过程、面向DB的思路写出来的程序好，可读性、可维护性、可扩展性都好了。
这次这个项目不知道该怎么办了，难道要回到老路上去吗？？？？