DDD/CQRS Vs Clean Architecture

[Mohammed AMHEND]

  
   Uncle Bob,

 What are the main differences and similarities between the clean architecture approach that you presented in the 7th episode and a DDD/CQRS architecture.

  Cheers

[Uncle Bob]

There are several architectures that have similar characteristics.  

• The Hexagonal architecture by Steve Freeman and Nat Pryce. 
• The DDD architecture, by Eric Evans
  
• The DCI architecture by James Coplien and Trygve Reenskaug
• The Clean Architecture by me, based on Ivar Jacobson's BCE architecture.
  

The descriptions of these architectures differ significantly; but the end results are all very similar.  Overall these architectures attempt to separate a software system into independently deployable levels.  

The separations emphasized by DDD/CQRS are:

• Domain Model
• Commands
• Queries.
  

DCI separates:

• Models (Domain objects)
  
• Interactions (Use cases)
• Contexts

Hexagonal separates layers:

• UI
• Mid-tier
• Domain

Clean separates:

• UI
• Database
• Use Cases
• Domain

Each of these architectures emphasize different technical mechanisms to achieve their separations.  

• DCI uses inheritance and traits
• Clean uses Dependency Inversion (polymorphism and interfaces)
• Hexagonal also uses Depencency Inversion, but with an emphasis on mocks.
• DDD/CQRS is less technically specific, though an example can be found in the TimeAndMoney example by Evans.
  

Though these approaches may sound very different, the end results have a deep similarity.  All of them lead to systems that separate:

• application specific functions
• application independent functions
• input/output mechanisms
  
• storage mechanisms
• external interfaces
• frameworks.

Such that each separation can be placed in an independently deployable component (Jar, Dll, Gem, etc.) and maintained as a separate independent module.

Or to say this more succinctly, each evolves into a plugin model.

[Mohammed AMHEND]

Thank You !!

I hope you'll decide someday to write a Clean Architecture book, that gathers all this stuff and gives much more detail about your Clean Architecture

[Uncle Bob]

I am working on that book right now.

[Andreas Schaefer]

how could one implement the cqrs aspect of seperating reads/queries from writes/commands/systemStateMutations in a clean way (given the increase of business value justifies this approach)?

e.g. according to greg young you could simplify your read scenarios by having a "thin remote facade" (web server or web api I assume) that accesses data storage more or less directly, bypassing whole parts of the domain model (boundaries, entities, interactors, maybe even repository implementations!?), which essentially makes the domain model only being used in write contexts .. and potentially splitting apart n more scalable, dedicated read context databases that could store data in a read-optimized 1st normal form (opposed to the 3rd normal form of the write context database) .. assuming we're having relational databases (but surely this can be optimized for other db formats as well).
greg states that as we're practically dealing with relaxed consistency in read scenarios anyway, we can as well go this step further and having seperate read databases that get updated and normalized by event handlers when write events occur.

could this still be seen as clean?
I assume we'd need more corase grained tests for the read contexts, but I'd be fine with that.

what do you all think? UncleBob, I'd love to hear your thoughts on this as well.

regards
Andreas

[Bennie Copeland]

I got an inkling of how this works in Implementing Domain Driven Design in the chapter on Architecture.

Your command model is designed to adhere to the actual domain being modeled. These entities will fire off events when changes are made to them. These changes are picked up a subscriber, that then duplicates the changes in a query model that could have a drastically different design than the command model. This could also be stored in a separate database geared towards data warehousing using star schemas and is tuned for reading large amounts of data; whereas the command model is stored in an database structure geared for rapid inserts and consistency.

As far as this architecture being clean, I don't see why it couldn't be. You have command interactors for making changes to the command model and stores them in the command repository, and then have query interactors that can query the query repository interface. It could still remain decoupled using boundry interfaces. The key part is having the domain entities publishing events.

[Sara ezati]

Dear Uncle,

Hope you are doing well,

I have some doubt yet,

BCE architect is a presentation tier Arch like MVC? And we we talk about DCI or DDD we talk about whole software Arch?

Best,

Sara.