Skip to content

deejayy/software-architect

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

60 Commits
 
 
 
 
 
 

Repository files navigation

So you wanna be a software architect?

This aims to be a collection of resources if you decide you want to train yourself to be a software architect.

In phase 1, it'll be just a bunch of links put into this readme.
In phase 2, it should have a structure, a good start for everyone (hopefully), but not a complete thing.
In phase 3, it'll be an ultimate guideline on the topic "How to be a software architect".

Let's go.

Oh, I almost forget: do contribute, I have a lot of things to learn (eg. proper written english :).

Phase 1

(don't worry, phase 2 won't look like this)

Podcasts

Software Architecture Podcasts (https://player.fm/podcasts/Software-Architecture)
Episode 396: Antifragile Architecture
Episode 390: Security in Software Design
Episode 389: Basecamp’s Software Development Process
Episode 374: Motivating Programmers
Episode 368: Managing Distributed Teams
Episode 355: Scaling Technology and Organization
Episode 346: Streaming Architecture
Episode 333: Software Design
Episode 317: Measuring Software Engineering Productivity
Episode 308: IT Architecture and IT Transformation
Episode 281: Career Strategy
Episode 265: Becoming a Tech Lead
Episode 250: Why Large IT Projects Fail
Episode 245: Marketing Yourself and Managing Your Career
Episode 236: Evolutionary Architecture
Episode 234: Lean Enterprise
Episode 228: Software Architecture Sketches
Episode 208: Hiring in the Software Industry
Episode 170: Large Agile Software Development
Episode 168: Being a Consultant
Episode 166: Living Architectures
Episode 153: Product Lines and Software Ecosystems
Episode 149: Difference between Software Engineering and Computer Science
Episode 147: Software Development Manager
Episode 142: Sustainable Architecture
Episode 132: Top 10 Architecture Mistakes
Episode 115: Architecture Analysis
Episode 114: Requirements Engineering
Episode 112: Roles in Software Engineering II
Episode 110: Roles in Software Engineering I
Episode 93: Lessons Learned From Architecture Reviews
Episode 90: Product Line Engineering Pt. 3
Episode 58: Product Line Engineering Pt. 2
Episode 53: Product Line Engineering Pt. 1
Episode 74: Enterprise Architecture II
Episode 34: Enterprise Architecture I
Episode 64: Architecture and Business
Episode 41: Architecture Pt. 4
Episode 30: Architecture Pt. 3
Episode 25: Architecture Pt. 2
Episode 23: Architecture Pt. 1
49. Building Effective Distributed Teams
47. Working with an Event-Driven Architecture
42. How to Prepare for Coding Interviews
41. Architecting Multi-Tenancy
39. Evolving Alongside your Tech Stack
28. Effective Leadership Development
24. Side Projects for Fun and (not necessarily) Profit
20. Becoming a Junior Developer
15. Pursuing a Career in Tech
10. How to Learn Something New
9. Coordinating Remote Work
125: Choosing the Right Product Idea
105: Strength Training for Nerds
91: Designing a Calmer Team Communication Platform
56: Getting Things Done and Building Your Own Tools
42: Marketing for Developers
31: #NoEstimates
26: What do you need when you launch?
25: Tips and tricks to make your code awesome
20: Code is not a business
17: Maximizing Your Conference Experience
9: Architecture, Patterns and Design
5: Jobs-to-be-Done and Product Design
Designing Data-Intensive Applications: Reliability, Scalability, Maintainability, Data models: Relational vs Document, Relationships, Query Languages
The Pragmatic Programmer - Investing in Your Knowledge Portfolio
What Should You Learn Next?
Tackling Tough Developer Questions
How to Learn Programming Skills
Programmer Strengths and Weaknesses
Software Design Anti-patterns
Why Domain Driven Design
How to be an Advanced Programmer
Delegate all the things!
What programmer do you want to be?
Technical Leadership, Cultivating Culture, and Career Growth
Role of the Software Architect in a Continuous Delivery Environment
Architecting to Avoid and Recover from Failure
Unlocking the "Secret Sauce" of Great Teams
Architecture and Rapid Growth

Ideas, technologies, seeds for a google search

  • everything driven development
  • Hammock Driven Development
  • caching techniques, tools and cache invalidation
  • chaos engineering
  • antifragile architecture
  • distributed (systems | databases | coordination)
  • documenting architecture
  • fault tolerance and error handling
  • legacy (code | systems)
  • modularization
  • mooc
  • multi-tier applications
  • performance and tuning
  • pipes & filter
  • rfc
  • semantic versioning
  • software architecture in sync with organization structure
  • software architecture patterns
  • technical debt
  • timezones
  • UML
  • C4 model (Simon Brown)

Human factor

  • 360 degree feedback
  • support network of architects
  • plan your own time as well

Process

  • agile
  • disaster recovery plan
  • estimation
  • handling defects
  • incident response
  • incremental release
  • itil
  • product iteration (PI) planning
  • release management
  • SLA
  • workflow management

Quality Assurance

  • automatic testing

Security

  • authentication, SSO, OAuth, 2FA
  • checkmarx, osa, sast
  • devsecops
  • encryption
  • OWASP
  • security

DevOps

  • apache mesosphere
  • backup strategies
  • CI/CD
  • devops
  • docker
  • edge computing
  • geodns
  • kubernetes
  • load balancing
  • logging
  • networking
  • service discovery
  • SRE
  • static code analysis, sonarqube
  • storage technologies
  • virtualization

Cloud technologies

  • * aaS
  • aws, azure, google cloud
  • openstack
  • serverless

AI

  • chatbots
  • computer vision
  • machine learning
  • neural networks
  • tensorflow

Misc

  • blockchain

Databases

  • ACID
  • cloud databases
  • data science
  • data visualization
  • database replication
  • graph databases
  • graphql
  • hadoop
  • nosql
  • sql
  • transactions
  • data masking
  • bigquery

General software development

  • CBD https://en.wikipedia.org/wiki/Component-based_software_engineering
  • algorithmic complexity
  • antipatterns in software development
  • application state management
  • bugs and debugging
  • clean code and refactoring
  • code retreat
  • code review
  • coding guidelines (styling, linting)
  • Compiled vs interpreted languages
  • data structures: arrays, trees, heaps, tries, hashtable, dictionary, primitives
  • design patterns
  • event sourcing
  • extreme programming
  • formal languages
  • functional programming
  • git
  • git workflows
  • hackerrank
  • IDE
  • Imperative vs Declarative Programming
  • llvm
  • mobile apps
  • MVC, MVVM
  • naming things
  • nocode
  • low-code
  • npm
  • online payment solutions
  • oop, aop
  • ORM
  • pair programming
  • quantum computing
  • regular expressions
  • software disenchantment
  • software quality
  • statically vs dynamically typed languages
  • streams
  • websockets

Backend developmemnt

  • API design (public, private)
  • autoscaling backend services
  • backend frameworks
  • CRUD
  • embedded systems
  • internet of things
  • message queues
  • microservices
  • monoliths
  • REST
  • service mesh
  • soa

Frontend developmemnt

  • a/b testing
  • accessibility
  • bootstrap
  • cdn
  • CMS
  • CSS frameworks
  • electron, node-webkit, webview
  • frontend frameworks (and how to build them from scratch)
  • HTTP 1, 2, 3, QUIC
  • PWA
  • semantic web
  • SPA
  • UI design systems
  • user experience
  • voice UI
  • web components
  • webassembly
  • webgl
  • webrtc

Books

Chess and the Art of Enterprise Architecture
Test-Driven Development by Example, Kent Beck
Building Evolutionary Architectures, Neal Ford (local snapshot)
Techniques for Crafting Better Presentations, Neal Ford (local snapshot)
The ThoughtWorks Anthology, Volume 2, Neal Ford
97 Things Every Programmer Should Know, Neal Ford
97 Things Every Software Architect Should Know, Neal Ford
The Productive Programmer, Neal Ford (local snapshot)
Fooled by randomness

Conferences

O’Reilly Software Architecture Conference 🡕
#devdotnext2020 #LeadDevLondon

People

Patrick Kua, tech lead 🡕 Neal Ford 🡕

Blogs

LevelUp Newsletter, Patrick Kua 🡕

Links

https://apiumhub.com/tech-blog-barcelona/user-interface-testing/
https://apiumhub.com/tech-blog-barcelona/microservices-vs-monolithic-architecture/
https://apiumhub.com/tech-blog-barcelona/almost-infinite-scalability/
https://apiumhub.com/tech-blog-barcelona/importance-good-software-architecture/
https://apiumhub.com/tech-blog-barcelona/importance-of-soft-skills/
https://apiumhub.com/tech-blog-barcelona/software-architecture-books/
https://apiumhub.com/tech-blog-barcelona/benefits-of-software-architecture/
https://www.leanix.net/en/enterprise-architecture
https://www.infoworld.com/article/2988671/architecture-principles-considered-harmful.html
https://ea.rna.nl/2015/03/08/losing-a-limpet-what-happens-when-we-dont-have-enterprise-architecture/
https://ea.rna.nl/2017/01/13/agile-architecture/
https://blog.codinghorror.com/so-you-dont-want-to-be-a-programmer-after-all/
https://blog.ndepend.com/mentoring-software-developers/
https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/
https://blog.ndepend.com/code-reuse-not-good-goal/
https://blog.ndepend.com/secrets-maintainable-code-codebases/
https://blog.ndepend.com/code-quality-metrics-signal-noise/
https://www.ndepend.com/docs/code-metrics
https://blog.ndepend.com/5-tips-help-visualize-code/
https://blog.ndepend.com/with-code-metrics-trends-are-king/
https://en.wikipedia.org/wiki/List_of_software_development_philosophies
https://en.wikipedia.org/wiki/Software_development
https://medium.com/globalluxsoft/5-popular-software-development-models-with-their-pros-and-cons-12a486b569dc
https://www.mendix.com/blog/introducing-the-low-code-manifesto/
https://hackernoon.com/what-is-serverless-architecture-what-are-its-pros-and-cons-cc4b804022e9
https://getstream.io/blog/styled-components-vs-css-stylesheets/
https://blog.pragmaticengineer.com/software-architecture-is-overrated/
https://www.progression.fyi/
https://dzone.com/articles/10-years-of-important-technical-decisions-itds
https://blog.cleancoder.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html
https://uxstudioteam.com/ux-blog/ux-team-structure/
https://pythonspeed.com/articles/dont-need-kubernetes/
http://strlen.com/treesheets/
https://futureofcoding.org/notes/paval-bazant-5-21-19.html
https://melsatar.blog/2017/04/29/architectural-design-decisions/
https://github.com/elsewhencode/project-guidelines
https://github.com/ryanmcdermott/clean-code-javascript
https://leadership-library.dev/The-Leadership-Library-for-Engineers-c3a6bf9482a74fffa5b8c0e85ea5014a
https://atomicdesign.bradfrost.com/chapter-5/
https://adr.github.io/
https://github.com/donnemartin/system-design-primer
https://github.com/kamranahmedse/developer-roadmap
https://github.com/futurice/backend-best-practices
https://8thlight.com/blog/stephen-prater/2020/09/15/values-rules-break.html
https://12factor.net/
What is extreme programming 🡕
https://doriantaylor.com/the-specificity-gradient

One-liners: The architect ...

  • makes decisions on things which are expensive to change later
  • plans everything what the client not asked specifically but necessary for the product (non-functional requirements)
  • is not always there but an architecture is
  • shouldn't be always the best developer (who is tend to keep the hard problems for themself)
  • should code in a daily basis

Phase 2

Architecture

Different architect roles

Software architect (Wikipedia) 🡕

A software architect is a software developer expert who makes high-level design choices and tries to enforce technical standards, including software coding standards, tools, and platforms.

Architects make high-level design choices based on their programming experience. An architect has thought through all the aspects of a software, just like an architect that builds a house. A construction architect knows where the ducts will be, where the electric connections will be and where the wall outlets will be. A design that a common person sees is just the walls and windows but a detailed design that is abstracted from the outsider are also present with the architect. In addition, the architect may sometimes propose technical standards, including coding standards, tools, or platforms.

Software architects may also be engaged in the design of the architecture of the hardware environment, or may focus entirely on the design methodology of the code.

Architects can use various software architectural models that specialize in communicating architecture.

Architect type Strategic thinking System interactions Communication Design
enterprise architect across projects highly abstracted across organization minimal, high level
solutions architect focused on solution very detailed multiple teams detailed
application architect component re-use, maintainability centered on single application single project very detailed

Solution architecture (Wikipedia) 🡕

Solution architecture is a practice of defining and describing an architecture of a system delivered in context of a specific solution and as such it may encompass description of an entire system or only its specific parts. Definition of a solution architecture is typically led by a solution architect.

According to Forrester Research, solution architecture is one of the key methods by which enterprise architecture delivers value to the organization. Solution architecture activities take place during solution ideation, solution design, and solution implementation. During ideation, solution architecture establishes the complete business context for the solution and defines the vision and requirements for the solution. During design, solution architecture elaborates potential options, which may include RFIs, RFPs or prototype development. It selects the optimal option and develops the roadmap for the selected solution. During implementation, solution architecture communicates the architecture to the stakeholders, and guides the implementation team.

Application architect (Wikipedia) 🡕

The Application architect is a lead or technical manager in the computer programming team who is specialized in the application built and the technologies used.

An applications architecture describes the behavior of applications used in a business, focused on how they interact with each other and with users. It is focused on the data consumed and produced by applications rather than their internal structure. In application portfolio management, applications are mapped to business functions and processes as well as costs, functional quality and technical quality in order to assess the value provided.

Enterprise architecture (Wikipedia) 🡕

Enterprise architecture (EA) is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes."

Practitioners of enterprise architecture, enterprise architects, are responsible for performing the analysis of business structure and processes and are often called upon to draw conclusions from the information collected to address the goals of enterprise architecture: effectiveness, efficiency, agility, and continuity of complex business operations.

Further reading

Technical Architect vs Solution Architect vs Enterprise Architect: What’s the Difference?
The role of a software architect
Enterprise Architect vs. Solution Architect
Enterprise Architects vs Solution Architects vs Domain Architects
Bridging the Gap Between Enterprise Architecture and Solution Architecture for Maximum Benefit
Technical vs. solution vs. enterprise architecture: a matter of scale
Following the Software Architecture Career Path
Architect Role Definitions 🡕 (local snapshot)
Aligning Enterprise, System, and Software Architectures 🡕 (local snapshot)

Everything driven development

Test-driven development (TDD)

Test-driven development (Wikipedia) 🡕 (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the code is improved so that the tests pass. This is opposed to software development that allows code to be added that is not proven to meet requirements.

  • encourages simple designs and inspires confidence
  • is related to the test-first programming concepts of extreme programming
  • helps improving and debugging legacy code developed with older techniques

Benefits
  • programmers who wrote more tests tended to be more productive
  • programmers rarely felt the need to invoke a debugger
  • programmer is concerned with the interface before the implementation
  • allows a programmer to focus on the task
  • ensures in this way that all written code is covered by at least one test
  • gives the programming team a greater level of confidence in the code
  • more code is required with TDD than without TDD
  • can lead to more modularized, flexible, and extensible code
  • they detect any unexpected changes in the code's behaviour
Limitations
  • extensive use of unit tests required for testing: user interfaces, software that works with databases,
  • management support is essential
  • tests may share blind spots or the developer misinterprets the requirements: tests will give a false sense of correctness
  • false sense of security
  • tests become part of the maintenance overhead of a project
  • maintaining an excessive number of tests costs time
  • tests made with TDD cannot easily be re-created at a later date
Key elements of TDD

Dummy, Stub, Spy, Mock, Simulator

Further reading

Introduction to Test Driven Development
Test Driven Development (Scaled Agile)
Test Driven Development Tools and Agile Process
TDD × ROI: Is Test-Driven Development worth the money?
Test Driven Development: what it is, and what it is not
Test-driven development (IBM)

Design-driven development (DDD)

Design Driven Development 🡕 uses design as part of a process to learn and better define requirements in order to build better, more informed technology solutions. It can also be looked at as a process whereby design and user experience drives the development of a product or software application. This leads to products that people enjoy using and want to tell others about.

Using design to learn means allows the business to gain insights to better inform product design and technology decisions before investing heavily in the software development. The design can be in the form a sketch, to a low or high-fidelity mockup, to a clickable prototype or even a quick and dirty coded prototype. Anything you can put in front of a customer to get feedback and better inform what you’re building before you build it.

Without design driven development, it’s easy to build many bad experiences into a product and more importantly, miss the mark with solutions completely. In the absence of design driven development, teams are focused more on building and shipping — often blindly. If product managers and teams are not thinking deeply and analysing what they intend to build and why, they’re coding without a cause.

Further reading

Design Driven Development (Thoughtbot)
Design-driven development (UXMA)
Design Driven Development (Mäd)
Design Driven Development (Slideshare) 🡕
How to Foster Design-Driven Development in Your Company 🡕, (local snapshot)

Feature-driven development (FDD)

Feature-driven development 🡕 (FDD) is an iterative and incremental software development process. It is a lightweight or Agile method for developing software. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner in accordance with the Principles behind the Agile Manifesto.

FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined. This section gives a high level overview of the activities. In the figure on the right, the meta-process model for these activities is displayed. During the first two sequential activities, an overall model shape is established. The final three activities are iterated for each feature.

Any project can use this method. In other words, that project splits into multiple features; each feature is divided further until it is as small as it can be worked out. Additionally, this is done to ensure that its delivery can happen in 2-10 days.

It is usually applicable to Large-scale projects.

Roles and responsibilities
  • Project Manager
  • Software Architect
  • Development Manager
  • Dev Lead
  • Class Owners
  • Domain Experts
  • Other Supporting Roles
Practices
  1. Domain Object Modeling
  2. Development by Feature
  3. Individual class ownership
  4. Feature Team
  5. Code/Design reviews
  6. Configuration Management
  7. Regular Deploy
  8. Visibility
Processes
  1. Develop an overall model
  2. Build a feature list
  3. Plan By Feature
  4. Design by feature
  5. Build by feature
Further reading

Feature Driven Development (FDD): An Agile Methodology
Feature Driven Development (FDD)
An Introduction to Feature-Driven Development
Feature Driven Development: A Guide
Feature Driven Development
FDD: It's processes & comparison to other agile methodologies
9 Things You Must Know About FDD - Feature Driven Development
Feature-Driven Development: An Agile Alternative to Extreme Programming
Feature-Driven Development: Best Practices
A Practical example of Feature Driven Development
What is Feature Driven Development?
Not Everything Needs to Be a User Story: Using FDD Features
Major Seminar On Feature Driven Development (PDF) 🡕, (snapshot)
Feature Driven Development 🡕

Model-driven development (MDD)

Model-driven engineering 🡕 (MDE) is a software development methodology that focuses on creating and exploiting domain models, which are conceptual models of all the topics related to a specific problem. Hence, it highlights and aims at abstract representations of the knowledge and activities that govern a particular application domain, rather than the computing (i.e. algorithmic) concepts. MDD is a key element of the low-code approach.

Instead of writing code you can create models. These models are transformed into source code. You, of course, have to learn how to model, but once you have, all the manual work of writing code is automated.

In Model-Driven Development the model of a software application is specified on a higher abstraction level than traditional programming languages. This model is automatically transformed into a working software application by generating code or interpreting / executing the model. While the used model is on a higher abstraction level it is much smaller compared to the same model expressed in code.

Model-driven development (MDD) leverages graphical models and pre-built application components so that users can visually construct complex applications. Interest in model-driven development continues to increase as individuals experience the ease and speed with which technical and business users orchestrate and deploy business applications. The right model-driven development platform provides significant productivity advantages over traditional development methods and enables project delivery by smaller teams.

There are two core concepts associated with model-driven development: abstraction and automation. The software application model is defined on a higher abstraction level and then converted into a working application using automated transformation or interpretations. The right model-driven development approach leverages model execution at run time, where the model is automatically transformed into a working software application by interpreting and executing the model (removing the need to generate or write code).

MDD Tools
  • Mendix
  • Microsoft Power Apps
  • Appian
  • Pega platform
  • Quick Base
  • Kony Development Cloud
  • OutSystems
  • Nintex Platform
  • KiSSFLOW
  • Dezyne
Further reading

15 reasons why you should start using Model Driven Development
8 reasons why Model-Driven Development is dangerous
Model Driven Development Misperceptions and Challenges
10 Misperceptions and challenges of Model Driven Development
8 Reasons Why Model-Driven Approaches (will) Fail
5 types of Model Driven Software Development
Model Driven Development Vs Test Driven Development Computer Science Essay
ModelDrivenSoftwareDevelopment
Agile Model Driven Development (AMDD): The Key to Scaling Agile Software Development
Low-Code Principle #1: Model-Driven Development, The Most Important Concept in Low-Code
Model-Driven-Development (part 1) — RAD, BPMS and Low-Code Development Platforms
Model-Driven-Development (part 2) — Pitfalls and Recommendations
The Pragmatics of Model-Driven Development 🡕, (snapshot)
MDA @ Object Management Group 🡕

Acceptance test driven development (ATDD)

Acceptance test driven development 🡕 (ATDD) is a development methodology based on communication between the business customers, the developers, and the testers. All these processes aid developers and testers in understanding the customer's needs prior to implementation and allow customers to be able to converse in their own domain language.

Acceptance tests are from the user's point of view - the external view of the system.

Analogous to test-driven development, Acceptance Test Driven Development (ATDD) involves team members with different perspectives (customer, development, testing) collaborating to write acceptance tests in advance of implementing the corresponding functionality. The collaborative discussions that occur to generate the acceptance test is often referred to as the three amigos, representing the three perspectives of customer (what problem are we trying to solve?), development (how might we solve this problem?), and testing (what about…).

These acceptance tests represent the user’s point of view and act as a form of requirements to describe how the system will function, as well as serve as a way of verifying that the system functions as intended. In some cases the team automates the acceptance tests.

Acceptance tests are a part of an overall testing strategy. They are the customer tests that demonstrate the business intent of a system. Component tests are technical acceptance tests developed by an architect that specify the behavior of large modules.

Test format

Given (setup) - When (trigger) - Then (verification)

Given Book that has not been checked out
And User who is registered on the system
When User checks out a book
Then Book is marked as checked out
Further reading

Acceptance Test Driven Development (ATDD) 🡕
Driving Development with Tests: ATDD and TDD 🡕, (snapshot)
ATDD From the Trenches 🡕
7 Things About Acceptance Test Driven Development Everyone Should Know 🡕
ATDD Lets Team Frequently Release Software
Acceptance test-driven development 🡕
Acceptance Test Driven Development 🡕
ATDD - Acceptance Test Driven Development 🡕
Acceptance test driven development for web applications 🡕

Behaviour-driven development (BDD)

Specification by Example

Behavior-driven development 🡕 (BDD) is an Agile software development process that encourages collaboration among developers, QA and non-technical or business participants in a software project. It encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave. It emerged from test-driven development (TDD). Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.

The goal of BDD is a business readable and domain-specific language that allows you to describe a system’s behavior without explaining how that behavior is implemented.

BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural-language constructs (e.g., English-like sentences) that can express the behaviour and the expected outcomes.

BDD focuses on:

  • Where to start in the process
  • What to test and what not to test
  • How much to test in one go
  • What to call the tests
  • How to understand why a test fails

At its heart, BDD is about rethinking the approach to unit testing and acceptance testing in order to avoid issues that naturally arise.

Title

An explicit title.

Narrative

A short introductory section with the following structure:
As a: the person or role who will benefit from the feature;
I want: the feature;
so that: the benefit or value of the feature.

Acceptance criteria

A description of each specific scenario of the narrative with the following structure:
Given: the initial context at the beginning of the scenario, in one or more clauses;
when: the event that triggers the scenario;
then: the expected outcome, in one or more clauses.

Further reading

Behavior Driven Development 🡕
Your Boss Won't Appreciate TDD: Try This Behavior-Driven Development Example 🡕
Get Started With Behavior Driven Development 🡕
A few benefits you get by doing BDD 🡕
Behavior-Driven Development 🡕
The beginner's guide to BDD (behaviour-driven development) 🡕
Behavior-Driven Development: What is it and how do you use it? 🡕
Behavior Driven Development 🡕
Behaviour driven development: an introduction to BDD model 🡕
Behavior-driven Development 🡕

Domain driven design (DDD)

Example driven development (EDD)

Plan-driven models

About

So you wanna be a software architect?

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published