95% of all software applications is "not so good for using DDD"?

[Neylor Ohmaly Rodrigues e Silva]

 

Probably 95% of all software applications fall into the “not so good for using DDD” categories.(http://devlicio.us/blogs/casey/archive/2009/02/18/ddd-what-kind-of-applications-is-it-suited-to.aspx)

The author of this statement is correct? I know that DDD isn't about writing code but it's about that whole process BEFORE the code is written, it's about getting insight in what the problem is all about, what/who participates in which information streams and what do these elements look like, how do they relate to each other etc. etc. However at some point you need to write code and decide to apply the DDD/CQRS principles on the code. Its not clear when is good to apply DDD/CQRS principles while coding.

Thanks.

[Greg Young]

I'd say more than 5% but still a small amount

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[Neylor Ohmaly Rodrigues e Silva]

So "the big amount" of softwares should use Transaction Script, Layered and others type of methodologies and keep away from DDD/CQRS? They provide no value?

Em quarta-feira, 7 de agosto de 2013 18h42min21s UTC-3, Greg Young escreveu:

I'd say more than 5% but still a small amount

On Wednesday, August 7, 2013, Neylor Ohmaly Rodrigues e Silva wrote:

 

Probably 95% of all software applications fall into the “not so good for using DDD” categories.(http://devlicio.us/blogs/casey/archive/2009/02/18/ddd-what-kind-of-applications-is-it-suited-to.aspx)

The author of this statement is correct? I know that DDD isn't about writing code but it's about that whole process BEFORE the code is written, it's about getting insight in what the problem is all about, what/who participates in which information streams and what do these elements look like, how do they relate to each other etc. etc. However at some point you need to write code and decide to apply the DDD/CQRS principles on the code. Its not clear when is good to apply DDD/CQRS principles while coding.

Thanks.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[João Bragança]

Or even just lightswitch :)

On Wed, Aug 7, 2013 at 2:56 PM, Neylor Ohmaly Rodrigues e Silva
<nohro...@gmail.com> wrote:
> So "the big amount" of softwares should use Transaction Script, Layered and
> others type of methodologies and keep away from DDD/CQRS? They provide no
> value?
>
> Em quarta-feira, 7 de agosto de 2013 18h42min21s UTC-3, Greg Young escreveu:
>>
>> I'd say more than 5% but still a small amount
>>
>> On Wednesday, August 7, 2013, Neylor Ohmaly Rodrigues e Silva wrote:
>>>
>>>
>>>>
>>>> Probably 95% of all software applications fall into the “not so good for
>>>> using DDD”
>>>> categories.(http://devlicio.us/blogs/casey/archive/2009/02/18/ddd-what-kind-of-applications-is-it-suited-to.aspx)
>>>
>>>
>>> The author of this statement is correct? I know that DDD isn't about
>>> writing code but it's about that whole process BEFORE the code is written,
>>> it's about getting insight in what the problem is all about, what/who
>>> participates in which information streams and what do these elements look
>>> like, how do they relate to each other etc. etc. However at some point you
>>> need to write code and decide to apply the DDD/CQRS principles on the code.
>>> Its not clear when is good to apply DDD/CQRS principles while coding.
>>>
>>> Thanks.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "DDD/CQRS" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an

>>> email to dddcqrs+u...@googlegroups.com.

>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>>
>>
>> --
>> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>

> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to dddcqrs+u...@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--

Sent from my regular computer
http://twitter.com/thefringeninja
http://www.thefringeninja.com/

[Greg Young]

Access works well

[Neylor Ohmaly Rodrigues e Silva]

Lightswitch and access is for very simple apps, I think I didn't understand when DDD is applicable.

You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/AX8sm9mlkIU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Kyle Cordes]

On Aug 7, 2013 5:10 PM, "Greg Young" <gregor...@gmail.com> wrote:
>
> Access works well
>

Overkill, just use Excel. Or 3x5 cards. Computers are overrated...

Kyle

[Greg Young]

+1

--

You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Kijana Woodard]

I'm laughing here because I think this is basically correct, but I have the impression that the OP is not laughing and is probably frustrated with these answers.

I'd say most projects are both dramatically over engineered and poorly done. People get in their heads that they need layers and queues and what not when the traffic and business needs only require - save this data to the database.

