Re: Re: Has DDD reached it's embracing tipping point or not?

Hi Giacomo, thanks for your feedback. As you say, DDD really starts to pay
off in domains where the complexity of the system is high in addition to
the competitive edge that can be earned by tackling this complexity very
well. We've all seen the charts that show that the initial investment of
DDD is a bit higher compared to 'regular methods', but if done right,
maintainability and therefore productivity remains stable and can even
increase while the system grows and more features are added.

As in your case, where the stakes are high ($$$) and a lot of business
value can be added, the business is usually more inclined to invest - in
better developers, cutting-edge technology, etc. For some systems this is
immediately obvious, mostly for systems the organization hands out to their
clients to use (financial systems, amazon), but less obvious for
internal/support systems I guess. I've seen a lot of money going down the
drain, though, because these support-systems were a nightmare to
maintain/extend, yet had to be maintained for obvious reasons. Perhaps the
choice for DDD can also contain an estimation on the estimated lifecycle of
the system (?).

On Thu, Feb 21, 2013 at 11:45 AM, Giacomo Tesio <[email protected]> wrote:

> **
>
>
> The point, IMHO is the business complexity vs the technological challenges.
>
> Most of enterprise softwares gains a competitive advantage by solving
> harder technological problems than competitors (scalability, high
> availability, computational performances and so on).
>
> While expensive in itself (you need at least one domain expert, good
> modelers, senior OO programmers and so on...), DDD is the cheapest approach
> when the competitive advantage comes from the business experience of the
> domain expert that becomes accessible to all the users through the software.
>
>
> In our financial applications we face hard technological challenges, but
> the value that the customer recognises and pays comes from the management
> of a complex business process designed from a set of authoritative domain
> experts.
>
>
> My 2 cents,
>
>
> Giacomo
>
>
> On Thu, Feb 21, 2013 at 10:25 AM, Willem van Gool <[email protected]>wrote:
>
>> **
>>
>>
>> Sameer, this is my point exactly - or at least my point of view regarding
>> my own company/section. It seems that as many companies have eagerly
>> invested with their best intentions to standardize their templates and
>> approaches to software development, they've locked themselves into a one
>> size fits all approach based on a somewhat naive way of development.
>>
>> Now I'm not saying that data-driven approaches or transaction script
>> should be avoided at all cost - they have their place for the simpler, crud
>> based data management systems. Moreover, templating/standardization is
>> certainly a good thing, but for an industry that's usually so quick to
>> adopt and innovate, I find it rather surprising that after almost ten years
>> after DDD was formally introduced, I see very few actual appliances of it
>> in the field. I realize this is only my view of the situation, so that's
>> why I was so curious to hear from the rest of you about your perspectives.
>>
>> Perhaps it is indeed because too much 'theory' on DDD has been placed on
>> forums and blogs and very little books have been published explaining the
>> entire material with more practical guidance on it (at least if you compare
>> it to [Put your hot new MS Technology/Framework Here]).
>>
>> In addition, when discussing/proposing DDD with several of my peers or
>> some of the architects I have worked with I noticed that many of them A)
>> don't know what DDD is or B) think it's just another niche-type of approach
>> only to be used for only really special/niche type of systems.
>>
>> Other than that, I also think it has to do with the change of mindset it
>> requires compared to data-driven, crud-based type of development, like
>> asking someone to drop C#/Java to use a functional language for the next
>> project. Surely, it can be done and I feel that any serious software
>> engineer should be able (and willing to) adopt and broaden their spectrum
>> of capabilities, but new approaches can have a steep learning curve which
>> is also considered a risk in practice (and it is, of course), while the
>> possible benefits remain unseen to the untrained eye.
>>
>> With more and better books being published on the subject, I'm beginning
>> to see a shift in interest, so I guess we are slowly moving from the early
>> adoption phase towards the tipping point of massive adoption...we'll just
>> have to see :)
>>
>>
>> On Wed, Feb 20, 2013 at 8:55 AM, Sameer Patil <[email protected]>wrote:
>>
>>> **
>>>
>>>
>>>
>>>
>>> The Enterprise applications develoment community is still at large not
>>> embracing DDD. From my personal observations i am listing the top two
>>> reasons which i felt is holding them back which are indeed limited to my
>>> expodure within the offshoring teams.
>>> 1) They are so used to doing to the transformation of business model to
>>> tech specs in their inhereted documentation template/framework. Being from
>>> the service industry the development methodology needs to go through the
>>> standard documentation template prescribed by the. When i exposed a few
>>> teams to the DDD they agreed that it helped them in understanding the
>>> domain better and also resulted better code quality.
>>> 2) Secondly there needs some more determination even from the domain
>>> experts who are ready to invest time with a development team. Sometime i
>>> have seen dropping the DDD approach due to non availablity of the domain
>>> expert.
>>>
>>> I also feel there is need for some more materials/books on step wise
>>> guide to emracing DDD. Some books similar to "Embracing TDD" or "successing
>>> with agile"
>>>
>>>
>>> --- In [email protected], Willem van Gool wrote:
>>> >
>>> > About five or six years ago, I picked up the Blue Book because I was
>>> > looking for better ways to design and code the systems I was working on
>>> > then. I guess that as many of you who visit this forum regularly have
>>> been
>>> > on a quest to find better methods to design and code our
>>> software-systems
>>> > than the transaction-scripty, data set oriented systems we have been
>>> > working on for years. Unfortunately, few people within our company
>>> (size
>>> > about 300) are familiar with DDD-concepts, and because of all corporate
>>> > standards are based on the old, data-oriented methods of engineering
>>> and
>>> > architecture, it has been really tough convincing people to 'give it a
>>> try'.
>>> >
>>> > On the other hand, especially with the release of Vaughn's book just
>>> > recently, which is in excellent read by the way, I have the feeling
>>> that
>>> > DDD is really starting to take off everywhere. This got me wondering
>>> about
>>> > the world-wide adoption of DDD: has your company embraced it
>>> completely (or
>>> > do you apply it often as a independent consultant), or is it still
>>> > considered 'just a hype' by your peers?
>>> >
>>>
>>>
>>
>  
>