Skip to content

Summary

Summary · Chapter 3

  • Being an effective architect means understanding the domain of the software you build. General business knowledge plus a deep grasp of the organization’s business is the foundation for mastering the problem space (see Developing business acumen).
  • DDD is a proven approach to modeling a domain. A ubiquitous language and working with domain experts simplify and facilitate communication among everyone on the project (see Domain-driven design).
  • Strategic practices — splitting the domain into subdomains and defining bounded contexts in the domain model — minimize complexity and let the team grasp even complex domains.
  • Proper requirements engineering, including effective elicitation from stakeholders, is key to building software successfully; knowing the requirements is crucial to designing an appropriate solution (see Requirements engineering, Requirements elicitation).

The next chapter explores one of the most important requirement types: quality attributes. Building quality software requires understanding the quality attributes that matter to stakeholders (see Quality attributes).

  • Software Architect’s Handbook (Packt, 2018), Ch.3 “Summary”, p. 176.