Software Architecture: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (44 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
* Pimp My Architecture - Rearchitecting an Application without Rewriting it from Scratch http://www.infoq.com/presentations/north-pimp-my-architecture | * Pimp My Architecture - Rearchitecting an Application without Rewriting it from Scratch http://www.infoq.com/presentations/north-pimp-my-architecture | ||
* http://www.oodesign.com/design-principles.html | * http://www.oodesign.com/design-principles.html | ||
=Internal= | =Internal= | ||
* [[Software Engineering]] | |||
* [[Software | * [[EvoA|Building Evolutionary Architectures: Automated Software Governance 2nd Edition]] by Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage | ||
=Overview= | |||
The art of software architecture belongs under the larger domain of [[Software_Engineering#Software_Architecture|software engineering]], alongside [[Software_Development#Overview|software development]]. | |||
=Subjects= | =Subjects= | ||
| Line 19: | Line 17: | ||
* [[The Law of Demeter]] | * [[The Law of Demeter]] | ||
* [[12 Factor App]] | * [[12 Factor App]] | ||
* [[Design Patterns]] | * [[Design Patterns]] | ||
* [[Actor Model]] | * [[Actor Model]] | ||
| Line 28: | Line 24: | ||
* [[Real-Time Computing]] | * [[Real-Time Computing]] | ||
* [[Eventually Consistent Systems]] | * [[Eventually Consistent Systems]] | ||
* [https://martinfowler.com/bliki/FluentInterface.html Fluent Interface] | * [https://martinfowler.com/bliki/FluentInterface.html Fluent Interface] | ||
* [[Universal Scalability Law]], [[Amdahl | * [[Universal Scalability Law]], [[Amdahl's Law]] | ||
* [[Domain-Driven Design]] | * [[Domain-Driven Design]] | ||
* [[Single Page Application (SPA)]] | * [[Single Page Application (SPA)]] | ||
| Line 37: | Line 31: | ||
* [[Distributed Systems]] | * [[Distributed Systems]] | ||
* [[Software Security]] | * [[Software Security]] | ||
* [[ACID]] | |||
* <span id='Microservices'></span>[[Microservices]] Architecture | |||
=Concepts= | |||
==Software Architecture== | |||
===Evolutionary Software Architecture=== | |||
Evolutionary software architecture is the sum of software engineering practices and techniques, as well as structural architectural patterns that allow incremental guided change across multiple dimensions of a software system. The dimensions in question include first and foremost the [[#Domain|domain]], but also multiple other [[#Architectural_Characteristics|architectural characteristics]] the system designers deem as important. | |||
==Requirements== | |||
Functional requirements (related to [[#Domain|domain]]) and non-functional requirements, associated to [[#Architectural_Characteristics|architectural characteristics]]. | |||
==Domain== | |||
==Architectural Characteristics== | |||
==Framework== | |||
==Platform== | |||
==Architectural Governance== | |||
<font color=darkkhaki>Definition. TO DO.</font> | |||
Architectural governance includes code reviews, architecture review boards (manual, bureaucracy). | |||
==Change== | |||
Incremental change. | |||
==Architectural Patterns== | |||
==Coupling and Cohesion== | |||
<font color=darkkhaki>Referred by: | |||
* [[Infrastructure_as_Code_Concepts#Infrastructure_Code_Management|Infrastructure as Code Concepts | Infrastructure Code Management]]</font> | |||
===Connascence=== | |||
{{Internal|Connascence|Connascence}} | |||
===Bounded Context=== | |||
=Organizatorium= | =Organizatorium= | ||
| Line 43: | Line 71: | ||
* Next Architecture: https://www.oreilly.com/ideas/3-emerging-trends-tech-leaders-should-watch#next-architecture | * Next Architecture: https://www.oreilly.com/ideas/3-emerging-trends-tech-leaders-should-watch#next-architecture | ||
* Banking startup that uses Java, deploys on AWS, and builds "microliths" https://www.infoq.com/podcasts/cloud-based-banking-startup-java | * Banking startup that uses Java, deploys on AWS, and builds "microliths" https://www.infoq.com/podcasts/cloud-based-banking-startup-java | ||
* [[Architectural Decision Records]] | |||
* [[Behavior-Driven Development]] | |||
=TODO= | |||
* Clean Architecture https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164/ | |||
Latest revision as of 04:16, 31 December 2023
External
- https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure-ebook-dp-B075LRM681/dp/B075LRM681/
- Generic Development and Architecture http://www.infoq.com/articles/CCC-Jimmy-Nilsson
- Pimp My Architecture - Rearchitecting an Application without Rewriting it from Scratch http://www.infoq.com/presentations/north-pimp-my-architecture
- http://www.oodesign.com/design-principles.html
Internal
- Software Engineering
- Building Evolutionary Architectures: Automated Software Governance 2nd Edition by Neal Ford, Rebecca Parsons, Patrick Kua, Pramod Sadalage
Overview
The art of software architecture belongs under the larger domain of software engineering, alongside software development.
Subjects
- Hexagonal Architecture
- The Law of Demeter
- 12 Factor App
- Design Patterns
- Actor Model
- SOLID Principles
- Reactive Programming
- Parallelism
- Real-Time Computing
- Eventually Consistent Systems
- Fluent Interface
- Universal Scalability Law, Amdahl's Law
- Domain-Driven Design
- Single Page Application (SPA)
- Self-Contained Systems
- Distributed Systems
- Software Security
- ACID
- Microservices Architecture
Concepts
Software Architecture
Evolutionary Software Architecture
Evolutionary software architecture is the sum of software engineering practices and techniques, as well as structural architectural patterns that allow incremental guided change across multiple dimensions of a software system. The dimensions in question include first and foremost the domain, but also multiple other architectural characteristics the system designers deem as important.
Requirements
Functional requirements (related to domain) and non-functional requirements, associated to architectural characteristics.
Domain
Architectural Characteristics
Framework
Platform
Architectural Governance
Definition. TO DO.
Architectural governance includes code reviews, architecture review boards (manual, bureaucracy).
Change
Incremental change.
Architectural Patterns
Coupling and Cohesion
Referred by:
Connascence
Bounded Context
Organizatorium
- https://www.infoq.com/presentations/starling-bank: "If you develop, you break things", the story of a bank building their systems on Java. They move money. Apparently they move fast. Self-contained systems, microliths, AWS working well for them, no startup dependencies, no distributed transactions, L.O.A.S.C.T.T.D.I.T.T.E.O, shortened to DITTO, idempotency, building skepticism into services, why Java, safe instance termination.
- Next Architecture: https://www.oreilly.com/ideas/3-emerging-trends-tech-leaders-should-watch#next-architecture
- Banking startup that uses Java, deploys on AWS, and builds "microliths" https://www.infoq.com/podcasts/cloud-based-banking-startup-java
- Architectural Decision Records
- Behavior-Driven Development