asp.net-mvc – 提供DDD,但需要一些其优点

我放弃传统的DDD，这往往是一个巨大的时间，并强迫我做无尽的映射：数据层<域层<表示层。 即使是一个小的变化，我必须改变数据模型，域模型，演示模型/视图模型，然后存储库，管理器/服务类，当然还有AutoMapper映射，然后测试整个事情！每个呼叫都需要调用一个调用一个调用底层代码的层的层。除了“你以后可能需要”之外，我没有得到任何回报。咩。 我目前的做法更务实：
>我不用担心“数据层”和“域层”之间的差异，因为没有意义 – 这些术语是可以互换的。我让EF做它的事情，并在需要的时候添加界面和存储库。
>我已将我的“数据”和“域”项目合并(“核心”，无聊的名称，我知道)，我几乎可以发誓Visual Studio实际运行更快。
>我允许EF实体上下栈，但是我仍然像往常一样将它们映射到演示模型/视图模型。
>对于简单的操作，我直接从控制器调用存储库，对于复杂的操作，我照常使用域管理器/服务;存储库从不暴露IQueryable。
>我将实体/ POCO定义为部分类，因此我可以在相应的部分类中单独添加域行为。

问题：我现在使用这些实体，所以客户端代码可以看到他们的导航属性。模型在他们离开存储库后总是实现的，所以这些导航属性通常是空的。

可能的解决方案：
与它一起生活这是丑的，但比上述问题更好。
2.对于每个实体，定义隐藏导航属性的接口;并使客户端代码使用接口。但讽刺的是，这意味着另一层(虽然薄而易于管理)。
还有什么？

我不习惯这种快速和松散的编程风格，所以也许我缺少一些明显的技巧。还有什么我应该考虑的吗？我确定还有其他问题我很快会遇到。

编辑：
这个问题不是DDD。并注意到许多与传统DDD方法的斗争 – Seemann appears to到the same conclusion，Rahien speaks about the “Useless Abstraction For The Sake Of Abstraction Anti Pattern”，Evans自己说DDD在5％的情况下才是真正有用的。还有see this thread.有些评论/答案是可以预测的，我如何做DDD错误，或者我如何调整我的系统做正确的。但是，我不是要求DDD或者是适合的情况，而是想知道其他人正在做的是如上所述的思考。这不像DDD是所有设计弊病的灵丹妙药，每十年一个新的过程都会出现(RUP任何人？XP，敏捷，Booch，blah …)。 DDD只是最新的，最知名和最常用的。但是，实用主义应该是第一次，因为我正在努力建立按时运送并易于维护的可销售产品。迄今为止，我学到的最有用的编程公理是YAGNI。我想要的是将我的系统改成一种“DDD-lite”，在那里我得到它的强大的设计/ OOP /模式哲学，但没有胖。