Service Oriented Architecture & Domain-Driven Design

Question

I've always developed code in a SOA type of way. This year I've been trying to do more DDD but I keep getting the feeling that I'm not getting it. At work our systems are load balanced and designed not to have state. The architecture is:

Website

===Physical Layer==

Main Service

==Physical Layer==

Server 1/Service 2/Service 3/Service 4

Only Server 1,Service 2,Service 3 and Service 4 can talk to the database and the Main Service calls the correct service based on products ordered. Every physical layer is load balanced too.

Now when I develop a new service, I try to think DDD in that service even though it doesn't really feel like it fits.

I use good DDD principles like entities, value types, repositories, aggregates, factories and etc.

I've even tried using ORM's but they just don't seem like they fit in a stateless architecture. I know there are ways around it, for example use IStatelessSession instead of ISession with NHibernate. However, ORM just feel like they don't fit in a stateless architecture.

I've noticed I really only use some of the concepts and patterns DDD has taught me but the overall architecture is still SOA.

I am starting to think DDD doesn't fit in large systems but I do think some of the patterns and concepts do fit in large systems.

Like I said, maybe I'm just not grasping DDD or maybe I'm over analyzing my designs? Maybe by using the patterns and concepts DDD has taught me I am using DDD? Not sure if there is really a question to this post but more of thoughts I've had when trying to figure out where DDD fits in overall systems and how scalable it truly is. The truth is, I don't think I really even know what DDD is?

Answer 1

I think a common misconception is that SOA and DDD are two conflicting styles.

IMO, they are two concepts that work great together; You create a domain model that encapsulates your domain concepts, and expose entry points into that model via services.

I also don't see what the problem is with ORM and services, you can easily use a session/uow per service call. Just model your service operations as atomic domain commands.

a naive example:

[WebMethod]
void RenameCustomer(int customerId,string newName)
{
    using(var uow = UoW.Begin())
    {
        var customerRepo = new CustomerRepo(uow);
        var customer = customerRepo.FindById(customerId);
        customer.Rename(newName);
        uow.Commit();
    }
}

Maybe the problem you are facing is that you create services like "UpdateOrder" which takes an order entity and tries to update this in a new session?

I try to avoid that kind of services and instead break those down to smaller atomic commands.

Each command can be exposed as an operation, or you could have a single service operation that receives groups of commands and then delegate those to command handlers.

IMO, this way you can expose your intentions better.