Depending on your viewpoint, Simon is either a software architect who codes or a software developer who understands architecture. When he's not developing software with .NET or Java, Simon can usually be found consulting, coaching or training. Simon has also written books about Java, presented at industry events and has put together a training course called Software architecture for developers, which is based upon his software architecture writing at Coding the Architecture. Twitter: @simonbrown
E-mail: simon.brown at codingthearchitecture.com
Screaming Architecture
Architectures are not (or should not) be about frameworks. Architectures should not be supplied by frameworks. Frameworks are tools to be used, not architectures to be conformed to. If your architecture is based on frameworks, then it cannot be based on your use cases.
I don't really like Uncle Bob's idea. His thought about architecture above is not wrong, but not right, at least, only partially right.
When thinking about how to build the software, I would usually think from two different angles:
- Use cases based, or feature driven
- Libraries based, or framework driven
Both these two angles make sense for me, and I don't think I should abandon either of them. In fact, usually, I would begin with the Use Cases angle, and end with the framework thought.
Software development has a lot of characteristics as an industry. I would name two of them here:
- Software, including its source code and libraries, could be replicated in some way.
- The industry is far from mature.
These two industry characteristics make Software Development very different from Civil Engineering. In Civil Engineering, only top architectures would think about their frameworks, while in software development, most of software need to choose their frameworks. Even worse, these frameworks are dynamic, they change themselves all the time. And so as libraries, or even development platforms.
An Annoying Detail
I talked about how there are a number of "classic" software design techniques from the pre-agile era that are being used less and less. For example, things like UML, class-responsibility-collaboration cards and component-based design. This is a shame because some of these techniques can complement an agile way of working and would perhaps prevent some wheels from being reinvented. If people don't know about these techniques though, how will they adopt them?
It's quite interesting. UML, and CRC Cards are my favorites. And I actually share the same idea with Mr. Brown. Hey, I am going to be bias from here now.
That's right, the annoying detail is actually a large chunk of the system and, for me, architecture is about more than just what's contained within "the application". Structure is very important, but what about that tricky stuff like non-functional requirements, the actual delivery mechanism (technologies, frameworks, tools, APIs, etc), infrastructure services (e.g. logging, exception handling, configuration, etc), integration services (internal and external), satisfying any environmental constraints (e.g. operations and support), etc. For me, this is what "architecture" is all about and *that's* "the whole enchilada".
No comments:
Post a Comment