Alex Rivera | Logout

Service Oriented Architecture & Domain-Driven Design

Asked 2010-03-18T03:59:37.013
23

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?

domain-driven-design design-patterns soa
Edit
Report

1 Answer

10

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.

answered 2010-04-16T19:03:10.800

Your Answer