Service Oriented Architecture & Domain-Driven Design

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 开发者_StackOverflowtruth is, I don't think I really even know what DDD is?

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.

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 design-pattern 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.

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.

I am really really late in this, but I would like to add the following in the very good answers by everyone else.

• DDD is not in any conflict with SOA. Instead, DDD can help you maintain a better Service Oriented Architecture. SOA promotes the concept of services, so that you can define better boundaries (oh, context boundary is also a DDD concept!) between your systems and improve the comprehension of them.
• DDD is not about applying a set of patterns (e.g. repository, entities etc.). DDD is mostly about trying to model your software, so that all the concepts (i.e. classes in case of object-oriented programming) align directly with concepts of the business.

You should also check this video (especially the last 5 minutes), where Eric Evans discusses exactly this topic.

I've even tried using ORM's but they just don't seem like they fit in a stateless architecture.

I don't have any reference handy to back this up. However, you're right, ORMs do not fit nicely with DDD as well. This is because, they're trying to bridge the object-relational impedance mismatch, but in a wrong way. They force the software towards an anemic domain model, where classes end up being "plain data holders".

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.

In the video I've linked above, you can also find Eric explaining that DDD concepts can "break" in very large-scale systems. For instance, imagine a retail system, where each order is an aggregate containing potentially thousands of order items. If you'd like to calculate the order's total amount strictly following DDD, you'd have to load all the order items in memory, which would be extremely inefficient compared leveraging your storage system (e.g. with a clever SQL statement). So, this trade-off should always be kept in mind, DDD is not a silver bullet.

Like I said, maybe I'm just not grasping DDD or maybe I'm over analyzing my designs?

Excuse me, but I'll have to quote Eric Evans one more time. As he has said, DDD is not for perfectionists, meaning that there might be cases, where the ideal design does not exist and you might have to go with a solution, which is worse in terms of modelling. To read more around that, you can check this article.