Considering Domain Driven Design, can Infrastructure or System use Domain's objects (Values, Entities, etc.), or should it be applied Dependency Inversion, so that Infrastructure will only depend on Interfaces defined by itself?
What about the Repository? Does it applies de same?
Is it a violation to a Infrastructure, Repository or a System code depends on the Domain?
(A) Example code where Infrastructure depends on the Domain:
namespace Infrastrcuture {
public class Sender {
public void Send (Domain.DataValue data) { ... }
}
}
(B) Example code where Infrastructure will not depend on the Domain:
namespace Infrastrcuture {
public interface ISendableData {
...
}
public class Sender {
public void Send (ISendableData data) { ... }
}
}
In general, I'd say it's OK if your infrastructure depends on your domain. The other way around is not such a good idea.
Think about it this way: what is more likely to be replaced at some point? Infrastructure or domain?
Infrastructure will change over time (different providers, different servers, ...) Your domain on the other hand will always be there
Related
My latest MVC solution consists of an MVC5 site and a DAL class library that will contain a repository interface and class for each entity. I am trying to figure out where to place business logic for my entities such as CheckingAccount.Withdrawl or CheckingAccount.Deposit. Any suggestions? Should this be done within the Model folder within the MVC project while all of the repository classes are in my DAL?
Ideally you want to separate your actual business logic from your entities and abstract it away from your database or ORM as much as possible by creating a business logic layer and injecting your repository into your service/business logic layer using an IoC container and dependency injection.
The common approach is to create a separate class library for your business logic layer that remains agnostic of your UI layer (meaning your UI layer could be an MVC front end or even restful web service) and communicates via data transfer objects.
Here is a simple example:
MVC Controller / UI
public class AccountCheckingController : Controller
{
private readonly IAccountService AccountService;
public CheckingAccountController(IAccountService accountService)
{
this.AccountService accountService;
}
[HttpPost]
public ActionResult Deposit(decimal depositAmount)
{
...
DepositReceiptDto depositReceipt = this.accountServive.Deposit(accountId, depositAmount);
...
return new DepositViewModel {
Receipt = depositReceipt
}
}
}
Business Logic Class / Service (stored in a class library such as WebsiteName.Services or Website.BusinessLogic
public class AccountService : IAccountService
{
private readonly IAccountRepository Repository;
public AccountService(IAccountRepository repository)
{
this.Repository = repository;
}
public DepositReceiptDto Deposit(int accountId, decimal depositAmount)
{
// Perform actions against your repository/ORM here.
return new DepositReceiptDto {
DepositAmount = depositAmount,
User = UserDto,
Status = Status.Success
};
}
...
}
As you can see, by using this separation you can easily switch out your UI without having to perform much work.
I hope this helps.
If something is not an entity and is not a value object, then it's a service. Correct namespace for service depends on his level. Data-access services may be located in the Project.Dal or Project.Dal.Services. The good namespace for domain's service is the Project.Domain.Services.
Was wondering if there's a recommended best-practice way of grouping similar services together in what's becoming a larger and larger project. Say that most of my services can be lumped in either dealing with "Pro" data or "Amateur" data (the data goes way beyond a simple flag in a table, the data itself is totally different, from different tables, on the pro or amateur side.
I know I can add routes to my classes...
/pro/service1
/am/service2
It looks like I can put the DTOs in namespaces....
What about the Service.Interface items (Service and Factory classes). Would you put those into namespaces also?
Finally, is there a way for the metadata page to reflect these groupings? I started to go down this road, but all the services listed out in alphabetical order, and you couldn't see the route or namespace differences between service1 and service2.
thank you
If you want, you can split multiple Service implementations across multiple dlls as described on the Modularizing Services wiki.
You can safely group service implementation classes into any nested folder groupings without having any impact to the external services. But changing the namespaces on DTO's can have an effect if your DTO's make use of object, interfaces or abstract classes which emit type info containing full namespaces.
In ServiceStack v4.09+ (now on MyGet) the MetadataFeature includes the ability to customize the ordering of the metadata page, e.g you can reverse the order of the metadata pages with:
var metadata = (MetadataFeature)Plugins.First(x => x is MetadataFeature);
metadata.IndexPageFilter = page => {
page.OperationNames.Sort((x,y) => y.CompareTo(x));
};
Organising your large project:
For a complex service(s) I setup 4 projects in one solution.
AppHost, This takes care of the configuration of the service. (References Model, Service and Types)
Model, This is the database model (Does not reference other projects)
Service, This is the implementation of the service only, not the interfaces or DTOs (References Model and Types)
Types, This includes my Interfaces, DTOs and routes. (Does not reference other projects)
Having a separate Types library allows the distribution to clients, for example for use with the ServiceStack JsonServiceClient.
Yes you can namespace the Interfaces, DTOs and factory classes, any way you want. They will work as long as they are referenced in your service correctly.
If you are trying to separate more than one service, you should consider separating your service code into logical folders within the Service project. i.e.
/Service/Pro
/Service/Amateur
Wrap the outer code of your Service methods in a public partial static class MyServiceStackApplication, with an appropriate name. Then reference this as the assembly in the AppHost constructor. So for example:
Pro Service (Service Project/Pro/UserActions.cs)
public partial static class MyServiceStackApplication
{
public partial class Pro
{
public class UserActionsService : Service
{
public User Get(GetUserRequest request)
{
}
}
// ...
}
}
Pro Service (Service Project/Pro/OtherActions.cs)
public partial static class MyServiceStackApplication
{
public partial class Pro
{
public class OtherActionsService : Service
{
public Other Get(GetOtherRequest request)
{
}
}
// ...
}
}
Amateur Service (Service Project/Am/UserActions.cs)
public partial static class MyServiceStackApplication
{
public partial class Amateur
{
public class UserActionsService : Service
{
public User Get(GetUserRequest request)
{
}
}
// ...
}
}
etc.
You can see from the above code we can have multiple files, all separated out and organised, but one assembly for ServiceStack to reference in the AppHost:
public AppHost() : base("Pro & Amateur Services", typeof(MyServiceStackApplication).Assembly) {}
Using the reference to the MyServiceStackApplication assembly, and using the partial keyword allows you to organise the code into manageable groupings.
Metadata:
Unfortunately separating the metadata by namespace isn't supported. You could try and customize the MetaDataFeature yourself, but it does seem like a useful feature, being able to separate multiple services where they are hosted in the one ServiceStack application. I would suggest you raise a feature request.
Mythz is bringing out features faster than lightning. :) Seems like he has that covered in the next release and you should be able to apply a custom filter to HostContext.Metadata.OperationNamesMap.
1) In most cases each Aggregate Root should define its own transactional boundary, in which case we don't need to expose IUnitOfWork interface in Domain Layer.
a) I assume in this situation a good option would be for a repository ( used by aggregate to enforce invariants applied within it ) to contain its very own instance of UoW ( if using EF, then this UoW instance could simply be of type DbContext )?
2)
a) But if for whatever reason transaction spans several aggregates ( thus more than one aggregate needs to be changed at one time ), then won't Domain Layer also need to contain IUnitOfWork interface?
b) Won't exposing IUnitOfWork interface in Domain Layer violate persistence ignorance rule?
c) If yes to b), doesn't then exposing IUnitOfWork defeat the purpose of having repositories?
Replying to Alexey Raga:
1)
I would advice against exposing repositories to aggregates. Repositories are there to give you aggregates, that's it.
a) Though I assume that majority of ddd architects don't have a problem with exposing repos to aggregates ( I'm only asking because I read several articles on repos and DDD and the impression I got is that authors ain't against exposing repos to aggregates - but now I'm not so sure anymore )?
b) So you're also against exposing repositories to domain services?
c) Judging by your answer I'm guessing that you consider exposing IUnitOfWork as a violation of PI?
2)Note that although my command handler (app service in a way)...
Do you normally implement command handlers as app services?
3)
public void Handle(ApproveOrderCommand command)
{
var order = Repository.Get(command.OrderId);
property.Approve(command.Comment, ServiceRequiredForOrderApproval);
Repository.Save(order);
}
Is property.Approve(...) a typo and you actually meant order.Approve(...)?
Thanx in advance
I would advice against exposing repositories to aggregates. Repositories are there to give you aggregates, that's it.
Look at it at that way: your domain is a "bubble" which only understands its own stuff. Meaning, it only understand its own value objects, domain services interfaces it declares, etc. I wouldn't include repositories in this set.
When your domain (an aggregate) needs something it should explicitly expose the dependency of what it needs, not just ask for some repository.
Services is what brings things together.
For example, my command handler could look like:
public class ApproveOrderCommandHandler : IHandle<ApproveOrderCommand>
{
//this might be set by a DI container, or passed to a constructor
public IOrderRepository Repository { get; set; }
public ISomeFancyDomainService ServiceRequiredForOrderApproval { get; set; }
public void Handle(ApproveOrderCommand command)
{
var order = Repository.Get(command.OrderId);
order.Approve(command.Comment, ServiceRequiredForOrderApproval);
Repository.Save(order);
}
}
Note that although my command handler (app service in a way) deals with repositories, my domain (order aggregate) is persistence ignorant. It doesn't know anything about repositories of UnitOfWorks.
When I do need to spin up a UnitOfWork I can compose it using a Chain Of Responsibility pattern:
public class WithUnitOfWorkHandler<T> : IHandler<T> {
private readonly IHandler<T> _innerHandler;
public WithUnitOfWorkHandler(IHandler<T> innerHandler) {
_innerHandler = innerHandler;
}
public void Handle(T command) {
using(var ouw = new UnitOfWork()) {
_innerHandler.Handle(command);
uow.Commit();
}
}
}
Now I can "chain" any of my command handlers by "decorating" it with WithUnitOfWorkHandler.
And some of the handlers may even touch more than one repository or aggregate. Still, aggregates don't know anything about persistence, unit of works, transactions, etc.
Persistence ignorance means: The business layer has no knowledge and no dependency whatsoever on the concrete persistence system that is used under the hood (e.g. MS SQL Server, Oracle, XML files, whatever).
Thus, exposing an interface that abstracts away the concrete type of the datastore can never violate this principle.
Persistence Ignorance is a guideline, it is almost impossible to reach with actual languages and technologies. The Repository pattern and the Unit Of Work abstract the persistence related stuff and "hide" the Data Access Layer to the business code, but it is more a trick (a clean one) than an absolute solution. The presence or the need for something (an interface, a base class, an attribute...) that says "heyyy, there is something in here we want to hide..." violates PI. But for the moment, there is no better solution.
I am designing a system using domain driven design concepts and I am struggling with a few things. The "domain" is essentially a business system for the company I work for. I am also using dependency injection. So, in my model I have things related to any typical business system (Employee, Order, Invoice, Deposit, etc..). Right now I am trying to create a cash posting application in which users (aka Employees) can create deposits and apply them to unpaid invoices. The problem that I am having is that we are also using an external business system (Microsoft Dynamics Nav) to handle our accounting transactions. So essentially I am dealing with two different databases. So, for the cash posting application I have modeled the domain objects Deposit and DepositLine. I also have in my domain an IDepositRepository interface that is responsible for persisting the deposits. To get a deposit from the system I just want to grab it directly from the database. However, in order to create a deposit I have to use the Dynamics Nav web services because there is certain logic that gets executed behind the scenes that I don't know about. I started looking at the concept of an Anti Corruption layer in which I could translate my version of the deposit object into a deposit object suitable for the web service. So here is what I am envisioning right now:
Domain Layer
- Models
- Deposit
- DepositLine
- Repositories
- IDepositRepository
Infrastructure Layer
- Data
- Repositories
- DepositRepository
- DynamicsNav
- Services
- INavCashManagementService
- Translators
- IDepositTranslator
- Adapters
- INavAdapter
Now I thought i might implement the DepositRepository like so:
public class DepositRepository
{
private INavCashManagementService navCashManagementService;
public DepositRepository(INavCashManagementService navCashManagementService)
{
this.navCashManagementService = navCashManagementService;
}
public Deposit GetDeposit(int id)
{
// use nhibernate to get directly from the database
}
public void SaveDeposit(Deposit deposit)
{
this.navCashManagementService.CreateDeposit(deposit);
}
}
First of all, is this an appropriate design? My next problem is that users are also going to have to "Post" deposits. The Nav web services will also have to be used to run the posting routine. But, this is more of a business process rather than a persistence issue, so I don't see it fitting into the repository. So I am wondering how/where I should call the posting routine. Should I create a domain service like this:
public class CashPostingDomainService
{
private INavCashManagementService navCashManagementService;
public CashPostingDomainService(INavCashManagementService navCashManagementService)
{
this.navCashManagementService = navCashManagementService;
}
public void PostDeposits()
{
this.navCashManagementService.PostDeposits();
}
}
One confusion I have with domain driven design is external dependencies. Doesn't the CashPostingDomainService class now have an external dependency on Nav? I know the implementation isn't in the domain layer, but doesn't the interface itself make it a dependency? The same goes with other technical concerns like sending emails. If I have an IEmailService interface and want to send an email once the deposits are posted, would I inject the interface into the CashPostingDomainService class? Or would that be part of the application workflow? So which one of these options make the most sense (if any):
1
public class DepositController
{
private ICashPostingDomainService cashPostingDomainService;
private IEmailService emailService;
public DepositController(
ICashPostingDomainService cashPostingDomainService,
IEmailService emailService)
{
this.cashPostingDomainService = cashPostingDomainService;
this.emailService = emailService;
}
public void PostDeposits()
{
this.cashPostingDomainService.PostDeposits();
this.emailService.NotifyDepositsPosted();
}
}
2
public class DepositController
{
private ICashPostingDomainService cashPostingDomainService;
public DepositController(
ICashPostingDomainService cashPostingDomainService)
{
this.cashPostingDomainService = cashPostingDomainService;
}
public void PostDeposits()
{
this.cashPostingDomainService.PostDeposits();
}
}
public class CashPostingDomainService
{
private INavCashManagementService navCashManagementService;
private IEmailService emailService;
public CashPostingDomainService(
INavCashManagementService navCashManagementService,
IEmailService emailService)
{
this.navCashManagementService = navCashManagementService;
this.emailService = emailService;
}
public void PostDeposits()
{
this.navCashManagementService.PostDeposits();
this.emailService.NotifyDepositsPosted();
}
}
Thanks for the help!
is this an appropriate design?
It seems fine to me. The important thing is for your Repository to stay oblivious of the Nav side of things and let the anticorruption layer handle that. You might want to have a look here for a similar example.
I know the implementation isn't in the domain layer, but doesn't the
interface itself make it a dependency?
You may have that feeling because the name of your (supposedly agnostic) service interface contains "Nav". To reflect a service abstraction that could have Nav or any other ERP as an implementation, you should rename it to ICashManagementService.
If I have an IEmailService interface and want to send an email once
the deposits are posted, would I inject the interface into the
CashPostingDomainService class? Or would that be part of the
application workflow?
It's your architectural decision to choose one or the other.
Option 1. means that sending an email is an intrinsic part of the deposit posting domain operation. If you take your domain module and reuse it in another application, posting deposits will automatically result in sending an email whatever that application is about. This might be the right thing to do in your context, or you might want to make things a little more generic (like, sending feedback after the operation but not deciding in the domain service whether this feedback should be mail, a log file, etc.)
Option 2. means that the sequence of events that happen after posting the deposits is application specific, that is at the use case level rather than business/domain level. It is up to the Controller (or Application Service) to decide which actions to take -send an email or anything else. Consequently, different applications based around your domain layer could decide to take different actions. This also means possible code duplication between these applications if several of them chose to send mails.
I'm still learning about DDD and I have these two (probably simple) questions:
If a Factory creates new object/graph/aggregate instances, but also "reconstitutes" objects/graphs from the Repository, then:
(1) Does your service layer functions/jobs/tasks/unit-of-work call into the Factory or a behavioural method on the Entity instance or a DomainService function? I'm lost as to the call stack based on the responsibility of these components.
(2) Do Entity instances even have "behavioural methods" like above? For example does a Post have p.UpdatePost(string bodyText) or is that not a concern of the domain model and so the same should be achieved with the Repository? Or the service layer function, should it be calling the Repository in this case and the entity instance simply have behavioural methods that are specific to the domain and not persistence? But then, why does it sound like "updating a post" is a domain function when that's the user's goal?
You can see I'm all over the place. Please help.
(1) Does your service layer functions/jobs/tasks/unit-of-work call into the Factory or a behavioral method on the Entity instance or a DomainService function? I'm lost as to the call stack based on the responsibility of these components.
Usually - top level retrieves necessary aggregate root and calls a function on it. Sometimes top level retrieves multiple aggregate roots and pass them to domain service, but not often because domain service is a quite strong sign that there is unrecognized aggregate root. At the end - top level ensures aggregate root is persisted.
(2) Do Entity instances even have "behavioural methods" like above? For example does a Post have p.UpdatePost(string bodyText) or is that not a concern of the domain model and so the same should be achieved with the Repository? Or the service layer function, should it be calling the Repository in this case and the entity instance simply have behavioural methods that are specific to the domain and not persistence? But then, why does it sound like "updating a post" is a domain function when that's the user's goal?
Yes, they do. Domain model should be aware of it's state changes. And that's much more beneficial as it seems at first. Great thing about this is that You gain extensibility point. If client will walk week later to You and say that he wants system to check additional things when user updates post - instead of searching every line of post.bodyText="new value", You will be able to go straight to post.UpdatePost method and attach necessary things there.
On the other hand - CRUD is not mutually exclusive with domain driven design. E.g. - in my application, management of users and their roles is uninteresting enough that I'm not even trying to model it granularly. You need to recognize parts what matters in business Your application is describing and working with.
Keep in mind that domain driven design makes sense for complex applications only. Simple blog application doesn't need it.
(3) Am I wrong in assuming that a service layer (not Domain Services) should encapsulate how an interface interacts with the Domain Layer?
As I see it - application services are more for orchestrating infrastructure. If there is no infrastructure involved - then application service loses value:
Application services basically are just facades. And every facade is bad if complexity it adds overweights problems it solves.
Inside domain:
//aggregate root is persistence ignorant.
//it shouldn't reference repository directly
public class Customer{
public string Name {get; private set;}
public static Customer Register(string name){
return new Customer(name);
}
protected Customer(string name){
//here it's aware of state changes.
//aggregate root changes it's own state
//instead of having state changed from outside
//through public properties
this.Name=name;
}
}
//domain model contains abstraction of persistence
public interface ICustomerRepository{
void Save(Customer customer);
}
Outside of domain:
public class CustomerRepository:ICustomerRepository{
//here we actually save state of customer into database/cloud/xml/whatever
public void Save(Customer customer){
//note that we do not change state of customer, we just persist it here
_voodoo.StoreItSomehow(customer);
}
}
//asp.net mvc controller
public class CustomerController{
public CustomerController(ICustomerRepository repository){
if (repository==null)throw new ArgumentNullException();
_repository=repository;
}
public ActionResult Register(string name){
var customer=Customer.Register(name);
_repository.Save(customer);
}
}