AWS prescriptive-guidance documentation change
Summary
Updated breadcrumb navigation link and fixed apostrophe formatting throughout the document
Security assessment
The changes consist of a broken link fix (welcome.html to introduction.html) and typographical corrections (replacing curly apostrophes with straight ones). No security vulnerabilities, security features, or security-related content were added or modified. The mention of 'security' in Conway's Law context refers to organizational concerns, not technical security controls.
Diff
diff --git a/prescriptive-guidance/latest/hexagonal-architectures/adapt-to-change.md b/prescriptive-guidance/latest/hexagonal-architectures/adapt-to-change.md index 0585ed3c6..b7e2abdc6 100644 --- a//prescriptive-guidance/latest/hexagonal-architectures/adapt-to-change.md +++ b//prescriptive-guidance/latest/hexagonal-architectures/adapt-to-change.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Building hexagonal architectures on AWS](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Building hexagonal architectures on AWS](introduction.html) @@ -21 +21 @@ As the core of the application, the domain model defines the actions that are re -In classical layered architecture, the domain depends on the persistence layer. If you want to change the domain, you would also have to change the persistence layer. In comparison, in hexagonal architecture, the domain doesn’t depend on other modules in the software. The domain is the core of the application, and all other modules (ports and adapters) depend on the domain model. The domain uses the [dependency inversion principle](https://stackify.com/dependency-inversion-principle/) to communicate with the outside world through ports. The benefit of dependency inversion is that you can change the domain model freely without being afraid to break other parts of the code. Because the domain model reflects the business problem that you are trying to solve, updating the domain model to adapt to changing business requirements isn’t a problem. +In classical layered architecture, the domain depends on the persistence layer. If you want to change the domain, you would also have to change the persistence layer. In comparison, in hexagonal architecture, the domain doesn't depend on other modules in the software. The domain is the core of the application, and all other modules (ports and adapters) depend on the domain model. The domain uses the [dependency inversion principle](https://stackify.com/dependency-inversion-principle/) to communicate with the outside world through ports. The benefit of dependency inversion is that you can change the domain model freely without being afraid to break other parts of the code. Because the domain model reflects the business problem that you are trying to solve, updating the domain model to adapt to changing business requirements isn't a problem. @@ -29 +29 @@ In hexagonal architecture, primary adapters are responsible for loosely coupling -The [service façade pattern](https://refactoring.guru/design-patterns/facade) provides a front-facing interface to serve clients such as the presentation layer or a microservice. A service façade provides clients with several read and write operations. It’s responsible for transferring incoming requests to the domain and mapping the response received from the domain to clients. Using a service façade is easy for microservices that have a single responsibility with several operations. However, when using the service façade, it is harder to follow [single responsibility and open-closed principles](https://itnext.io/solid-principles-explanation-and-examples-715b975dcad4). The single responsibility principle states that each module should have responsibility over only a single functionality of the software. The open-closed principle states that code should be open for extension and closed for modification. As the service façade extends, all operations are collected in one interface, more dependencies are encapsulated into it, and more developers start modifying the same façade. Therefore, we recommend using a service façade only if it’s clear that the service would not extend a lot during development. +The [service façade pattern](https://refactoring.guru/design-patterns/facade) provides a front-facing interface to serve clients such as the presentation layer or a microservice. A service façade provides clients with several read and write operations. It's responsible for transferring incoming requests to the domain and mapping the response received from the domain to clients. Using a service façade is easy for microservices that have a single responsibility with several operations. However, when using the service façade, it is harder to follow [single responsibility and open-closed principles](https://itnext.io/solid-principles-explanation-and-examples-715b975dcad4). The single responsibility principle states that each module should have responsibility over only a single functionality of the software. The open-closed principle states that code should be open for extension and closed for modification. As the service façade extends, all operations are collected in one interface, more dependencies are encapsulated into it, and more developers start modifying the same façade. Therefore, we recommend using a service façade only if it's clear that the service would not extend a lot during development. @@ -37 +37 @@ CQRS has great benefits in the long term, but requires an initial investment. Fo -A combination of hexagonal architecture, domain-driven design, and (optionally) CQRS enables your organization to quickly scale your product. According to [Conway’s Law](https://www.thoughtworks.com/insights/articles/demystifying-conways-law), software architectures tend to evolve to reflect a company’s communication structures. This observation has historically had negative connotations, because big organizations often structure their teams based on technical expertise such as database, enterprise service bus, and so on. The problem with this approach is that product and feature development always involve crosscutting concerns, such as security and scalability, which require constant communication among teams. Structuring teams based on technical features creates unnecessary silos in the organization, which result in poor communications, lack of ownership, and losing sight of the big picture. Eventually, these organizational problems are reflected in the software architecture. +A combination of hexagonal architecture, domain-driven design, and (optionally) CQRS enables your organization to quickly scale your product. According to [Conway's Law](https://www.thoughtworks.com/insights/articles/demystifying-conways-law), software architectures tend to evolve to reflect a company's communication structures. This observation has historically had negative connotations, because big organizations often structure their teams based on technical expertise such as database, enterprise service bus, and so on. The problem with this approach is that product and feature development always involve crosscutting concerns, such as security and scalability, which require constant communication among teams. Structuring teams based on technical features creates unnecessary silos in the organization, which result in poor communications, lack of ownership, and losing sight of the big picture. Eventually, these organizational problems are reflected in the software architecture.