Are services part of domain model according to DDD? If we google for "ddd onion architecture", we can mostly see that the most inner layer is called something like "Domain Model Layer" and the second is "Domain Services", for example, [dead link, NSFW anymore] . But in https://en.wikipedia.org/wiki/Domain-driven_design and DDD book we see that that entities, value objects and services all express the model and are model elements. If entities, value objects and services are all part of domain model, how should we call those two layers of onion: model (entities + value objects) and services (as I sometimes do)? But if all are part of domain model, this naming does not seem accurate.
Are domain services part of domain model?
Yes, but also no.
In the blue book, domain services are described in chapter five; immediately after entities and value types. Evans writes
In some cases, the clearest and most pragmatic design includes operations that do not conceptually belong to any object. Rather than force the issue, we can follow the natural contours of the problem space and include SERVICES explicitly in the model....
A service is an operation offered as an interface that stands alone in the model, without encapsulating any state....
The interface is defined in terms of other elements of the domain model.
But it will not always be the case that the implementation of the domain service lives within the domain model itself.
In some cases, the domain service is really acting as a service provider, which needs to be wired to the infrastructure to perform its role (for example, sending messages to another process). So the domain model defines the provider interface, an implementation of that interface is passed to it (for example, as an argument to a method on an aggregate root), and then the model decides if/when to invoke the methods on that interface.
can entities and value objects have a compile time dependency on interfaces of domain services? Are they (entities, value objects and interfaces of the domain service) in the same layer of the domain model?
Yes, and yes. For example, here's an online sample of the shipping application from chapter 7.
public interface RoutingService {
List<Itinerary> fetchRoutesForSpecification(RouteSpecification routeSpecification);
}
Now, this particular demonstration happens to keep the domain services in a different namespace than the model, and uses an application service to bridge the two.
return routingService.fetchRoutesForSpecification(cargo.routeSpecification());
But it would be equally correct to make this part of the responsibility of the model
return cargo.fetchRoutes(routingService);
Queries give you a bit of room to play, because you don't have to worry about allowing the model to protect its own invariant. With commands, the latter approach provides better encapsulation
order.updateSalesTax(taxCalculatorService);
Are services part of domain model according to DDD?
It is part of the domain layer. Domain services encapsulates domain logic that cannot be naturally modeled as value objects or entities.
In the onion architecture, all dependencies face inward. Value object and entities should not have any dependencies on domain services. Domain services depends on entities and value object. At the heart of the architecture is the domain layer (value+entities+services). This is DDD which is an abstract view of the business/problem domain. This layer does not depend on anything like database, web services calls, smtp and other infrastructure related services.
One layer above is the application layer which depends on the domain layer. Application layer consists of application services that contain application logic to orchestrate business use cases.
Next layer is the infrastructural layer which can responsible for technical implementation of storing information, logging,security, notification and integration with other bounded contexts. This layer also enables the application layer to be consumed via web services or message endpoints.
To avoid tight coupling between these layers, the higher layer must adapt to the message types of the lower layer. Between these layers, you may use data transfer objects(DTO) so you don't pass domain objects(entities) across boundaries. Also to avoid tight coupling to specific technology(eg. database), layers communicate via interfaces.
Related
I am implementing a Hexagonal Architecture with Domain Driven Design.
I have a Value object called "Address" that has a "validate()" method.
I would like to have a default validation provider for the address that is within my domain, but also allow external users to provide an overridden validator.
So I created an AddressValidationAdapter interface that can be implemented by the outside world in "dependency inversion" manner.
My question is - what is the best way to call my AddressValidationAdapter from within my Address class ?
Do I need to add it as a dependency in its constructor ?
Should I use some sort of global / static context ?
Should I use event driven approach where I post a "ValidationEvent" within my domain and subscribe to a validation success notif ?
Should I create a Service that orchestrates everything ? (Seems not very DDD like)
Thank you very much for your thoughts.
Best Regards
Alex
You mention Domain Driven Design, which is a practice that requires all business related code to go in a domain layer, and all non-busines related code to go out of that domain layer. Other than that, DDD is more concerned by how you design and evolve your business model, not so much about application architecture. The author of the DDD concept states that it can be used with any software architecture.
You also mention Hexagonal Architecture, which addresses software architecture, and has more constraints on how you structure your code. Hexagonal Architecture defines 3 concentric layers in applications:
The domain layer validates that state changing values do not violate business rules;
The ports layer is a business representation of infrastructure interactions;
The adapters layer implements the actual communication with external infrastructure.
Hexagonal Architecture also states that type references should go inwards, which means ports are not allowed to reference adapters, and the domain model is not allowed to reference other layers. A good practice is also to forbid direct reference accross different adapters. However, this is not much of a concern in your situation.
Address validation is definitely not an adapter layer concern, because it is not related to how your application interacts with an external infrastructure or data structure. This means that address validation should not be implemented as an adapter, in the sense of Hexagonal Architecture. It is not a port either for the same reasons. Address validation should go in the domain layer, because business rules validation is the purpose of the domain layer (Hexagonal Architecture) and all business related code should go in the domain layer (DDD).
However, neither DDD nor Hexagonal Architecture state anything on how you should structure your domain layer internally, so it is up to you. If you want your application to use different validation implementations, you may want to use the adapter pattern in cunjunction with a dependency injection library. Note that "adapter", here, refers to a software engineering desing pattern that has inspired the Hexagonal Architecture concept of adapter layer, but is totally independant from it.
Since the purpose of the domain layer is to validate state changing data, there should be very little code apart from validation rules implementation and data structure. If you move the latter to a validator class, there will be little left to write in the domain model objects themselves. You are probably going to end with an anemic domain model this way. You might want to consider implementing Always Valid State domain model, where validation rules are implemented directly in the domain model's setters and constructors.
If you wrote an adapter class due to the fact that you need to retrieve external data to do the actual validation, this is a good evidence that your domain model is lacking information and should be extended, rather than violating Hexagonal Architecture constraints.
Do I need to add it as a dependency in its constructor ?
Absolutely no! Value object are data and you are putting yourself in a hell with serialization/deserialization for it
Should I use some sort of global / static context ?
Not sure what you mean, but global/static context is scary, what about multiple validation done in parallel?
Should I use event driven approach where I post a "ValidationEvent" within my domain and subscribe to a validation success notif ?
Domain events are related to entities state changes, nothing is changing when you do validation
Should I create a Service that orchestrates everything ? (Seems not very DDD like)
It could be...
but also allow external users to provide an overridden validator.
I'm very curious of the details of this, why an external user would need a different validation?
Could it be that an Address has some sort of generic validation that need to be always checked, but different use cases have more stricter rules?
If that's the case why the Address itself would need to know them? It is just a value! An Integer just know that it has to be a number if in certain usage you need it to be in a range of values it's something that you add to it, but it doesn't know about it
DI/IoC approach is good and I was thinking you could do something like:
class Address {
....
validate(AddressValidationAdapter customValidation) {
// generic validation then...
customValidation.validate(whatAreYouPassingHere)
}
}
Whatever you are using as whatAreYouPassingHere, can't the code doing:
Address address = ...
address.validate(customValidator)
just read the values needed from the address and do its own validation?
I have this classic DDD problem; I have a Domain Service "DetectPriority" that do some stuff.
PM ask me to create 2 different services; one INTERNAL ( with is FULL of business rules and involve many other Domain Models ) and another one ETERNAL ( a simple API call ).
There is a interface "DetectPriorityInterface" within the Domain.
Both Implementations MUST be active in the same time; a kind of "mixed" has to select one instead of the other in real time.
The problem is: Where do these implementations ( two implementations ) should live: in Domain Layer or Infrastructure Layer??
Internal Implementation is full of business rules and should reside in Domain Layer.
External Implementation is a simple CALL and should lives in Infrastructure.
Should we put both in Infrastructure layer?
Thanks
EDIT
Actually we have one interface "DetectPriority" and three implementations, ALL in our Domain layer ( temporary "wrong" solution ) :
InternalDetector ( with Business Rules )
ExternalDetector ( With external API call )
MixerDetector ( get both Implementations and handle the choise )
Clients use the Interface so, for Application Layer, all these stuff are trasparent; in the next, we will remove the Internal ( or External ) and Mixer and use only One Implementation. ( The idea behind all these is to understand who performs better, it is an A/BN test )
Our internal debate is: Cause InternalDetector has some domain rules that belongs ONLY to that Detector, it should live in Infrastructure layer, cause it is not an General Domain Rules. Some of us disagree with this, cause in InternalDetector we only have business rules and we don't see that in Infra Layer.
Problably the correct way should be add Internal in Domain, and External in Infra .. but it seems to be a bit confused ..
Putting all together in Infra layer would be more readable for devs...
We didn't find some stuff in books cause usually you have a single implementation of a domain service ....
The short answer is that you should implement an internal service in the domain layer and an external one in the infrastructure layer, exactly as you said in your question. This way, everything will be in its place.
An additional important thing to consider is that the code that decides which service to call should be in the domain layer too. As I can imagine from your question, you decide which detector to use using some business rule. That fact that one detector is implemented in your application, and another one is not is just an implementation detail of your system. In fact, you just decide to use one set of business rules or another one according to some condition. It is a business decision.
DDD is pretty often about difficult compromises. But when you are looking for a good compromise, I would advise never move the domain logic outside of the domain layer, and never add references from the domain layer to other ones.
This is essential.
And here is an example of how you can solve this task without violation of these rules:
// Names in this code should be changed to something with business
// meaning. For example `externalDetector` can be `governmentDetector`
// and `internalDetector` can be `corporateDetector`.
// Declare a service interface in the domain layer
public interface DetectPriority {}
// Inject both detectors in the domain service.
// Your dependency injection code should inject here
// an internal implementation and an external one,
// implemented in the infrastructure layer.
// So your DI code knows about different implementations
// but the domain service doesn't.
// For the domain service it's just two implementations
// of domain interface IDetector
IDetector _externalDetector;
IDetector _internalDetector;
// Implement the method of the domain service like this:
public Priority Detect()
{
if (weShouldUseExternalSetOfRules)
{
return _externalDetector.Detect(); // this one is implemented in your infrastructure layer
}
else
{
return _internalDetector.Detect(); // this one is implemented in your domain
}
}
In this solution you can see that:
All domain logic (an implementation of internal detector and decision which set of rules to use) is placed in the domain layer.
We don't have references to the infrastructure layer from our domain. The domain service have the reference only to IDetector interface, but this interface is declared in the domain layer.
There is not infrastructure code in the domain layer. In this case, infrastructure code means something like "call that GET method of that REST service using this set of parameters in the query string". Obviously, this code will be in the externalDetector implementation.
To be sure that it is a good way, you can take a look at this repository with a sample DDD application from famous Eric Evans' book. You can find there a service interface declared in the domain layer and the service itself implemented in the infrastructure layer. Unfortunately, there aren't examples of using this service interface inside of the domain layer in this application. But it's declared inside of the domain layer to make such a usage possible.
And you can find the same approach with a good explanation in this great article.
EDIT
According to new information in the question, if it is about A/B testing, then choosing a detector is the application-level decision. All other things remain the same. So:
MixerDetector should be in the application layer
DetectPriority interface - in the domain layer
InternalDetector in the domain layer
ExternalDetector in the infrastructure layer
And you don't need "business" names for your detectors then, because they are literally InternalDetector and ExternalDetector.
Should we put both in Infrastructure layer?
Not usually, no. Among other things, that's going to make a mess of your dependency graphs. We don't want domain code to have a dependency on infrastructure code (one of the motivations for having a domain model is so that you can implement the logic of the domain without being tightly coupled to the context that runs the domain model -- introducing infrastructure dependencies is contrary to that goal).
That doesn't necessarily mean that the infrastructure code is "far away" - see package by feature vs package by layer. They are different responsibilities (in the single responsibility principle sense), so there will usually be some separation between the two.
One aspect in which the two are very different: failure modes -- robust code that communicates across the network needs to respect the fact that the network is unreliable, but that's not a domain concern, so we don't usually want to pollute our domain code with network contingency logic.
But if you like, ignore all that -- the real heuristic is simple: we want the arrangement of code that is easiest to maintain over its entire lifetime. If in your context that means putting domain code into the infrastructure layer, then that's what you should do.
The guidelines of DDD and other styles are primarily there to help you avoid the trap of increasing the lifetime maintenance cost by deciding to do what is easy "right now".
I use to keep domain service implementations which are free of infrastructure dependencies in the domain layer. Implementations of a domain service interface which require infrastructure dependencies should reside in the infrastructure layer.
What you need to consider as well in your case is that the code which instantiates the concrete implementation of your DetectPriorityInterface at runtime has to reside in the infrastructure layer as well as it also has a direct dependency to the external domain service.
I suggest you have some factory for that job which decides on creating one or the other domain service based on some kind of parameter. But you can still use a factory interface which you can put in your domain layer. Let's call it PriorityDetectorFactoryInterface or similar. And only the concrete implementation of that factory, let's call it PriorityDetectorFactory would reside in the infrastructure layer.
If you have some application service which is responsible for handling the use case where the priority detection comes into play you would pass the PriorityDetectorFactoryInterface into this application service. At runtime the concrete implementation of the factory interface (i.e. PriorityDetectorFactory) will be injected into the application service. With that you can also keep the application layer where you usually only define the workflows for orchestrating your use cases free of infrastructure dependencies.
With that you would have:
DetectPriorityInterface in your domain layer
InternalPriorityDetector (implementing DetectPriorityInterface) in your domain layer
ExternalPriorityDetector (implementing DetectPriorityInterface) in your infrastructure layer
PriorityDetectorFactoryInterface in your domain layer as well
PriorityDetectorFactory (implementing PriorityDetectorFactoryInterface) in your infrastructure layer
...and the mentioned application service handling your use case in your application layer
Note: this is all based on the assumption that your internal domain service implementation is really free of dependencies other than stuff from the domain layer itself.
I am learning about DDD so apologies if my question is naive. I think I need to use Local Data Transfer Object in order to display data to the users as a lot of properties are not part of any of Entity / Value Objects.
However, I am not sure where this DTO should be implemented - in a Domain Layer or in an Application Service Layer. The DTO implementation seems part of the Domain, but it means that when I create a collection of DTOs in the Service Layer and pass it to a Presentation Layer, I have to reference Domain Layer in Presentation Layer, which seems wrong.
What is the correct way to implement DTO using DDD principles?
Define the DTO to the layer where the source of the values comes from.
Relative to OP's question: place the DTO in the Application Service Layer. DTO is an output of that layer, it makes sense if you define it there. Don't put your DTO in the Domain Layer. The Domain Layer does not care about mapping things to serve external layers (the domain does not know there is a world outside of its own).
Presentation Layer (closes to consumers)
This could be your API
Has Models or Dto definitions of its own with attributes relative to its layer. If this is an API then Models/DTO have attributes for formatting or data type validations
This is the "Application Root" (meaning that it must reference both Domain Service layer, Data/Infrastructure Layer to be able to inject services)
Maps data between ApplicationService.Dto and Presentation.Dto
Application Service Layer
Has Dto definitions of its own to be able to return data without exposing the domain entities.
Bridge between Presentation Layer and Domain Layer.
Contains Application Services. See answer https://stackoverflow.com/a/3840552/1027250 for detailed definition of Application Services.
Domain Layer
Domain entities
May contain Interfaces bridging the infrastructure layer, defined in words that can be understood by the business, free from technical terms (IE: IExcelReport, IGoogleSheetReport, IRepository)
May contain "Domain Services"
Data / Infrastructure Layer (closest to your database or external services)
Database infrastructure (mapping).
Excel libraries if you define this layer as infrastructure code.
Mail or notification services.
PDF output files
Such DTOs that are exposed to the outside world become part of a contract. Depending on their form, a good place for them is either the Application Layer or the Presentation Layer.
If the DTOs are only for presentation purposes, then the Presentation Layer is a good choice.
If they are part of an API, be it for input or output, that is an Application Layer concern. The Application Layer is what connects your domain model to the outside world.
As an interesting observation, it follows that the Presentation Layer should access the domain model only through the Application Layer. Otherwise, we lose our single point of access - we'd have multiple layers invoking the domain model. The Application Layer exposes all of our use cases. Whether they are invoked by a call from another service or by the Presentation Layer makes little difference.
Sources
The core of these concepts I learned from The Red Book by Vaughn Vernon. (I would quote from it, but I don't have it handy.) The chapters about the Application Layer and the Presentation Layer are relevant.
Primarily, my conclusions come from being strict with the concepts as presented by Eric Evans and Vaughn Vernon, and prioritizing freedom in the domain model, as this is Domain-Driven Design:
The domain model should be easy to change. That means not exposing domain objects externally, as having external dependants would make them hard to change (without breaking things).
The Application Layer is the external point of access. It is what defines the use cases on the domain model. That means not operating on the domain model from elsewhere. The Presentation Layer can only go through the Application Layer. Nobody likes having to deal with many different points of access!
Yorro is right about where to place DTO but I encourage you to avoid "DTO mindset". This way of thinking collides with DDD way of thinking.
Thinking about "I need a DTO here" is thinking about technical representation (as plalx says); it is a level of abstraction too low. Try a higer level of abtraction and think about your domain, user's tasks and your UI.
Do you need get view data to the user? Bring it to UI through a View Service that return a specific YourViewInfo class.
Do you need to send data to some Service to perform a task? Send it a specific TaskMessageInfo class or a specific Command class.
When you begin to modeling the internals of these classes is when you should start to thinking about its technical representation; then you could reach to the conclusion that could be, i.e., DTO classes for convenience.
Thinking this way helps you to model the system and doesn't trigger questions like
Where to put or belongs this thing?
DTO and Domain are different layers.
So it requires mapping from one to another and usually it is done in what is called Application Services layer.
Take a look at the following articles to go deeper with DTO and layering:
Is Layering Worth the Mapping? by Mark Seemann
DTO vs Value Object vs POCO: definitions
Hexagonal (Ports/Adapters) Architecture
What has to be mentioned here is so-called Hexagonal (Ports/Adapters) Architecture [Vernon, the red book p. 125]. It is very convenient to place objects that represent data for the external (outside the domain & the application) comsumers. The architecture is the great addition to Layered Architecture generally implied by DDD.
Here is the example.
Along with ports/adapters for a DBs, email services etc.
We may define a ports/adapters/http/ui/myestore/ShoppingCartResponse.valueobject.ext (assume we use some imaginary programming language EXT) that contains the data your UI application MyEStore will use to show the end user his shopping cart state.
ShoppingCartResponse.valueobject.ext is created by ports/adapters/http/ui/myestore/EStoreHTTP.adapter.ext (for brevity it could be a synonim for a very slim HTTP REST API controller from REST world in our example).
The adapter asks the domain service ShoppingCart.service.ext for aggregates, entities, other value objects. Then it creates the desired ShoppingCartResponse.valueobject.ext from them (by itself or with creators - factories, builders etc.). Then sends the value object as an HTTP response to the consumer.
DTO or Value Object?
Whether ShoppingCartResponse would be a value object or a DTO (.dto.ext) you should decide based on
The particular structure of your Ports/Adapters object hierarchy;
If it is justified to have another type of object, a DTO, in the system, or it is better to keep only value objects only;
A semantic meaning of DTO vs value objects in object hierarchy;
The responsibilities differentiation between them: say your value object would do some invariants logic-keeping, whereas DTO could be just a dumb object with no logic.
I would prefer starting with the simplest approach, allowing only for value objects, and add DTOs only as the clear architectural need in them appears.
This approach gives much flexibilty yet it keeps code design clean and simple. Ports/Adapters section accommodates objects that belong together (the adapter, VO or DTO, their creators) and keeps Application Layer clean keeping the space for more relevant application layer objects.
is the following good design and allowable in onion architecture and domain driven design?
say you have an "Order" domain class like so
class Order
{
INotificationService _notificationService;
ICartRepository _cartRepository;
void Checkout(Cart cart, bool notifyCustomer)
{
_cartRepository.Save(cart);
if (notifyCustomer)
{
_notificationService.sendnotification();
}
}
}
Is it good or bad design to have the domain model call interfaces of infrastructure?( in this case, notificationservice and CartRepository)
Your design will be OK only if both INotificationService and ICartRepository interfaces are defined within your Domain (Core) layer and if they're bound at runtime with the right implementation by your Dependency Resolution layer (the outermost layer of your Onion architecture).
Remember that in an Onion architecture, your Domain layer cannot reference any libraries.
ICartRepository implementation will obviously be done in your Infrastucture layer as it will surely be tied to your Data Access layer technology.
If your INotificationService implementation needs to talk to an external service, then it goes to Infrasrtructure as well. But if it is part of your business then it's implementation could be in the Domain layer.
I think INotificationService is a domain concept rather than infrastructure service. We could model this as a DomainEvent telling "the customer about the cart is saved".
What about moving the INotificationService to the domain layer and rename it as "CartDomainEvents".
CartDomainEvents.raise(CartSavedEvent(...));
In general case, Calling infrastructure components introduces bidirectional dependencies which is usually not a good design.
Repository layer are exist for each aggregate of the domain,repository is on top of domain, you can have repository base interfaces on your domain who they live in infrastructure but you can not see the repository implementations in your model(it's not correct).
there are some basic interfaces such as UnitOfWrok, Repository, Specificationm authentication and ... in your infrastructure accessible in all layers. I recommend to take a look at aghata store front written in .net to see a real implementation project https://github.com/elbandit/Asp-Net-Design-Patterns-CQRS
repository belong to infrastructure layer
also it would be better to use Icart interface
void Checkout(ICart cart, bool notifyCustomer)
to reduce coupling.
I've seen lots of book and article examples saying to put validation code in your Service Layer. Keep the Domain Objects "dumb" (aka, pure POCO's) and handle all validation that a Domain Object might do in the Service Layer.
The Service Layer is responsible for so much it seems (or at least it can be); user authentication, role authentication, scripting dependency objects for IoC's (loggers, error-handlers, etc...), scripting Domain Objects, scripting repositories and passing Domain Objects to and from the repository... whew!
Doesn't creating all these rules in the Service Layer pose a substantial threat to your Domain Objects? For instance, what happens is some programmer decides to write consuming code directly against your Domain Objects and just bypasses the Service Layer altogether? That would be bad, but a believable situation.
If you are going to put a lot of the responsibilities in the Service Layer, including all Domain Object validation, is there a way to "protect" your Domain Objects is someone tries to script them directly? For instance, maybe some way your Domain Objects now they're not being used by a certain client (in this case, the Service Layer?).
Good design makes me think the Domain Objects should know nothing about who's calling them and how they're being called.
If there is no way to "lock down" the Domain Objects, then why are so many articles, books, etc suggesting that putting Domain Object validation in the Service Layer the way to go? I would imagine by taking a defensive programming position, that you should build your Domain Objects to be bullet-proof, and rely on your Service Layer for a simple layer of code to forwarding and receiving requests between the UI and the BAL/DAL.
Has anyone had some real-life project experiences with "abuse" of their Domain Objects from people that have bypassed their Service Layer?
I think you may misunderstand the purpose of a POCO. A POCO, as I understand it, is not an anemic domain object with only properties and attributes. Rather a POCO simply is not tied to a framework or complicated inheritance model. The object is flexible and only concerned about its role in the domain.
They are 2 different design philosophies. Rich Domain Model vs Anemic Domain Model.
The short answer is yes, you can prevent direct access to your domain objects.
You can do so with a number of techniques:
1) You can make all public facing domain objects immutable (i.e. you can't change the data) via only having the only public methods be getters. All methods that modify your objects can be protected or package private so only the correctly packaged services can access them (in Java at least)
2) You can expose only separate classes to your external developers -- so if you have a Person domain class you can have a PersonInfo class that you pass up, that does nothing but contain info.
3) You should expose a coherent API to your app consumers. You basically prevent them from bypassing your Service layer.