Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture to Manage Complexity and Enable Change

Keeping Architectures Relevant: Using Domain-Driven Design and

Emergent Architecture to Manage Complexity and Enable Change

Brandon Satrom
Thought Ascent, Inc.

Paul Rayner
Virtual Genius, LLC.

March 2010

URL : http://msdn.microsoft.com/en-us/architecture/ff476937.aspx

What have I remembered from the article?
  - try to use as much domain language/ubiqituous language that is shared between developers, architects and business experts
- do not overspecify your architecture. Developers still need the necessary freedom, and don't want to be cuddled. 
- architects should spend a part of their time as active developer. !! The code is the design!!
- architect should try to clearly define what a capability provides, not how it's implemented
- architect should design with evolution in mind. This implies ordering and isolating cohesive areas of the system from each other
??? is layerer architecture the solotion here?? - NO  -> violates the Dependency Inversion Principle (1) -> results in accidental coupling
Better Onion-architecture : isolating layers through interfaces

- isolate domain model as much as possible from concerns that are not relevant to the business domain (logging, security, persistence, ..)

- architect the lines not the boxes : define clean interfaces using a rich domain model



(1) A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend on details. Details should depend on abstractions.