gistfile1.txt

Enterprise applications are exactly that. Large. Large applications involve many processes that are unique that may involve the manipulation of the same amount of data from various parts of the application.
A tightly coupled design of an application will cause all areas of the application to have side effects, these side effects call for hacks to fix those single points of the application, but because of this, they have a direct effect on every other part of the application that has a dependency on that part, which is the reason that tightly coupled applications are the exact opposite of how any enterprise application should be written.

They require several things. 
1) A service layer which can handle individual working components of the system. 
2) These services can take in other services that are required to act as a facade when multiple single services serve as part of a larger process or business process.
3) Interfaces that can provide well defined business processes for all components of the application.
4) A UI agnostic Core Layer that is not coupled to how the information is requested. Via a Mobile Application, A Console Application or Web application, this will allow for complete testability of the behaviour of the services.
5) Request / Response wrapper object pattern can be used in order to wrap up several objects / states that need to be processed for an individual business process. This works well with a SOA design in which multiple services of the application are in complete control of how the data is manipulated, this allows for heavy hitting high population of requests to be load balanced by having multiple services hosted on their own hardware. With internal WCF TCP bindings you can have great performance will a fully decoupled system, this is exactly how large banks work and transfer money. (Trust me, I watched a video and Scotty told me so - also it makes sense.)

This means that domain entities should NOT be the centre of the attention to behaviour of the application, domain-driven design has nothing to do with how entities are saved, created, loaded or deleted. It doesn't have anything to do with the behaviour of the application!

It is a domain-driven design that provides the structure of the application core, it does not dictate the behaviour of the application, nor should the entities control what is created, when they are created or who they create.
They are a reflection of a normalised database.

The service layer within the core of the application dictates the behaviour, behaviour which can be fully tested and mocked out via use of interfaces
and dependency injection where these interfaces can be injected into the UI layer of the application in which their usefulness can be consumed to drive the application
from a UI layer. A UI layer which could be implemented via a mobile application, a Web application or Console application, if the UI is completely abstracted away then the Core layer 
can be shared across multiple UI implementations, because the implementation should be agnostic to how it's interacted with. Ideally, the exposure of the Core should be via WCF Services or Web API.

Domain entity objects should never see the light of day via the UI tier layer of the application (Only in simple scenarios would these be deemed acceptable, such as a read only list of data). 
Important or vital information should be abstracted and transferred to view model objects which can contain other information in order to help a process along the way, containing UI related data such as 
enums and lists or enable multiple entity objects to be flattened into a single view model. For large entites with complex types and various data types that can hinder UI layer related fields such as 
integer and datetime parsing, Mapping tools can be used in order to create highly structured conversion of database related entities to view models. Enterprise scaled mappers would be those such as Dozer (for Java)
and AutoMapper (.NET). They also serve well with exposing Core domain entities to services via WCF or Web API.

Giving control of an application to the domain entities is a poor and undesirable practice in large enterprise applications. They will give no control on behaviour of the application and will leave many unknown paths of execution. If multiple entities have complex relations, then each and every single entity must also take into consideration the logic of every other entity it is tightly coupled too if driving the application
logic through the entity / models via methods that are not part of a well defined facade of services.

How does one test or mock out a concrete entity with no interfaces defined. 
how does one improve performance when the entity is not only the domain object, but the source of the behaviour of the application.
How does one improve performance when the entity is not only the domain object, but is it coupled to a caching engine dependant on how the entity is saved, deleted, created via the entity instance itself.
How does one follow agile practices when the code is not written in an agile friendly way. You cannot simple change one area of an application that is not written in an agile way and expect other parts of the system to just work like they did before the change, because they wont. Agile project management will not work for applications that are not designed in an agile manner - that means allowing for abstractions, well defined interfaces and business processes, the ability to mock / stub out areas. 

WebForms is great, but without Dependency Injection in WebForms, then services cannot be applied to improve the overall development and maintenance of an enterprise application.
The MVP Pattern adopted in WebForms solves this problem but not all follow. Ninject has a great nuget package to bring DI to WebForms and those who deal with ASP.NET WebForms should look into how Master Pages, Base Page
and Controls can directly resolve dependencies via IoC.