Architecture

Conway's Law is an adage in software engineering which states that “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” It was formulated by Melvin Conway in 1968.
The law is based on the reasoning that in order for a product to function, the authors and designers of its component parts must communicate with each other in order to ensure compatibility between the components. Therefore, the technical structure of a system will reflect the social boundaries of the organizations that produced it, across which communication is more difficult. In colloquial terms, it means complex products end up "shaped like" the organizational structure they are designed in or designed for. The law is applied primarily in the field of software architecture, though Conway directed it more broadly and its assumptions and conclusions apply to most technical fields.

https://en.wikipedia.org/wiki/Conway%27s_law

https://serverlessland.com/workflows 

Serverless First

Serverless First

• ¢ Quicker to market

• « Reduced operational complexity

• ¢ Massive scalability

• ¢ High availability

• ¢ Future proofed technology stack

• e Lower running cost (pay for use)

• « Reusable reference architecture

« Serverless First is a mindset — still buy before build

The heart of software is its ability to solve domain-related problems for its user.
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

What are the three sub-domain types?
Core: encapsulate your business-differentiating functionality which

gives you competitive advantage as an organization, and where 80%

of our engineering effort is

Supporting: should help support the core domains but don’t give

value on their own. These don’t affect your competitiveness

 Generic: These domains are typically very complex to build, offer no

competitive advantage to the business, do not change very often, and

should ‘ideally’ be bought off the shelf

What are the three sub-domain types?

¢ Core: Order fulfilment, product, customer, price

¢ Supporting: Data, BI, integrations, and messaging

¢ Generic: Finance, people, HR, auth

an event-driven architecture strategy:

« Allows us to have decoupled domain and experience services

« Enables the services to scale independently

¢ Our events are based on our domain models

¢ Enables us to utilize error handling and retries

« Allows for loose coordination between domain teams

- Also allows integration with 3rd-party systems (event gateway pattern)

Serverless 

We commonly think about serverless as something that helps us not have to worry about infrastructure.  But what if serverless was also a way to reduce the amount of application code  that we need to write? What if we could replace application code that we would need to write and maintain?

And along the way, we make our applications more robust and more scalable.

Use lambda Destination to send result of lambda , isntead of having it in logic .

This gives seperation of concerns should the destination change it will be in Automation Code and not in business logic

https://youtu.be/bIu8XZZROw4?t=614

Choreography to Orchestration 

https://youtu.be/bIu8XZZROw4?t=804

User Event bridge pipes 

Approach 1 

Step 1 : Lambda -- DDB 

Step 2 : lambda --> Event -- Eventbridge 

refactor to Appriach 2 

Lambda --> DDB -- DDB Streams -->  AMZ Event bridge Pipes -Event -- EventBridge 

manage trasactional integrity better than
https://youtu.be/bIu8XZZROw4?t=1094

Operational considerations:

Latency, cost, resilience