That's if there is a so called architect involved. The flip side I see is people building monster controllers that do a hundred things. Then, when someone points out they could use a little abstraction, it becomes a massive rewrite to 'make everything asynchronous' or whatever mantra is invoked.

Either way, the brain is off and it's dogma all the way down.

[Neylor Ohmaly Rodrigues e Silva]

Making fun. It's very helpful.

You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/AX8sm9mlkIU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.

[Kelly Sommers]

Neylor,

Ignore the condescending comments. Don't let those get in the way of your willingness to learn the topic.

No process or architectural choices should be considered something you widely adopt. Think of the knowledge you gain like a toolbox of tools. When you have a problem that you find requires a certain tool, you yank the tool out of the toolbox and go to work :) I always like to think of things I've built in the past when learning something new. What could have benefitted from these techniques? Which ones would have been over complicated (or over simplified)? Why?

Which parts do you find the most interesting in relation to your line of work?

On Wednesday, August 7, 2013 7:47:06 PM UTC-4, Neylor Ohmaly Rodrigues e Silva wrote:

Making fun. It's very helpful.

Em quarta-feira, 7 de agosto de 2013, Greg Young escreveu:

+1

On Thursday, August 8, 2013, Kyle Cordes wrote:

On Aug 7, 2013 5:10 PM, "Greg Young" <gregor...@gmail.com> wrote:
>
> Access works well
>

Overkill, just use Excel. Or 3x5 cards. Computers are overrated...

Kyle

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

--
You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/AX8sm9mlkIU/unsubscribe.

To unsubscribe from this group and all its topics, send an email to dddcqrs+unsubscribe@googlegroups.com.

[Alfredo Casado]

It's funny how people use numbers, why 5%?, why not 6% or 7% or 9,5%?, if you don't have data don't use numbers, it's ridiculous.

In first place i make a clear distinction between CQRS and DDD, the first it's an architectural pattern that sometimes fit and sometimes not, DDD for me it's more a way to approaching software development. DDD it's listen to the bussines, it's using OO to model this bussines, it's a scape from the (usually) failing anemic models (aka transaction scripts) or fat models (aka active record and friends). 

I think that DDD, at least the most important parts (fundamentals and philosophy, concrete patterns aside), fits in every project, for me is another technique like TDD/BDD that i try to use allways. Off course if you want a CRUD don't use DDD, use a tool that make the CRUD for you with some form of scaffolding or naked objects. 

The problem it's that a lot of projects that begin with something like "only a CRUD with some validation" in a few months becomes a monster totally out of control, and when this happen someone say "we need to rewrite this!" and the history begins again... and again. 

2013/8/8 Neylor Ohmaly Rodrigues e Silva <nohro...@gmail.com>

[Kyle Cordes]

On Wednesday, August 7, 2013 at 7:13 PM, Kelly Sommers wrote:
> No process or architectural choices should be considered something you widely adopt. Think of the knowledge you gain like a toolbox of tools. When you have a problem that you find requires a certain tool, you yank the tool out of the toolbox
>

Here is an attempt at a more serious answer:

It depends on the kind of work you do. If you work mostly on complex enterprise data systems which encode a variety of deep domain behavior, you should probably consider DDD, CQRS, and such things for most projects - I know I have worked on a number of such projects that would have been much better of with these ideas baked in. If you work in other parts of the software world, you may find these ideas much less relevant.

--
Kyle Cordes

http://kylecordes.com

[João Bragança]

the thing is that guy in the article said he made up the number.

Just from my personal experience at my job, I'd say that 80% of the
'applications' here need two tier right to the database. There's no
collaboration, it's just simple things like 'update the royalty rate
for this IP license.'

Although I detest lightswitch, if the app just needs a couple of
screens then why not? Bang it out in two hours.

[Simon Timms]

My feeling is that DDD is a good approach for most applications. However a good percentage of applications reside entirely inside a single bounded context and don't need the rigor of CQRS or even a message based architecture. I wouldn't abandon wholesale such aspects as a ubiquitous language without consideration no matter how simple the application seemed.

As with all things you should think before just applying an application or process template.

[Greg Young]

Maybe the tenseness of my answer was confusing. I was being serious. Something like a modern access connected to a real database is "good enough" for a vast number of line of business applications. As written by others there is a huge amount of over-engineering that occurs. 

As Kyle pointed out even many of these systems in place can often without adverse affect to the business be replaced with far simpler answers.

[belitre]

