I dislike the term "DMZ" because it implies that there is a single zone into which you toss things you don't really specifically trust. Lots of places in fact will just have some random switch or hub connected to another interface on their firewall, and call that their "DMZ".
I much prefer to segregate individual services into individual zones (typically a mixture of interfaces on the firewall and vlans on a switch connected to the firewall). From there I'll do a mixture of symmetric natting or direct routing with ACLs / firewall rules on a per service / per server basis. If you're an FTP server, you get ftp related access; DNS server? You get port 53, etc. But I never put the ftp server and the DNS server on the same broadcast domain.
For me the point of a "DMZ" is mostly to act as a single point to monitor and regulate traffic, it isn't just to block traffic. You setup policies based on the service and you have a single chokepoint to setup your logging, monitoring, and filtering.
Of course, if you do wind up having to nat directly into your corporate network for whatever reason, at least you can still monitor the logs for that specific rule that brings the traffic in, and monitor that specific host a bit more closely than the others. Ideally though, you can just move that server into the DMZ as well and just allow more access from inside the corporate zone into that service zone than would be allowed from outside; this gives you 100% visibility on the traffic generated by that host so that if it is compromised by the internet facing service, you quickly see that it is from the traffic logs.