Which layer for custom type (DDD)
https://softwareengineering.stackexchange.com/questions/363272
-
25-01-2021 - |
题
If I have a custom type (or maybe an enum) like for ex. a Range
:
Public Class Range
Sub New(minimum As Single, maximum As Single)
Me.Minimum = minimum
Me.Maximum = maximum
End Sub
Public Property Minimum As Single
Public Property Maximum As Single
Public ReadOnly Property Delta As Single
Get
Return Maximum - Minimum
End Get
End Property
End Class
'-----------
'Some methods...
This type should be used in the domain model(implementing DDD), in the business logic when doing stuff and also in the data layer, where it will be stored as a complex type.
So :
- should I define such classes in a Project
App.Common
and reference this assembly everywhere (my choice for now, but don't know if having references in domain model project is an anti-pattern?) - should I define it in my domain model and reference my domain model everywhere where it is needed. (maybe better? since Domain model is core in DDD, but the type is not a domain or value object...)
- should I create different classes for each layer (which don't make sense to me, since I want to handle it like another type and not as Object)?
EDIT
In my case I use range
as a MeasuringRange
for measure devices. For ex. a thermometer that can measure from 0°F-250°F:
public class Thermometer
{
public Thermometer(Range measureRange)
{
this.MeasureRange=measureRange;
}
public Range MeasureRange {get;set;}
}
At the moment it's also used in the DataLayer (using EF Code First) to store the device range as a complexType (EF creates fields MeasureRange_Max
and MeasureRange_Min
.
It's also used in services in the BLL when doing some measurements with the devices.
解决方案
I don't believe that there is an authoritative answer to this.
My guess is that we should treat Range
as a sort of domain agnostic convenience for implementation. It's somewhat analogous to System.Collections in that regard.
Also, it seems like that the application component might want to use it even if the domain component does not (and vice versa), which implies that it belongs in a separate component that they might both share.
should I define such classes in a Project App.Common and reference this assembly everywhere
This is the approach that makes the most sense to me.
should I define it in my domain model and reference my domain model everywhere where it is needed.
Probably not - the domain model is a lot of weight to pull in for a library. Unless Range
and Delta
are part of your domain language, the dependency is really an implementation detail that should not be obvious to the clients of the domain model.
should I create different classes for each layer (which don't make sense to me, since I want to handle it like another type and not as Object)?
I don't see much advantage there, in the same way I don't see an advantage to duplicating a collection across multiple components.
其他提示
One big idea in DDD is that the Domain layer does not depend on any other layer (i.e. Presentation, Infrastructure, Application etc). This rule exists so this layer contains pure, easily testable, side effects free, business logic.
But, in order to implement this business logic, we need to use and re-use some basic classes like lists, email addresses, ranges (like yours), time intervals etc. These classes, although there are not from the Ubiquitous language, they are important supporting constructs. They keep our code DRY.
According to the DIP, the Domain layer should own these constructs. This implies that they should reside in the Domain layer. You can put them inside a nested directory, something like Domain/Base
, in order to separate them from the Entities
, Aggregates
and Value objects
but to keep them close.