Is this "anemic" model acceptable design?

I first want to say that I am not trying to accomplish a domain model in my current design.

That being said, I currently am building an architecture that looks like the following:

UI DTO <=> Service DTO <=> Business/Database DTO (using AutoMapper)

I have been reading Eric Evan's DDD book, and have also watched Greg Young's 7 reasons why DDD projects fail, and am afraid of the anemic model. Even though I am not prescribing to DDD, I do not want to create too many layers that it becomes a pain to keep mapping very similar things back and forth.

However, the whole reason that I have the setup that I do is two-fold. Ease of change and obscurity

• Ease of change: If my public objects are exposed via my service, and I use the UI and business objects internally, then I much more free to make changes without breaking existing APIs. But, maybe I can use the one DTO and refactor if the DTO's begin to deviate?
• Obscurity: I can expose my public objects, but not expose my full objects and their implementations if they are internal. This is going to need to be a secure product, so I am preparing for that. But, maybe again I can just refactor that later?

So, my question is this: Does my current model make sense, or am I asking for problems later on? Is it ok because these objects are primarily DTO's? Even in Evan's book he implied that this model is ok if it is planned to be distributed over different servers? So, is my layering ok for this reason alone, as I plan on having the UI,Service, and DB layer capable of being on different servers (they arent currently due to no current need)?

I am just trying to be aware of over-architecture, but at the same time trying to avoid under-architecture.....so, is this model structure good or bad for my current implementation?

This is the pattern my team uses for development using ASP.NET MVC and WCF, where your business/database dto maps to an entity framework class, your service dto maps to a POCO class/DataContract passed into/out of the WCF service and your UI dto maps to an MVC model.

While this might seem redundant, rarely do the needs of each layer lend themselves to a design where all three dto's in a stack have the same properties. One example where they tend to be different is in foreign keys into lookup tables. In the database layer, this will be represented by an int, while in the service layer, this will be better modeled as an enum, so as to impose type safety, and lastly, in the ui, said field will be converted into a localized string for display to the user.

In regards to your fear about over architecting, there is something to be said about keeping things simple. The forces that would drive me to use this pattern are that I have a need to deploy my application layer independently of my ui or simply that I work on a team with more than two developers. As your team grows, the likelihood that a team member will decide to bypass your business layer and go directly against the database goes up significantly. In doing so, they invariably defeat the purpose of any Aspect-Oriented Programming you have in place - I.e. stuff doesn't get logged or wrapped in transactions. Adding the extra layer and moving it to a separate server creates a clean separation of concerns, and, more importantly, enforces it. A one or two person team may be disciplined enough to avoid this, but, as you grow, it becomes a necessity rather quickly.

Hope that helps!