When it comes to thinking about the structural characteristics of a software system, a common tendency is to separate architecture from design. Architecture is considered concerned with the significant part of a software system while design concerned with the rest of the structural elements. E.g., some consider the perception of the layers as being architecture while the objects structure that would go inside every layer as being just design.

This is a simple mistake. A rigid line between architecture and design can never be drawn as a general valid theory as long as significant is a subjective concept. As a result, drawing the line between significant and non-significant structural elements is up to every team. A team that is applying Domain Driven Design as a full philosophy for driving a new project would definitely consider the design in the Domain layer (down to an object view as a reflection of the agreed domain model) as being significant.

Even if the developers in a team draw their own line between significant and non-significant structural elements, the terms “architecture” and “design” are still not very appropriate for reflecting the nature of these two categories of structural elements. They would better call these two categories “High Level Design” and “Low Level Design” even if these are still very dry words. Architecture is design.

Probably the most dangerous aspect of forcing this separation of architecture and design is the effect that it might have on the development roles. Because of this mental separation, some get to consider that architects should be concerned with the architecture and developers with the design and implementation.

It is an already known fact that this approach has miserably failed. Architects should be concerned with both significant and non-significant design in a system and they should also be concerned with the implementation of it. They should be the expert developers. Even if not always able to write code with the same frequency as the regular developers do, they should constantly be in touch with the code that is being written and the technology platform that this is based on. Losing the hands-on practice has most of the times led to incompetency for the smart people that have been pushed into the high clouds.