@Alfredo, I think Eric's intent (or at least his recent claims in interviews, conferences, etc. about DDD) is not about " OO to model this bussines". All DDD is related to software engineering and finding the "best Strategy, Tactics and Models" that suite your problem for a special kind of systems: large or complex domain ones. Then he explains some practices, principles and patterns that can help you to tackle those.

So I would not say DDD is for every project. Software Engineering is for every software project. If it fits a particular category (big and complex) then DDD helps you with strategy, etc. And in many cases, as some have suggested, building a software system is not worth. Use access or python console and csv files :-)

And even if you choose DDD, then finding the right model for each Core subdomain (Functional, OO, Geospatial, AST, Logical, neural network...), not necessarily OO.

[Sławek Sobótka]

I meet about 30 teams/projects a year; my thoughts: root of all evil is excessive generalization - one app. and sys. architecture, one tool set, one methodology, one management style, one delivery process etc. for entire project.

In medium+ scale project you'll find all classes of complexity. Using/not using DDD in whole project is just naive. As belitre said: distill core domain (with subdomains), apply appropriately application and system architecture and rest... access (or RoR;)

Hard part is to spot complexity and classify it.

[Alfredo Casado]

@belitre, you are right, DDD it's not only OO. OO it's my default approach but of course there are subdomains or complete systems that fits better with other paradigms. 

but i not sure to agree with "DDD only for big and complex projects". I think that big and complex means different things for different people based in his past experiences. In my experience a system becomes "complex" only with a few thousand of lines, other people thinks in millions of lines when thinking about big&complex (i know that lines it's not the best measure, it's a example). 

I really don't see a situation when apply things like "ubiquitous language" it's not a good practice. I prefer to begin a project with the domain and delaying infraestructure decisions (such as the UI or persistence) following the lean principle to "decide in the last responsible moment". When i talking about using DDD i'm not talking about using the full pack of patterns in every corner of the project, i'm talking as a way of approaching software development focusing first on the domain, and i think in this as a good practice equals to other things like TDD,BDD, SOLID etc,etc that i use in every project.

I see a lot of projects fail because the focus it's on the technology stack (.net, java, RoR whatever) or in the persistence layer (use sql?, use no-sql?), or the messaging system or... and the domain is somewhere between hundred of lines of technology stuff. 

2013/8/8 belitre <bel...@gmail.com>

[Bennie Kloosteman]

That has to be qualified by the word excesive , we did the sums once on BT (which we bought) and compared it to other merchant banks and their costs were way cheaper  by standardising , they mainly used  VB and Excel and windows servers  ( with a very small amount of C++) and used lots of apps not big apps . We and the other merchant banks had a horses for courses approach Solaris / Linux /Novel /Windows server  , PC and Sun HW,  PowerBuilder / Java /.NET  / SmallTalk / Excel /VB / some C++ and COBOL on mainframe.  On the other hand a gov company had a single app that did everything , was expensive and it wasnt very good .

Its also work noting technologies are expensive to introduce but once used get cheaper , CQRS ( with Sagas) ,  SOA  and the expensive middleware solutions are all like  this , and most of the cost if getting experience in the relevant technology.  

[Bennie Kloosteman]

Its good to have some focus here , the cost to become skilled and productive on these stacks take a lot of time.. eg while i can write C++ and Java the fact im not experienced in the newer libs mean im probably 5* -10* more productive with C# ( even though i spent 10 years on C++ in the late 80's and 90's) . Persistance schemes also cost here getting highly skilled in EF , Hibernate , SQL  is not cheap. Cross machine messaging systems also require building up skills etc .. If you are going to throw away a previously built up skilled set then you need to build a pretty compellign case. 

That said i know what you were saying when a company i was at , was introducing SOA , all the focus was in the business speak and consulting eg  business alignment , should we have middle ware or Orchestration /BPEL etc etc . They paid no attention at all to the actual service designs , messaging , service granularitty , cross machine costs  , etc . That said the  BA ignored that and focused on the domain .. 

Ben

On Thu, Aug 8, 2013 at 7:50 PM, Alfredo Casado <casado....@gmail.com> wrote:

@belitre, you are right, DDD it's not only OO. OO it's my default approach but of course there are subdomains or complete systems that fits better with other paradigms. 

[Alfredo Casado]

