1

I spent short time studing Habanero and i found it good approach for making Enterprise Application in a really short period of time. The pattern witch Habanero use is "Active Record" as it's developers say. My questions are:

  1. There any similar application like Habanero witch fully support Domain Driven Design by determining aggregate roots, entities and value objects
  2. Is it right decision to use such tools in big organizations
  3. Does it worth training our team on such a tool

thank you

ghazyy
  • 649
  • 2
  • 7
  • 22

1 Answers1

6

Framework support for Domain Driven Design is quite different from frameworks supporting data driven applications. Such framework should increase the productivity of developers that works with an ubiquitous language that evolves with the business and that is learned by a domain-expert.

They should not face concepts like aggregates, root, value objects because they are just modelling concepts, conceptual tools, but ways to ease the development process. Thus a framework exposing abstract classes or interfaces named AggregateRoot, Entity or ValueObject is fundamentally broken. It doesn't provides any real value to an application, just useless indirections.

However:

  1. There are a few frameworks designed to support domain driven design, listed here. Moreover, I'm developing one by myself based on previous experiences that worked very well
  2. It depends, obviosly. For example we used all of the Epic's modeling patterns with success.
    We used some "home made" framewoks too, and some of them proved to really increase productivity. However, such frameworks (if useful) always have steep learning curves and it depends very much on how much reliable the software have to be and what are the developers skills.
  3. It depends on the framework, on the complexity of the business (if you don't need a domain expert to understand it, you don't need DDD) and on the developers, too. I faced successful stories and huge failures with different frameworks in different contexts. I've also had a conference that faced the topic (you can see the slides here).
Giacomo Tesio
  • 7,144
  • 3
  • 31
  • 48
  • "Thus a framework exposing abstract classes or interfaces named AggregateRoot, Entity or ValueObject is fundamentally broken. It doesn't provides any real value to an application, just useless indirections" - I don't agree with this, I'm successfully using similar framework ([CoreDdd](https://nuget.org/packages/CoreDdd)) to model domains on couple of projects. I think it helps a lot to be able to inherit from Entity or mark an entity as IAggregateRoot, my 2c – xhafan Apr 10 '13 at 16:55
  • @xhafan I don't see much value in using DDD to send emails. A nice object model is not a domain model. If you don't need a domain expert to understand the business, you don't need DDD. If you have to understand one or more domain experts, handling aggregate roots is the last of your problem. You will have to learn his language and business deeply and you will have to model a complex, well documented, codebase that everybody else must be able understand quickly. If you know what an aggregate root is, you know that an interface cannot enforce invariants. Thus is needless. – Giacomo Tesio Apr 10 '13 at 23:52
  • 1
    A developer should be able to understand the code from the code itself or from its unit tests, not from "well written documentation" which is always out of date. I believe there should be no code documentation. If it's not clear from the code or its tests, refactor it so it's clear. That's why seeing that something is an aggregate root (implementing IAggregateRoot) or an entity (inheriting from Entity base class) immediately helps understanding the code. – xhafan Apr 11 '13 at 07:16
  • @xhafan in most object oriented projects, you are right. In those 5% that require DDD, believe me: documentation is as important as code. Sometimes even more. In particular it's important in C# where we miss checked exceptions and the only way for a client to know what can go wrong with a call is to read up-to-date documentation. If the business rules are complex enough to require the hire of a domain expert and you have more that ten people that need to grasp it rapidly to be able to do their job, the code documentation (and vision statements) is really a must. – Giacomo Tesio Apr 11 '13 at 07:32
  • And note that this does not means that the code itself is not readable (on the contrary, domain models of mine often form internal DSLs), just that the ubiquitous language has to be explained, since you can find the same concept with slightly (or completely) different meaning and rules in different bounded contexts. – Giacomo Tesio Apr 11 '13 at 07:35
  • Example why comments are not needed: a very accepted answer which suggest "why" comments are good: http://stackoverflow.com/a/209089/379279 and a even better "no comment" solution for it: http://stackoverflow.com/a/210414/379279 I just believe that almost every comment can be transformed into a method name (even long) or baked into a code. – xhafan Apr 11 '13 at 20:20
  • @xhafan I'm glad it works for you and your team. To me, I've read ton of (almost) undocumented C code and I had no problems with that. Still, in a DDD project I won't hire any modeler that refuses to document what he learn from the domain expert. Self documenting code is often fine for technological problems (like sending emails, tcp connections, device drivers and so on), but not in domain models. – Giacomo Tesio Apr 11 '13 at 20:30