- Consider your “distribution boundaries”. Are you gluing separate components together? Be aware of performance tradeoffs for monolithic vs distributed systems. source.
- “Every remote call travels on the cyber equivalent of a horse and carriage.”
- How fine/coarse-grained are your interfaces? The more distributed, the coarser your interfaces should be
- “All sorts of places in the system will change shape to minimize remote calls.”
- Introduce public vs private methods.
- Conflict between REST structural model and the need for “coarse-grained” interfaces at remote boundaries.
- The “remote facade” pattern (same source) is a way to work around this: Certain objects that explicitly (unavoidably, to anyone using them)
Don't confuse software architecture with "where to start." Architecture has a specific and valuable role to play.
To ensure software works to meet requirements and to avoid duplication of work, there needs to be a master plan for the system. The entirety of the big picture needs to be coherent. That requires a single brain to consider everything in totality, making decisions and documenting approach so that the entire system does work together coherently.
When you have well-defined software architecture, you essentially have a todo list for implementation: A series of components with well-defined jobs to do and requirements, such as how they are to interface with others. Any competent member of the team should be able to pick up one of these tasks and complete it by writing software that actually builds the component. In this way, you can divvy up the work amongst various developers, each working more-or-less in isolation. As long as individual contributions meet the architectural specifications for the components assigned tothem (it's important to subject everything to QA to ensure this), then all of the assembled pieces can and should work together.
Consider these two mutually-exclusive kinds of decisions:
- "Architectural decisions" concern how components fit within the system as a whole, which other parts of the application they interact with, and how.
- "Implementation decisions" concern how a component is to be built.
If the decision only affects one component and has to do with how it does its job, it is probably an implementation decision. If the decision affects multiple components, or pertains to a what a component's job is, it is probably an architectural decision.
Identify all of the architectural decisions, and then make them all. Don't dive into the details; work from the top (highest level of abstraction) down.
There’s danger here in easily slipping into making implementation decisions. Here are a few things to help avoid that:
- Avoid writing code with logic in it. (Code that describes data structures is important during architecture; note how this shouldn't include any logic.)
- Write pseudo code and/or English code comments
- Keep asking yourself, "What are the decisions to make here? Have I made all architectural decisions?" Back out and move on when you find yourself having made all of the architectural decisions.
- If you're focusing on something very detailed, periodically remind yourself to be mindful of whether you've slipped into making implementation decisions.
Document every decision and (ideally) everything you consider (including rejected approaches, and the reasons why you made a decision.)
"The best laid plans of mice and men often go astray"… As soon as implementation begins, you'll start to see oversights and flaws in your architecture reasoning. That's fine; this is normal. Keep your architecture understanding up to date to evolve with your understanding.
All of the following needs consideration and documentation.
- Identify each of the system's layers
- For each layer, identify its highest level pieces that work together
- Some layers may only have 1 piece
- Describe how they work together
- If you find it's hard to keep all of the pieces of a system in your head at the same time, zoom out a level and describe things more generally, until it's possible to keep the whole picture in your head.
- Describe your data model
- Define discrete Content/Data Types
- Define Content Attributes of each content type
- (e.g. "A person has a "first name, a last name, a photo, and a bio")
- Decide on a DB schema:
- Document or a key/value store DB engine, versus relational DB engine
- Translate Content Attributes into fields/attributes associated with a record/item
- Define what application layer needs from the data layer and/or how it will access the data layer
- (e.g. maybe it makes sense to have classes to handle data CRUD operations for each content type)
- Create an object schema for each Content Type's representation in code
- Identify the interfaces between high-level logical components
- For each high-level component:
- Identify services required to implement application features
- Identify all UI components required
- For each component, break it down into sub-components and document logic required for each one
- Repeat from step 4 for each sub-component, until all of the remaining decisions are implementation decisions.