The cost to be productive in a concrete technology stack is very, very low compared to the cost to master the fundamentals like design principles. If you have the second the first is really cheap. For example, if you really understand what and ORM is you can use EF or Hibernate/JPA only reading the relevant documentation in a few days (or you can choose to not use a ORM at all...), the same goes for MVC, the same for Object Oriented (few weeks perhaps in this), the same for messaging systems, the same for everything. IMMO, the excesive focus in concrete technologies is one of the big problems of our industry. 

"That said the  BA ignored that and focused on the domain .. "

This is exactly the opposite problem, DDD promotes collaboration between domain and technology people, if you forgot one of the sides you are doomed.

2013/8/8 Bennie Kloosteman <bklo...@gmail.com>

[Tom Janssens]

Access does work well... until it stops working well ( clarification ).

 
Op donderdag 8 augustus 2013 00:10:23 UTC+2 schreef Greg Young:

Access works well

>>> email to dddcqrs+unsubscribe@googlegroups.com.

>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>>
>>
>> --
>> Le doute n'est pas une condition agréable, mais la certitude est absurde.
>
> --
> You received this message because you are subscribed to the Google Groups
> "DDD/CQRS" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to dddcqrs+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Sent from my regular computer
http://twitter.com/thefringeninja
http://www.thefringeninja.com/

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Kijana Woodard]

Whoa. That was one of the most disturbing threads I've ever read...then I went to the blog............

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.

[Jörgen Andersson]

Hi,

A few years ago I too wrote a blog post on this topic. And I arrive at a somewhat different conclusion.
http://se-thinking.blogspot.se/2011/10/is-domain-driven-design-always.html

I think that there is always a value in keeping your model true to  the business, i.e develop the ubiquitous language. Why? Complexity will almost always grow, even if it seems to be simple at the beginning.

Jörgen

--

[Kijana Woodard]

I think most software doesn't grow in complexity, it dies. Not because the software wasn't obeying paradigm X or didn't have enough layers, but because the business has changed or died.

To compensate for this in suggest keeping the software as small and simple as possible so that _when_ you need to throw it away or rewrite, the impact is minimized. In the same vein, writing many small apps that are focused helps such that different parts of the business can change and evolve independently.

If they really need to coordinate, here is where you start your 'architecting'. The #1 problem I run into with clients it's not bad code, which is plentiful, but the mega app and mega db that was supposed to solve everything. What really happened was a bbom and now no part of the business can make a move without risking the entire operation.

[Alfredo Casado]

Jorgen: i agree 100% with your post, reflects exactly my experience.

