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….

Joining RAYA Software in October

I’m joining RAYA Software starting next month (October), part of RAYA IT, a business line of 3 main business lines that form RAYA Crop., a well known name in the IT industry over the Middleeast.

My role is very interesting. The entire company is interesting to me, not just for the size and brand, but for the nature of how things are going in there nowadays, which makes RAYA the perfect place to join at this specific time.

About the role

I’m joining RAYA with the same title I hold current, a senior software engineer, yet, I’m going to be a member of a team of only 3 guys, M. Yosry, whom I haven’t met but is said to be a real guru by all guys I met in RAYA, M. Zahaby, an ex-RAYA returning in it recently and a personal friend of mine whom I had technical chats with and even worked with in a single freelance and knew what kind of a geek he really is, and myself!

The team is very special inside RAYA Software. We as team are responsible for helping other teams standardize coding practices all over the company (well, this is all within Microsoft technology development teams, I know nothing about Java technology department), and help other team leaders and members implement agile processes (specifically Scrum) in the way that fits work nature in RAYA. We stand with other teams in design sessions and researches/investigations required for specific projects, and we help create and enhance a rich toolset, reusable components and modules over applications. We work with all other teams and report directly to the "Microsoft Partnership Manager", El-Mohanned, who is like the CTO for Microsoft technology development, and a very interesting guy as a boss. Both very respectable, and still having his geek nature deep inside not affected by his current high management rank!

About the company

RAYA is a well known name in the software industry. Like many big companies, it had its special advantages, and eve problems. These days, the guys at the company starting from junior developers, the the GM, Aly Zweal (not sure of the spelling), whom I really enjoyed meeting him as a part of my recruitment process. The guy has a great smart mentality that measures the technical aspects to the business aspects for just the right balance, and whose meeting was as well as  El-Mohanned’s description of the interesting job duties some of the main reasons I accepted the job offer.

Right now RAYA is going through some really revolutionary changes. The smallest of those are switching to Scrum and migrating many projects to using latest technologies and having a big yet very precise recruitment campaign. The company’s line of business is rebuilding itself for more progressing forward, which makes it the perfect time to join and share in this building, especially when the role allows more impact on this process.

Regarding Agile, it’s cool how El-Mohanned’s first communication with me included a link to one of the two videos he uploaded to YouTube, "Raya Software Goes Agile":


This is the technical part, which is for someone like me a must-have base for having talks about anything else. But still, there’s more about RAYA Corp. in general. Belonging to a big corporate is another paradigm that I lived some of its blessings in my previous company GNS (Gulf Network Solutions). Now, I’m into the full experience of living within a corporate environments. It just helps you think differently about your entire life, and opens new areas to think about. A worth-it experience indeed that many people once taste find it very hard to change.



Oh, yeah, by the way again, RAYA is hiring! I mean it. THERE ARE OPENINGS. There’re openings for junior and senior developers, team leaders, and testers. You can check the careers page, and send your CV to the email mentioned under each vacancy, or to El-Mohanned, or simply to me! Hey, make sure to specify the position you are applying to in the email subject please. This is the rule, isn’t it? :D


What about SilverKey?

That’s what SilverKey is to me:


Geeky days and even nights, company kitchen talks, volunteering entire public BIG free DemoDay events, pre release tools and platforms, varying nationalities, cultures and mindsets, wedding and birthday and even farewell parties, virtually wearing multiple hats at work(roles), analysis and design negotiations. launch celebrations treats, Scrum process customizations, teamwork, Dody and Alia’s guitar, having breakfast in Ramadan tent, …

There’s much about SilverKey that I cannot explain by just saying. It used to be almost my house for more than two years now. I think I know about some of the people there more than I know about my own family and maybe same for them. There’re people who sure have made a difference during this period, Dody and Kent come on top of those. There’re guys who make for best friends like M. Nour. There’re some special personalities that are hard to meet occasionally like Amir Magdy, H. Zein and M. Tayseer. There’re people who are not just interesting as techies but have their own other interests like Ahmed El Malt and Tamer Zaki and Karim Ennarah. There’re fun foreigners like Sharron, Tosin, and, very quiet yet still really fun foreigners like Brian, Chris, Luke, David, and Olivia. There are very passionate and promising guys like Kariem Soudy and Amr Ali, There’re true fun guys like Mostafa Murad (AKA, TATA beik), M. El Sayyed (AKA, SAYYYED), Emad (AKA, iMAD), and M. Alaa (AKA, Developers friend). There’re kind guys like Ibrahim Marzuk and Taher. There’s an old buddy and community partner, Mohamed Hossam (AKA, BASHMOHANDES), business guys like Adam and Farid. And there’s for sure M. Kassem and Ahmed Ali and so many names that it’s easy to miss a lot of those over different generations (by the way, no categorization intended!). Although not so many of those names are still there today that most guys will not recognize the rest of all other names, this is much to carry for the company itself.

If it was only that I met Mona, my lifetime love, current fiancee and soon my wife (God Willing), and, the girl I believe is the best to exist in our world today, I met in occasions all related to SilverKey, that would be enough.

So, technically I’m not leaving SilverKey completely for the upcoming while. Afterwards, who knows,, most likely the new generation will take over on its own afterwards (God willing).



The thoughts and states expressed in this post and entire blog are solely mine. Neither of my past/current/future employers nor any of their employees/owners hold any kind of responsibility for or commitment to any of them, even if mentioned in behalf of this employer.