Is it possible to use DDD and a rich domain model if your application is like:
windows client (WPF)
windows service
And communication happens with WCF?
I'm used to have DTO's with only data state, and have business rules inside the Service layer, but everyone keeps telling me that I should have a rich domain model where data state and rules/methods are all in the objects themselves.
I'm just not sure if this rich domain model would apply to a system that has a UI and communicates via WCF to a service (like I presented above). In my case is it better to continue using an anemic domain model because of WCF? If not, could you please give an example on how to architecture it using a rich domain model, considering WCF, proxy, etc?
Thanks!
Generally speaking you serialize your domain objects for transmission across WCF as some simplified DTO anyway, and it's these that are consumed by your client application.
You can serialize user defined types and deserialize them in the client but for most applications this is unnecessary. As long as you don't need the 'rich' behaviour of your objects in your client (which you shouldn't with a good DDD anyway), it sounds to me like you are fine to use a rich design in your service layer and send simple DTOs across the wire.
Related
I'm developing a server side application based on DDD.
My application service (wcf layer) has a method which received an XML from the client.
This XML needs to be processed and finally transformed into an object.
In such a case, where's the best place to put the data transformation logic?
Inside the domain model?
Example:
void OnRequestArrived(string xml)
{
ItemRequest request = ItemRequest.New(xml);
}
or in a separate domain service?
void OnRequestArrived(string xml)
{
ItemRequest request = _mappingService.Map(xml);
}
The ItemRequest object is then the main domain model for the business flow..
Thanks
This responsibility belongs to the WCF service. In DDD terms, this is the anti-corruption layer - it maps external models to the domain model at hand. The domain model should be protected from external services as much as possible.
Sometimes it can be convenient to break this single WCF service into two - an application service and a WCF-specific adapter which would adapt the application service to the WCF framework. This is based on the Hexagonal architecture. The application service knows nothing about WCF or serialization formats. The WCF adapter service handles this and other serialization concerns. This can be useful for two reasons. First it keeps your application service clean and focused on its responsibility - the orchestration of domain objects, repositories and other services to implement domain use cases. Second, it allows the same application service to be called from different adapters.
I am building a WCF service.
The Data Contract objects will be the exact same as the Business Objects.
Should I create Data Contracts in my WCF service or reference my BO Layer and use those Business Objects in my WCF Operations?
I would split them in different projects:
Foo.DataContracts
Foo.BusinessModels
Foo.Services
Reference BusinessModels and DataContracts in Services. Then map the model classes to contract classes using AutoMapper and vice versa. You can then later change your models without breaking your WCF clients, since they rely on the contracts.
If your business objects can be serialized without muddling the concerns of serialization in with the business logic, then I'd say go for it.
A better alternative though is to bring your business logic layer behind the Services layer and expose simple DTOs from the service that your view can bind to.
I wrote an article on this approach with WCF RIA Services that translates pretty well to standard WCF Web Services
I think in the same line of #valpolushkin though I have not used AutoMapper till now.
See my answer in WCF Message & Data Contract, DTO, domain model, and shared assemblies for an example where the use of Business Entities as Data Contract can cause breaking changes.
I think, it is a very bad practice to use Business Objects as DataContracts. The Service need to be autonomous. The service may be used by clients that has / has not got Lax Versioning.
Refer Service Versioning.
It is easy to mistakenly believe that adding a new member will not break existing clients. If you are unsure that all clients can handle lax versioning, the recommendation is to use the strict versioning guidelines and treat data contracts as immutable.
Also, refer MSDN - Service Layer Guidelines
Design transformation objects that translate between business entities and data contracts.
I have business layer and UI layer in separate projects within a same solution. What i need is ,connect this UI with business layer which coded in c#. UI created using MVC3 Razor.
What i should use as model in MVC application? am i need to create Service reference to business layer to generate some proxy?
then can i use those proxy as a model? please help me..
if you can provide me some tutorials
i tried this but no more idea with MVC :
http://www.dotnetfunda.com/articles/article816-understanding-the-basics-of-wcf-service-.aspx
Unless your project (or architect) demands that all methods of your app access a services layer, I would try and avoid using WCF unnecessarily (think of it - it means that all of your data between web server and back end goes over the wire, which has implications such as performance, serialization of data, and also potentially limits the lifespan of database connections and transactions, which can deprive such as lazy loading).
If you concur, the suggestion would be to ensure all accessible interfaces in your business layer are exposed on an interface, and then consume or inject the BLL interface directly into your controller.
You need to be careful about the word "Model" in MVC - ASP NET MVC encourages ViewModels, which are specific to the presentation tier and passed between Views and Controllers, as opposed to "Entities" which represent the more logical domain model as used by business logic and which can be tied to data persistence using an ORM such as EF or NHibernate. The MVC project template lumps everything which isn't View or Controller into "Model" which isn't necessary very helpful.
However, if you do choose to access your BLL via a WCF Services layer you still have some design decisions to make:
Choose whether you share the back end entities on the client side, or do you instead use proxied entities.
Choose whether you consume / inject the WCF service proxies directly in your controller, or do you create another facade layer (e.g. CAB calls these ServiceAgents). The latter would make sense if there are separate teams or vendors building the SOA side vs the Client side in order to accomodate changes to interfaces.
I have an existing set of Services and Repositories I use in an MVC application that leverage the Entity Framework 4.1 Code First.
I want to create a couple of WCF Services that use the existing architecture, but it seems to have a hard time serializing the object graphs.
I realize that there are some circular references to deal with, but I really don't want to litter the Domain Objects with WCF attributes, so should I just create View Models like my MVC app uses? And if so, should I create the View Models to be able to be used in both?
Any other ideas? - Thanks!!
I prefer keeping my domain model and the WCF data contract separate by defining Data Transfer Object classes as the data contact of the WCF server. They are tailored specifically to carry the right data across the wire. A good DTO design will keep the number of WCF service call roundtrips from the client down. It will also separate your internal domain model from the contract with the client.
I need some help clarifying how I should be setting up my project. My solution structure is as follows:
Company.DataTransferObjects
--AdminDTO.cs
--CustomerDTO.cs
Company.DataTransferObjects.Helpers
Company.Infrastructure.DomainServices
--Admin
---AdminService.cs
--Customer
--CustomerService.cs
Comapny.Infrastructure.Repositories
--Admin
---AdminRepository.cs
--Customer
---CustomerRepository.cs
Company.Domain
--Admin
---Admin.cs
---IAdminRepository.cs
--Customer
---Customer.cs
---ICustomerRepository.cs
Company.WebServices
--WebApi.cs
--IWebAPI.cs
My questions are as follows:
1) Does my set-up look right to you?
2) DTOs. From the web service's perspective, where should the DTOs be created?
Should I be creating the DTOs in an independent class library and referencing
them from the WebService or should they be part of my web service project?
Also, it is not clear to me how my DTOs should be interacting with my Domain objects.
Can somebody please explain their purpose from a program flow point of view and, specifically, if you were creating a WCF service how you would be manipulating them?
3) Domain Services. I am still having a hard time wrapping my mind around the purpose of Domain Services. Is this what is exposing the operational functionality that is not hitting the database and requires repository methods that cannot be accessed directly?
In other words, is a Domain Service a method that manipulates multiple repository methods? So, if my WCF service is calling data that can be accessed via a repository method, then that is what it should do. But, if it requires data that is the result of multiple repository methods, then this should be done via domain services?
4) Where does the Facade Pattern fit in a the DDD architecture?
Please excuse my confusion, I am trying to understand. It would be a serious help if you could tell me "what" I should be accessing from my WCF service.
Thanks!
going in reverse order on your questions:
4) Your web services are a facade to your domain, effectively.
3) Domain services can hit the DB too, they're typically the main API that consuming code should use to talk to your domain on anything that involves more than a single entity, or for things that represent a series of transactional steps. Some folks consider Repositories to be a special case of Domain Services (Rather than being an either/or). I usually consider my Services to be my domain's public interface.
2) DTO's are normally useful when you are (or plan to eventually) crossing physical boundaries. Anytime you think you might need to serialize something (e.g. into a SOAP message), you want to think about a DTO. SO in your case, your WCF project would use DTOs as its DataContracts, but internally it might use your domain objects (unless you expect your domain to sit in a different app domain or on a different physical box).
1) It's all personal preference; your layout doesn't look unreasonable, though it's different than how I normally organize.