This is a very glib answer, but getting right to the heart of the matter:
In terms of DDD maybe think of reporting as a Bounded Context?, so rather than thinking in terms of "THE" domain model, you should be willing to think that it's okay to have more than one model. So yes it's okay if the reporting domain has reporting business logic in it, just as it's okay for the transactional domain to have transactional business logic in it.
As to the question of, say SQL stored procedures vs. domain model in application code, the same pros and cons apply for the reporting system as for the transactional system.
Since I see that you added a bounty to the question, I read the question again and noticed that you are asking for specific resource on this, so I thought I'd start with suggesting that you look at other Stack Overflow questions on the matter, and I found this one https://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting
The general gist of that one is to use CQRS as a pattern for your system, which is consistent with DDD, and rely on the query side responsibilities as a way to get reporting done, but I'm not sure that is a helpful answer in your case.
I also found this http://www.martinfowler.com/bliki/ReportingDatabase.html, which I found linked from here: http://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/topics/2261
Here's an interesting article from ACM on the matter: http://dl.acm.org/citation.cfm?id=2064685 but it's behind a paywall so I can't actually read it (not an ACM member :( ).
There's also this here answer on a similar question: https://stackoverflow.com/questions/3380431/cqrs-ddd-synching-reporting-database
and this one: http://snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/
Hope this helps!
You can have a common BLL component, exposed as a web service quite happily. Simply expose 2 interfaces on the WCF side of things that are implemented by the same methods in the BLL. Both thick clients and the MVC website will make calls to this common WCF webservice, but each using a different interface.
So you have a Website only web service the web site can call, and another one for the thick clients. Only allow the website devs to access the first service by not giving them the security keys to access it - you'll have some form of security to prevent unauthorised users but you'll also have some for of security to restrict access to rogue applications too.
Best Answer
MVC was originally designed to solve the problems in architecting GUIs. It decouples the process of extracting data from the model in order to present it from the process of presenting it. Basically it is an application of the Single Responsibility Principle to GUIs.
This has a number of large advantages: it takes away the need to have logic code from the presentation layer and it makes the controllers testable, thereby increasing quality and reliability. Early web GUIs, like classic ASP, had logic code embedded in HTML pages which was hard to maintain and just made you feel dirty.
The
Modelis basically a black box representing the application and its data, and will typically be an n-tiered application. TheViewis to display the data from the application and typically pass commands and data back to update the application. TheControllermediates between theModeland theView, presenting data to theViewand commands to theModel.So the
Modelis, as you say, the business rules or domain (or it could just be a database), but the entire architecture - Views to present data and Controllers to pass data and commands back and forth between the Model and the Views - is very much a GUI framework.