In Search For Agile Domain Driven Design … Hopefully Part 1 of N

The Useless Introduction You Used To :)

This post has taken so long to be started in writing. I’ve been busy with many events in my life lately. Suffering from frequent limited internet access lately, and, all this moving between companies thing has been eating me. And yes, I admit, I’ have been as tired and more honestly lazy as you expected me to be!

Hey, there’s a little warning. This post is not exactly for my usual audience. I’m sorry, but introducing Domain Driven Design is not one of the goals for this post. There’re many interesting resources and books (even FREE: InfoQ, Domain Driven Design Quickly) on the topic. However, if you leave me a comment telling me to make a write-up on the topic, of course I will :) :).

One more thing. Another reason I’m working on this is that I’m preparing for an internal session here in Raya about Practical Lightweight Domain Driven Design. This session is truly internal yet. It should be recorded though but I’m not sure whether it’ll be possible to publish the videos (Yeah, I will see how we can have our public sessions of possible sure!). If you have a user group and would like me to give this session in a group meeting, I’ll be glad to do.

Introduction Still: The Messages, The ORM

This post was originally a couple of messages I’ve sent recently to the ALT.NET Yahoo Group. In which I discuss using Domain Driven Design with an ORM, more specifically, my favorite ORM, LLBLGen.

Quoting from the first message:

For now, we’re going towards LLBLGen Pro 2.6 for DAL generation and such (using Self-Serving mode probably). Yes, we’re going for database first design, and not using NHibrernate. I’m hoping that we can keep those two issues for other threads :).

Right now, I’m going for other Domain Driven practices. I want to make sure using POCO classes is worth it, and then see how to have those in LLBLGen (which -LLBLGen main template- is in its internal not much different design than Active Record, which in many times is handy, it’s VERY rare t change DAL when one fits different DB providers with good performance), and what are common patterns to do Domain Driven Design at all when having LLBLGen as DAL (if it makes any difference – again: and if effort to make it encapsulated enough to make no difference is worth it).

Making this choice alone is worth its own article. Maybe should title it “In Search For The Perfect ORM” as well :-D.

UPDATE: Frans Bouma has a nice write-up about what is an ORM and different types on an ORM. It’s quite old (2004), but the concepts themselves are still valid.

My original question was:

So, is anybody here doing DDD and uses LLBLGen as DAL generator ?How does the experience look like ? What are common practices across all projects and what have been pitfalls ? etc… These are the kinds of questions I’d love to see somebody here with something to share about.

Domain Driven Design At Work

This is not really an LLBLGen issue. It is questioning the Domain Driven Design productivity itself. I like DDD. I see it as the natural next step after 3-tier deisgn. This whole separation of concerns, models, repositories, factories, infrastructure, and services paradigm just fits my mentality and view of how the world looks like. However, not all the practices in DDD are similar in terms of return of investment, the customer business value that Agile emphasizes. The trick is to know which are and which aren’t, and how to do the balance.

In the second message, I go through an example of typical usage for DDD that has tried just a little bit to be lightweight in some areas but not others, and my own overview about what needs improvement:


I’ve been on a project that leverages DDD once before myself. The project has been frozen for a while for other priorities, etc…Maybe I start with my own take on the subject!!
We’ve been using the “Adapter” model. I thought it was for seeking some sort of more control/flexibility. Reading Fran Bouma’s blog (, the creator of LLBLGen), I see how he’s so much of an “Entity Design” guy. Well, makes sense, he owns the best entity design I’ve seen so far having considered EF and CSLA.
Clearly he sees the “Self Servicing” as the core for entity design rather than model design. You know, the “entity.Save();” style. This makes me have two thoughts at a time actually. 1- That “Adapter” model is the right choice for DDD (I’ll get to that just below), 2- That maybe DDD fully is not what I really want (the entity Self Servicing style is so powerful. It has saved my day so many times before).
Looking at the project I’ve been working on, We had something like those namespaces / VS projects (and others … ):
Company.Project.Adt (for models that may be reused in other projects, like Language, Currency, …)
Company.Project.Model (for project business domain specific models)
Company.Project.Data (for LLBLGen stuff, we have also “DataDBSpecific” and such related to Adapter mode)
Company.Project.Repositories (have interfaces and implementations for repositories, let’s put aside why the two in one project for now)
A repository load method could probably look like:
  Category Repository:

