Is DDD and CQRS a form of OOAD?

[Kelly Sommers]

Here goes my first question on this list :)

I was reading up on OOAD (object-oriented analysis and design) after it was pointed out to me. It looks to have some similarities to DDD. Is it safe to say DDD is a form of OOAD?

This quote struck me from Wikipedia

Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it.

Also this quote

Object-oriented analysis (OOA) is the process of analyzing a task (also known as a problem domain), to develop a conceptual model that can then be used to complete the task. A typical OOA model would describe computer software that could be used to satisfy a set of customer-defined requirements.

Also mentioned is the possibility of dividing into several sub domains each representing a different business, technological, or other areas of interest. Sounds kind of similar to a Bounded Context?

Granted some of the approaches mentioned in OOAD for analysis (UML etc) are more frowned on these days then maybe in the past but it feels like DDD is a form or approach of OOAD. 

Would that make analysis on choosing if a Bounded Context requires CQRS part of OOA?

Interested in your thoughts

Kell

[Jimmy Bogard]

I've always viewed the code part of DDD as OOAD, with a specific bent toward modeling the behavior in the domain model itself. You're doing the same sorts of code smell/refactoring techniques you would do in other models, but geared towards encapsulating data & behavior inside the domain.

[Clemens Vasters]

I think so.

 

Background: The company I worked for at the time picked up a constrained and business focused OOA variant called “Objects 9000” back in ~1994 from Martin Roesch (http://www.roesch.com, sadly  German only). We adapted the business analysis part of that and had some really good results with good clarity on the business domain and the functional requirements and the analysis model also naturally yields what you here call ‘roots’ and their dependent objects.

 

I’ll admit that we, at that company, weren’t wise enough to take the shortest path to turning that into a design back then (client/server was still hot, and there were too many fantasies about stamping out software like cars in a factory and thus way too much fancy plumbing magic), but once web technologies came around and you needed to think about concurrency and scaling, triaging data into read-only, read/write etc, those basic principles of how to dissect the domain and capture the requirements have proven very useful – I keep doing it whenever I write apps that are not straight-up plumbing (like Service Bus).

 

I haven’t even read “the” DDD book and the concepts being discussed here are all immediately familiar, so there seems to be a very obvious link. So that background and the fact that me and a bunch of other folks have been talking about and have been practicing patterns such a read/write separation or chronological, insert-only data models for quite a while, first made me say “how is this new?” on DDD/ES/CQRS, but novelty isn’t the point here. I’m actually very happy that folks like Greg and everyone else here are taking all these good ideas and putting them together in a coherent way so that they get exposure to a broader audience. Bottom line: I think of CQRS/ES/DDD as a way to package best-practice and thus there’s overlap and “standing on shoulders of giants” going on, including taking the better parts of OOAD.

[Michael Brown]

Many years ago, there was this new-fangled concept of representing real world objects and concepts through a programming language. There was a great paper written by a researcher named Trygsve Reenskaug that discussed how to approach this style of programming using a paradigm that he originally called Thing Model View Editor (we now know it as the MVC pattern but within those papers are also thoughts on how to represent business concepts within the code). Over the years as we moved into the world of rapid application development and client-server applications, our code begin to lose the elegance of modeling the real world domain in our code and began to look more like operations that manipulated transient representations of data. In other words the code was less Object-Oriented and more procedural in nature. Truth be told there were a lot of objects, but they were all infrastructure related.

 

Every few years, a skilled practitioner would remind us that we had this powerful mechanism to tie behavior and data together. (Our industry has the collective memory of a goldfish). Eric Evans just so happens to be the one sounding the trumpet for today’s developer.

 

Long story short…yes Domain Driven Design IS Object-Oriented Design.

 

[Glenn Block]

Weighing in late here, but I agree with the sentiments. DDD is definitely a flavor of OOAD. They key differentiation being that it brings it's own specific set of constraints whereas OOAD itself is more more general purpose.

Clemens, Objects 9000 sounds interesting. I'd be interested to hear more on the approach. Do you have a blog post or something?

Thanks 

Glenn