Kijana: Of course keeping the software as small as possible it's always a good idea. Keep things small it's the first and most important weapon we have to fight against the complexity. I have this poster from brian marick always near (http://www.exampler.com/images/posting-medium.png) :P

But simple it's not the same as messy or disorganized. I'm not very sure what "architect a system" really means for you, but i prefer 'architecting or designing' my system from minute 1 of the project, for me architecting/designing it's related to make thoughtful decisions, your decision can be separate your system in small apps for keep it simple and isolate changes in different parts or the business, this is not architecting?. For example, how you identify and divide this different pats of the system?, DDD says that you need to collaborate with the business people and identify this different parts of the system (aka subdomains) and with this information you take the decision to divide this in different applications/services/libraries (aka bounded contexts).

It's seems that a lot of people view DDD overkill for small projects, perhaps this it's because the example implementations with the typical DDD patterns you can see out there are really complicated (or simply terrible implementations). I think that it's perfectly compatible be simple and build emergent architectures with DDD. For me using DDD it's a way of thinking and a way or organizing my code that really not add more complexity than others, not using DDD because it's overkill for me it's the same to say that SOLID principles are overkill or that TDD it's overkill. It's overkill only when you don't have the experience with this techniques. 

Keep a system simple it's not easy, in fact, i think its the most difficult part of develop software.

2013/8/10 Kijana Woodard <kijana....@gmail.com>

[Kijana Woodard]

I don't really disagree with anything you've said. Simple is hard.

The problem I see is people layering on 'best practices' for their own sake without thought or analysis. This type of system is much harder to tangle with than someone's slap dash crud app that's outlived it's usefulness. For one, mgmt has invested a lot of resources in order to 'do things right' and they still have a bbom.

To me, the hardest part about writing software is wrangling all the politics and egos in order to surface the lurking business requirements. With the proper business requirements, most code becomes trivial.

[Jörgen Andersson]

Hi Kijana,

In my experience business apps don't die because business changes so much they become obsolete. I see them die because they can't keep changing as the business does and the reason for that is complex code with a model without true connection to the business making them impossible to continue changing. That is what I call technical debt and is something to carefully manage. I always strive to do that through two basic rules:
1. Never ever mix business code with technical solution. I.e keep business logic in the domain and technical issues in the integration/anti-corruption layer.
2. Make sure the domain model is true to the business so that a small change to the business always is a small change to the system. Developing and using an ubiquitous language the key for that.

Both these basic rules have I collected from DDD. Stepping back a bit in the process you'll find context mapping and strategic design, also valuable tools from DDD. That's why I say it is always applicable.

Jörgen

[Kijana Woodard]

I don't disagree. I use pieces of ddd in a similar fashion. Same with agile. Same with soa and cqrs. I can't say that I've ever worked on a 'ddd app' though.

Large organizations tend to be designed to keep developers and end users as far apart as possible. Endless layers of middle managers taint the UL. The best substitute I've found is to, somehow, get someone with decision making authority in the room (vp+). Makes a world of difference in separating the wheat from the chaff.

In the end, clearly designing a piece of software to meet a business need wins over any technical ideology. If one wants to call that ddd/bdd, fine.

To bring this conversation full circle, there are many times where 'dump data into excel' is the right answer for the business.

[Bennie Kloosteman]

Agree with this , modularization is crucial ,  it doesnt matter whether this is lots of small access apps , OO , SOA or CQRS /DDD those are just methods but make sure the system is modular .  Not sure about keeping it small as possible , id rather 6 small independent modules than 2 medium apps even if its more code.  

"re Bussiness apps dying "

Most cases i have seen the business wants to spend the absolute minumum on old software and put the money in new software where they can make more money ( which is good) .. After 10-20 years the old software is so out of date and it so hard getting people for it  , that you need to move  or just keep it going as best you can ,,  Anyone going to do a major enhancement  / rewrite of  VB 6 or earlier basic   , COBOL  , Small Talk , Power Builder , Progress , Pascal / Modula , LISP etc etc ?     

Ben

[Bennie Kloosteman]

I should add technology does not allow people to write modern UI is a very common reason for apps to die... which is why its useful seperating the gui from the logic ..  

[Kijana Woodard]

Well, we're pretty far off OT at this point, but...

Apps sitting on a shelf with no owners and no maintenance are dead.

What do I mean. Imagine a well crafted FoxPro app with proper modular separation. No one has looked at it in 10 years. The users have been doing their jobs and adding subtle user hacks to avoid "getting IT involved". Now someone comes along and gets funding to "put this on the web". The chances that "just the UI" gets rewritten are as close to zero as I can imagine. :-)

And, yes, I have seen a 10 year old FoxPro apps in the wild. Afaik, they have survived all attempts to rewrite them. :-D

[Bennie Kloosteman]

Dont think its OT because it relates to over engineering and app life cycles which relates to whether to use DDD. 

I remember when we did the organization wide update to XP there were still some windows 95 machine with  16 bit apps... ,in 1 department  1 was a DOS app in  some form of basic  ( not VB or GW)  the other was Clarion ...  both were  still doing something for the business ...  Basically we just left the windows machines  under the desk and gave them a second machine .. They now got a $560 per month extra recovery bill for 2 PCs which eventually forced them to move 1 app to excel.. ( which cost them about $800 from the inhouse department) .

Your foxpro shows an interesting point  , if it did have a seperate UI then it could have just got a new web front end  ... but  the cost of building it with a seperate UI would have been much more expensive ( not to mention integarting with an old technology) so rewriting completely 10 years later  to put it on the web is in most cases the best way to go . Though you could test the busines case with Citrix on the web , to deliver to clients first .and if the case is made rewrite it .

The UI rewrite is something for ISV ...I had a good laugh when matlab got Office style ribbons. Though for some business modern UIs can be important a lot of equities apps moved to WPF for that reason. 

I think the fact most solutions are over engineered is preventing businesses risking new apps due to high costs - this is especially an issue in Australia. If there were more quick and dirties - IT would get more project and more done .. Im especially miffed at the cost of a new business idea where a small startup  group in a large company has to wear the cost of a maintable app when 70-80% of the time the bussiness may not e viable ( especially when saddled with the IT costs) 

Ben