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]:

  • I think most people make the mistake to think that ‘DDD’ is some sort of technical methodology which they can apply to their software project and all will be OK.

    This is *wrong*. DDD is a way of thinking what controls what, what comes first and drives the rest. That’s also why one of the most important aspects of DDD isn’t the repository stuff, but the Ubiquitous Language you’ll define with the domain expert(s).

    The funny thing is: once you focus on that, the main things which are important aren’t HOW to implement repositories or even IF you should use those, that’s a technical choice of ‘a’ (not ‘the’) implementation, but WHAT is the application all about, which entities are defined etc. etc. Something which can result in a database model (from a NIAM/ORM model for example) which then in turn is used to produce a DAL.

    The thing with a lot of developers is that they focus too much on ‘code’ and that writing code is the way things are solved, because that’s what they do, forgetting that you first have to understand what you’ll write before you can write it.

    Check the DDD mailinglist for example: it was asked a couple of times a week: How to apply DDD to code… how to solve this or that with repositories etc.

    If those questions pop up, one is clearly on the wrong track. the right track should be:
    – identify problem
    – find solution
    – implement solution

    If you have problem X, and repositories are the solution for X, implement repositories. Though don’t implement repositories because someone said so: it’s not as if using repositories, aggregate roots etc. is going to make your software great and bugfree all of a sudden.

  • Btw, I now read the thread in the mailinglist… Like I said: most people think DDD is some kind of technical methodology.

    If you want a true answer, come to our architecture forum, I’m sure you’ll get more mature answers there than from people like some who can’t restrain themselves from showing how little they actually understand about the stuff they try to talk about every day.

  • Hey Bouma,
    Nice to have you into the discussion. Actually I have seen a start for a similar discussion in the forum, a non answered question actually :).

    I agree with you about that it’s mainly the concept that matters, the mindset. That’s where all the obsequious languages and implementations come to support later. I’m trying to get around “what controls what and what comes after what” with naming specific implementations for these, like saying LLBLGen instead of DAL, etc… Right now I’m at the stage of evaluating how specific implementations may be affected by this mindset (Sure, this is not the first step in thinking about it, and I did not say it is).

    Regarding ALT.NET, you realize things like “let’s put that aside” and “keep it for another thread”. You see, such sentences are there for a reason. I just know whom I’m talking to :).

  • “Actually I have seen a start for a similar discussion in the forum, a non answered question actually :).”
    The architecture forum isn’t a forum we monitor for questions to answer, so it might be a question isn’t picked up by the community.

    If you want to go for repositories, I’d go for adapter, and simply use the entity classes in the application, not using DTO’s. The thing is that you use a db first approach anyway, so the whole DTO mess is actually just overhead for no reason. The persistence logic is inside the repositories, the rest is outside the repositories. As Adapter doesn’t have ‘save’ or ‘fetch’ methods on the entity, it needs a persistence object (DataAccessAdapter) in the repositories, but outside these, you aren’t seeing any persistence oriented logic.

    If you look at DDD from a more abstract point of view, you’ll see that it is about determining which entities there are in the domain and how they relate to eachother. If you then apply that to a db schema and reverse engineer it to an llblgen pro model (incl. inheritance for example), you’ll get code which represents what you’ve defined on the more abstract level, the entities defined are there.

    Technically, you can separate your persistence aware code inside repositories, but keep in mind that repositories are just ‘a’ way to group code which is persistence oriented.

  • Exactly, that was the successful part in the mentioned implementation. I was and still am) interested in whether there`re further related thought :) :).

  • Further thought should go into solving problems which occur along the way, and I therefore don’t believe in ‘do this (e.g. repositories, aggregates etc.) and it will work’. If using entity classes with repositories give problems in some area, these probs should be addressed.

    One area where you need to look at for example is: how do you specify what to retrieve from a repository (filters, prefetch paths)? How are you going to address cross-repository queries?

    You’ll see that if you work with graphs of entities, the repositories get in your way.

  • This is one important place where I would love to see alternative implementations. The “load…” and “include…” were one example. I can think of one or two more. It can be in multiple ways and the discussion is about which some guys tried and with what success. Of course in this area and similar areas as well. You are pointing at one part of the core of the conversation right now :).

  • … with no underestimation for the value of other areas to discuss in DDD of course.

  • From Frans comment, one of the complex problems I really face when implementing the repositories is the cross repository queries. For example, I remember in my application I have a “ShopRepository” and I was thinking about either I have to load the shop categories – which has a separate repository – when loading the shop or not. Do I need to call the CategoryRepository from the ShopRepository or what? What about the number of the reads and calls to the database? Many questions…

    Also the updating of the models and how to manage this in the repository. How to reflect the changes made in the model and how the repository should do to track only the changes made in the model and do the actual update in the persistence medium. This is another problem and I am interested to know the best practice in doing that.

  • “one of the complex problems I really face when implementing the repositories is the cross repository queries.”
    Exactly. Chad Myers, if you’re reading this, this is what I meant. I DO get DDD, trust me.

    The main problem with repositories isn’t that they’re somehow flawed, that’s not it. The main problem is that if you have two agregate roots, e.g. Customer and Order, and you want all Orders for all customers from Sweden and load these orders WITH the customer entities attached to it (so you’ll get a graph), you have to effectively use 2 repositories: the order repository and the customer repository, but… how will they interact? Will the order repository contact the customer repository? Will you pass on all orders to the customer repository in some form of specification? How will you merge teh customers into the orders, efficiently ?

    What Mohammed Nour El-Din illustrates above is precisely the problem I referred to: he wants to do something, but the repository gets in the way: it’s too focussed on a single entity instead of working with graphs, but the entity usage in an application is about graphs, not about single sets alone: that’s the advantage of having objects in-memory instead of flat tables.

    To Mohammed Nour El-Din I’d say: write the code which does what you *need* in your application. If you need to fetch the graph, write code which fetches that graph for you. In the end, that’s what matters, not if you’re compliant with some book.

    “Also the updating of the models and how to manage this in the repository. How to reflect the changes made in the model and how the repository should do to track only the changes made in the model and do the actual update in the persistence medium. This is another problem and I am interested to know the best practice in doing that.”
    This comes down to the same root cause: if you use repositories, you’re focussing on separating the sets of entities in separate groups. This can work properly, however if you want to work with entities across repositories, you’ll have to add code to make this work which will likely create a web of references which makes the code less maintainable.

    Btw, what you describe above is the job of an o/r mapper which does more than simply creating objects from data rows. It’s entity management: you write the code which consumes the entities, and the rest, the infrastructure, is taken care of by the o/r mapper. After all, your customer/client isn’t paying you to write infrastructure code which is available on the shelf, he’s paying you to write code which will make his problem go away.

  • Muhammad InfoQ, Domain Driven Design Quickly link is broken

  • Pingback: get seedbox()

  • Pingback: gvk biosciences()

  • Pingback: zd porn()

  • Pingback: DMPK()

  • Pingback: lose weight spa()

  • Pingback: how to make money with a iphone()

  • Pingback: iraq Seo()