<span style="COLOR: #ff8000">public</span> <span style="COLOR: #ff8000">static</span> <span style="COLOR: yellow">ReadOnlyCollection</span><<span style="COLOR: yellow">Category</span>> LoadByShop(<span style="COLOR: yellow">Shop</span> shop, <span style="COLOR: #ff8000">bool</span> includeDisabledCategories)
Or for internal use:
  Shop Repository:
<span style="COLOR: #ff8000">internal</span> <span style="COLOR: #ff8000">static</span> <span style="COLOR: yellow">Shop</span> Load(<span style="COLOR: #2b91af">Guid</span> shopKey, <span style="COLOR: #ff8000">bool</span> loadCategories, <span style="COLOR: #ff8000">bool</span> loadProducts)


What I want to highlight here is the “include…”, “load…” parameters. I’m not sure whether this is the best way to do it.
Also, what really hits me is the mapping. You know, from LLBLGen entities to our domain models. We have been doing this in factories which live in the Repository space. Each factory had methods similar to this:
<span style="COLOR: #ff8000">public</span> <span style="COLOR: #ff8000">static</span> <span style="COLOR: yellow">Shop</span> CreateShopModel(<span style="COLOR: yellow">ShopEntity</span> entity)
<span style="COLOR: #ff8000">public</span> <span style="COLOR: #ff8000">static</span> <span style="COLOR: yellow">ShopEntity</span> CreateShopEntity(<span style="COLOR: yellow">Shop</span> shop
Regardless of the “public” access modifier (this is all very well hidden behind a service layer, but let’s put the whole issue aside as well), the idea of having to go through all the mapping has been just a boring ugly task, that has been there for long.
To be honest, we didn’t get so much benefit of it. It should have good promises, but how good compared to the cost of implementing them for complex object graphs ? That is the question!
Things got just worse when we wanted to implement our service layer. That’s a service in the classic sense of “web” service layer (REST), we wanted to created DTOs that can correspond to XML and JSON responses of our choice, and again, we had to do the mapping from and to the domain models and DTOs. Want more ? The DTOs wouldn’t convert to XML strings automatically (to JSON it would), we had to have another mapping layer from and to the DTOs and the actual XML.
Of course we had much time defining XML specifications and writing so many unit tests for this. I know not every project can go in this direction to this extent, but, I wanted to show where going in this path can take you.
So, even without service layer complications. You still have the model mapping tasks that (and this is what worries me) in many situations does not correspond to a “business” need. Note that I want to be doing Agile as well, and this makes the issue of delivering business value a true concern.
You can talk about automated generation for mapping. This may be something. We know it’ll not be this direct or one to one of course anyway, but it may help.
Would you do Domain Driven Design with “entity” models assuming the developers will stick to calling the repository’s “Persist” method instead of “entity.Save();”? You just can’t do that! How about new developers ? How about inconsistencies ?
Is mapping really that bad and much of an effort ? First look at it, I say it isn’t. But given complex scenarios I’ve been though I have to wonder about things like “complex object graph” and “caching” (in memory, on different levels, etc…).
It’s all about trying to calculate the costs indeed.


That’s what I’m trying to make out of this, the trick for the right cost.

Conclusion: How About YOU ??

Let me repeat the end of those messages:

Anyway, would love to hear your takes and what you have :) :) :).

If you have any thought on the topic, those will be most appreciated. You can comment here or in the topic messages page on ALT.NET Yahoo Group. This is an open discussion area, and I do not expect it to be closed soon.

Same, if you want to hear more ramblings on the topic, or just want me to shut it up all, send me a line.

Would love to see what others have to say about this….

Share With Friends:

How did I learn that?

As a bonus for coming here, I'm giving away a free newsletter for web developers that you can sign up for from here.

It's not an anything-and-everything link list. It's thoughtfully collected picks of articles and tools, that focus on Angular 2+, ASP.NET (4.x/MVC5 and Core), and other fullstack developer goodies.

Take it for a test ride, and you may unsubscribe any time.

You might also want to support me by checking these out [Thanks]: