A curious aspect of IT Architecture is that there is no single definition of Architecture. This causes real problems on projects. The reason is that Architecture and Design, are the pre-requisites for good IT systems. In Waterfall we have the ‘Big UpFront Design’ or BUFD, which is inefficient, unrealistic and untethered to technical reality. For example, how will I know what my real design is based on implementation details in 6 months? Agile, proposes an iterative design creation, with minimum and sometimes no real design made up front. This is likewise problematic. If I don’t create a reasonable target model design how will my engineers know what to build? Code itself is a design and the code design needs to be a bi-directional relationship with the higher order models, entities, relationships and architecture.
(Togaf Image)
What is Architecture?
There are many smart people who are attempting to alleviate these issues including: Matt Stine, Simon Brown, Robert Martin, Grady Booch, and Martin Fowler. In essence, there is a need within the IT industry to have a standardised, open-source based approach to what is Architecture. For example, is a good Architecture independent or dependent on the problem domain, and independent or dependent on desired user experiences? If you ask 10 IT Architects, this question you might receive 11 answers.
Simon Brown in his book Software Architecture for Developers restates some of Grady Booch’s writings on architecture, including the following:
“Architecture represents the significant design decisions that shape a system, where significance is measured by cost of change.” And, “The architectural decisions are those that you can’t reverse without some degree of effort.”
The above is clear. This means that code programmers are making architecture decisions! On every project an engineer will make a decision – sometimes by him or herself – to build code in a certain language, in a certain way, in order to solution the problem at hand. By choosing certain techniques and by coding in a certain way, the developer has made an architectural decision since the system is now ‘hard to reverse’ without costly changes. An example could be a general implementation of hard code values, which if wrong or needing to be updated, are time consuming to replace and edit; or choosing SQL when a Java framework was more suited and flexible.
Architecture in Specifics
However, to build a proper system, Architecture must be more than just something that is costly to change, or hard to reverse.
A good Architecture will reflect the domain business logic, its work-flow and is dependent on satisfying the desired end-user experience.
Architecture is the important high level shape and flow of the system, solution and associated software, which can be, but usually is not independent of the problem domain, but dependent on achieving the desired user experience.
Domain dependent Architectures are a necessity. See here. A key problem with Agile is that there is no formal design phase. Without a formal design and Architecture, it is impossible to properly use Agile teams and resources. They won’t know what they are building. Yes, iteration is key, but you must have a beginning and a purpose. Otherwise in reality the team flounders. Domain Driven Agile design gives you the following Architectural artefacts:
Ubiquitous Language
A ubiquitous language of DDD is mandatory in order to know more about the terms that the business uses. It helps with the translation into geek-IT speak. Each Agile team will become fluent in the business language specific to that domain allowing easier translation into system code and services. This will include the context setting and mapping of the contexts which lead to independent implementations, and defined interfaces.
Bounded Contexts
Bounded context is the context in which the ubiquitous language and the corresponding models are valid. It gives the Agile team a clear understanding of what has to be consistent and what can be developed independently.
Model
This is the high-level design Architecture which is refined over iterations and MVPs (Minimum Viable Products or Proof of Concepts). This Architectural model is based on a ubiquitous language and presents a system which describes the selected aspects of a domain, its logic, its workflows and how the Architecture resolves the problems that are related to that particular domain. A good architecture will give you an Enterprise view of the domain model, integrating business processes with IT.
What Are the Characteristics of a Strong Domain Model?
- Being Aligned with the business’ model, strategies, and processes.
- Being isolated from other domains and layers in the business.
- Be loosely designed with no dependencies on the layers of the application on either side of the domain layer.
- Being reusable to avoid models that are duplicated.
- Be an abstract and cleanly separated layer to create easier maintenance, testing, and versioning.
- Minimum dependencies on infrastructure frameworks to avoid outliving those frameworks and tight coupling on external frameworks.
- Designed with a “Plain Old Java Object” programming model without having any technology or framework dependencies.
The above also summarises what a Domain Driven Architecture is important and vital to have in some higher-level form, before the Agile teams get busy. It will shape the underlying technical detail and coding.