I just read Vernon's book "Implementing Domain-Driven Design". What I couldn't find is where to put your Domain Event's classes.
In the same namespace as your aggregates?
In a sub-module like <aggregate-namespace>.Events?
Or a hybird: same namespace but a physical Events subdirectory
It's not a big concern but it would be nice to know what some of you did and how it worked out.
Thanks in advance!
My understand is that the domain events should be in the domain layer (so the Domain project/assembly if you use .NET).
Where in the domain layer depends on how you structure the the project. Some do technical grouping, some do aggregate grouping).
Example (technical grouping):
Domain
📂 Events
📄 InvoiceCreated
📂 Models
📄 InvoiceModel
📄 OrderAggregate
Example (logical grouping by aggregate):
Domain
📂 OrderAggregate
📄 OrderAggregate
📄 InvoiceCreated
📄 InvoiceModel
Then in the application layer you place the domain event handlers.
Application
📂 Controllers
📂 EventHandlers
📄 InvoiceCreatedHandler
📂 Models
📂 Views
For my service bus messages I have a separate assembly (being in the C# world) along the lines of MainNamespace.Messages. Any domain events that need to go across the wire would be in that assembly also.
If, however, you intend mapping the domain events to service bus events the domain events could be in the domain assembly.
Related
There is a client-service application that uses WCF to build service-oriented architecture and DDD to build domain layer inside the service.
In the Domain Layer there is a domain object Customer with methods:
to change Phone and Address Customer.Relocate(Phone, Address)
to assign Sales Manager to a Customer Customer.Assign(SalesManager)
to make Discount to a Customer Customer.Make(Discount)
Since this Domain Layer is used inside a WCF Service, CustomerService is created with service methods:
CustomerService.Relocate(CustomerID, PhoneDTO, AddressDTO)
CustomerService.Assign(CustomerID, SalesManagerID)
CustomerService.MakeDiscount(DiscountDTO)
These methods validate parameters, request domain objects and invoke domain object methods to apply business logic.
The problem is that it looks like huge code duplication, since WCF Service methods are almost (90%) identical to methods of domain layer with parameters, expressed in IDs and DTOs.
Is this method duplication always happening when WCF / SOA is used with DDD?
Is there any way to make this thin WCF Service layer build automatically from Domain Layer?
Any other ideas?
This is by design. With DDD, domain logic is separated from application logic. Thus, there is no code duplication, because the two layers have different responsibilities.
Code that potentially could be duplicated are the validation rules: They are usually used in the domain layer to enforce invariants, and in the service layer to perform input validation. If this is the case in your application, you should refactor your code to remove the duplication and make the validation rules reusable. See also this answer.
If the problem that your software solves is so simple that the above still feels like repetitive work, DDD is probably not the right approach.
I am designing an enterprise solution which consists of modularized products within a product range using Entity Framework code first to define the domain model and provide the data access.
e.g. Solutions:
ProductRange.Authentication
ProductRange.Gateway
ProductRange.OrderSystem
ProductRange.MarketingSystem
Each of these products (solutions) will have similar layers, currently:
Projects in each solution:
ProductRange.OrderSystem.Model (contains code first POCOs)
ProductRange.OrderSystem.DataContext (contains the dbContext)
ProductRange.OrderSystem.DataAccess (contains the Generic Repository)
ProductRange.OrderSystem.Service.DomainLogic (contains business logic)
ProductRange.OrderSystem.Service.ApplicationLogic (contains application logic)
ProductRange.OrderSystem.Presentation.AdminWebsite
ProductRange.OrderSystem.Presentation.CustomerWebsite
Some of the products will need to access the domain logic of another product, especially they will all need to access the ProductRange.Authentication but also ProductRange.MarketingSystem will need to query ProductRange.OrderSystem
I am thinking to expose the domain logic between products in the range via a WCF service.
But I will also need to reference the product locally (e.g. creating project references).
How should I go about implementing this? Should I create a WCF service e.g. ProductRange.OrderSystem.WCF which calls the domain logic and exposes it or should my domain logic itsself be a WCF service? If the latter, would I always have to reference my domain logic via the WCF, even from the local ApplicationLogic?
I guess I am looking for some guidance about what layers to have and how best to provide inter connectivity between the solutions.
You can use a single( or multiple) layer to expose your pocos as datacontracts and service contracts.
for example:
ProductRange.Server.DataContracts
Product
AuthenticationInfo
ProductRange.Server.ServiceContracts
IOrderService
IAuthentication
Auth(AuthenticationInfo info):AuthenticationResult
ProductRange.Server.Services
OrderService
AuthenticationService(implements IAuthentication interface)
In the client side you can refer this project(only data contracts and service contracts) and create transparent proxy over interfaces like:
var serviceProxy = SomeHelper.CreateServiceProxy<IAuthenticationService>();
var result = serviceProxy.Auth(new AuthenticationInfo());
In addition: you can use your poco classes as a data contracts. If you want to better connectivity then you choose a binding(like a net.tcp) for your requirements.
I have a WCF service layer in my application that passes DTOs to UI.
Where is the best place to place my DTO classes in the project, should they have different folder called DTO or is it OK to place then in the folder in which the service using them is located?
Put them in a separate assembly (notice - not just a folder, a dedicated assembly) which both the UI layer and the Service layer can access. I usually call this layer Entities, and it BTW usually contains other things also.
Put your Service DTOs in a seperate Service.Dto project that should live at the SIL. Also, your phrasing probably confused people when you said "passes DTOs to UI". You probably meant passes DTOs to service clients.
I've got SOA which processing data for diff clients(asp,sl). The base of this design is domains of my business model. For transporting,showing it to clients I use DTO. For mapping domain to DTO I use AutoMapper. Now I should persist new entities from clients. I want use my DTO's at this scenario too. So i've got some questions as I'm not much familiar with this design
1) Is it a good practice build DTO on client and send it to web-service on the wire? MayBe i should pass my domains?
2) Is it possible have several DTO's to one domain (one show at grid, and one to save). For saving I need set all nonprimitive props at client.
3) DTO -> to Domain. If I've got int can I use AutoMapper to generate NHibernate Proxy for this ID, or I should do i manually.
Your expierence and practice are very interesting.
Thanks for answer!!!
A good practice to use is screen and command specific DTOs.
An example of this would be when the user is looking at a customer display screen there is a single DTO which contains all (or most if you need to lazy load some stuff) the information for that customer.
The value of this technique is that the data can come from multiple sources which allows you to model your domain as makes sense to you as opposed to how your screens are setup. It also allows you to change your domain without worrying about your screens as you just need to update the mappings.
Depending on your programming language there may be tools such a AutoMapper (for C#) which allow you to easily create the mappings between domain and DTOs.
Your architecture gets more flexible using DTOs over the wire, in stead of domain model entities. You can have several DTOs per domain.
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.