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

The most important things about Domain-Driven Design are the big picture ideas:

• the ubiquitous language,
• the strategic decision-making where you are adding value by working in the core domain (and insulating yourself from other nasty systems), and
• the approach to making testable, flexible designs by uncoupling infrastructure from business logic.

Those are broadly applicable, and are the most valuable pieces.

There is a lot of stuff about Factories, Services, Repositories, Aggregates, etc., I take that as advice from one experienced developer to another, not as gospel, because so much of it can vary depending on the language and frameworks that you're using. imho they tend to get overemphasized because programmers like us are detail-oriented and we obsess on that kind of stuff. There is valuable stuff there too, but it needs to be kept in perspective. So some of it may not be that relevant to you, or it might grow on you as you work with it.

So I would say it's not like there's a checklist that you can run through to make sure you're using all the patterns, it's a matter of keeping the big picture in mind and seeing how that changes your approach to developing software. And if you pick up some good tips from the patterns that's great too.

Specifically with respect to the SOA thing, I've developed applications that defer all their state to the database, which have used persistence-ignorant domain objects. Writing tests for services that have to mock daos and feed stuff back is drudgery, the more logic I can put in the domain objects the less I have to mess with mocks in my services, so I tend to like that approach better.

Answer 2

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.

Answer 3

There are some concepts introduced with DDD which can actually confuse you when building SOA.

I have to completely agree with another answer, that SOA-services expose operations that act as atomic commands. I believe that a very clean SOA uses messages instead of entities. The service implementation will then utilize the domain model to actually execute the operation.

However there is a concept in DDD called a "domain service". This is slightly different than an application service. Typically a "domain service" is designed within the same ubiquitous language as the rest of the domain model, and represents business logic that does not cleanly fit into an entity or value.

A domain service should not be confused with an application service. In fact, an application service may very well be implemented such that it uses a domain service. After all, the application services can fully encapsulate the domain model within SOA.