📚 Kafka in Action.
#book

📚 The art of immutable architecture.
#book

📚 Software Architecture: The hard parts
#book

پ.ن: خوندن این کتاب از اوجب واجبات است برای دولوپرای بک اند

مایکروسافت داره Typescript رو از نو با Go پیاده سازی میکنه و بهبود چشمگیری در پرفرمنس کامپایلر دیده میشه که :
۱. مدت بیلد پروژه ها
۲. استارتاپ ادیتور
۳. مصرف مموری
کاهش یافته! و این حدود 8x و بیشتر هست :]

بنابر تخمینی که میزنند در انتهای 2025 ریلیز این پروژه رو بعنوان Artifact توی گیت هاب خواهیم داشت.

https://github.com/microsoft/typescript-go

مایکروسافت میتونست همینکارو با خود dotnet هم انجام بده. مثلا با #C یا حتی #F. آیا میکروسافت واقعا قبول کرده bullshit زیاد ساخته و Google ازش بهتره؟ :)

#meme

ولی جدی بنظرم اینکارو با Rust انجام میدادن نتیجه خیلی بهتری میگرفتن :)

Architectural Decision Records (ADRs) are documents that capture important architectural decisions made during a project.

They provide a structured way to document the context, rationale, and implications of key decisions, ensuring that the reasoning behind those decisions is preserved and communicated to stakeholders, team members, and future maintainers.

An ADR typically includes the following sections:

1. Title: A concise and descriptive name for the decision.

2. Status: The current state of the decision (e.g., proposed, accepted, deprecated, superseded).

3. Context: The background or problem that necessitated the decision. This includes the circumstances, constraints, and requirements that influenced the decision.

4. Decision: A clear statement of the decision that was made.

5. Rationale: The reasoning behind the decision, including trade-offs, alternatives considered, and why this decision was chosen over others.

6. Consequences: The expected or observed outcomes of the decision, including benefits, drawbacks, and potential risks.

7. Alternatives: Other options that were considered and why they were rejected.

8. Related Decisions: Links to other ADRs or decisions that are relevant to this one.

9. References: Any supporting materials, such as documents, diagrams, or discussions.

When to Use ADRs?

1. Long-term projects where team members may change over time.

2. Complex systems where architectural decisions have significant implications.

3. Open-source projects where contributors need to understand the reasoning behind decisions.

4. Teams that value documentation and knowledge sharing.

ADR Tools you need to know

1. https://github.com/npryce/adr-tools

2. https://github.com/adr/madr

#software_architecture #architecture_design

What is Architecture Governance?

Architecture governance refers to the framework and processes that ensure an organization's IT architecture aligns with its business goals, complies with regulations, and maintains consistency, quality, and scalability. It involves:

- Defining and enforcing architectural principles, standards, and guidelines.

- Ensuring compliance with organizational and regulatory requirements.

- Managing risks associated with architectural decisions.

- Providing oversight and accountability for architectural changes.

Static vs Dynamic Coupling Concept in Software Architecture

🔹 Static Coupling:

Static coupling refers to the dependencies between modules or components that are evident at compile time or through the source code structure. It is determined by analyzing the code without executing it.

1. Visible in Code: Static coupling is visible in the source code, such as through class inheritance, method calls, or import statements.

2. Compile-Time Dependency: It represents dependencies that are resolved during compilation.

3. Impact: High static coupling can make the system rigid and harder to modify because changes in one module may require changes in dependent modules. Low static coupling promotes modularity and easier maintenance.

Example of static coupling:

// Class A is statically coupled to Class B
class A {
void method() {
B b = new B();
b.doSomething();
}
}

class B {
void doSomething() {
System.out.println("Doing something");
}
}

🔸 Dynamic Coupling

Dynamic coupling refers to the dependencies between modules or components that arise during runtime. It is not visible in the source code and depends on the execution flow of the program.

1. Runtime Dependency: Dynamic coupling is determined by how components interact during the execution of the program.

2. Not Visible in Code: It cannot be fully understood by just analyzing the source code; runtime behavior must be observed.

3. Impact: High dynamic coupling can make the system harder to debug and test because dependencies are not explicit in the code. Proper management of dynamic coupling (e.g., through design patterns like dependency injection) can improve flexibility and testability.

Example of dynamic coupling:

// Dynamic coupling through polymorphism
interface Service {
void execute();
}

class ServiceA implements Service {
public void execute() {
System.out.println("Service A");
}
}

class ServiceB implements Service {
public void execute() {
System.out.println("Service B");
}
}

class Client {
private Service service;

// Dependency injection (dynamic coupling)
public Client(Service service) {
this.service = service;
}

void performTask() {
service.execute();
}
}

// Runtime behavior determines which service is used
public class Main {
public static void main(String[] args) {
Service service = new ServiceA(); // Could be ServiceB at runtime
Client client = new Client(service);
client.performTask();
}
}

🔺 What is Architecture Quantum?

An architecture quantum is a self-contained, independently deployable unit of software that includes all the necessary components to deliver a specific functionality.

It is the smallest unit of architecture that can stand alone and operate independently. Key characteristics of an architecture quantum include:

1. Independently Deployable: It can be deployed without requiring changes to other parts of the system.

2. Self-Contained: It includes all the necessary components (e.g., code, data, configuration) to function.

3. Autonomous: It operates independently and does not rely on other quanta for its core functionality.

4. Scalable: It can be scaled independently of other quanta.

5. Aligned to Business Capabilities: It typically corresponds to a specific business capability or domain.

پروفسور دانشگاه استنفورد John Ousterhout راجب فلسفه معماری نرم افزار و اهمیت آن صحبت میکند. همینطور راجب کتابی که در همین موضوع نوشته است. جان بر این باور هست که برنامه نویس های خوب میتونن تعلیم داده بشن.

یکی از کار های مهم و بزرگ ایشون برگذار کردن کورس هایی در دانشگاه است که دانشجویان به نوشتن پروژه مختلف های مختلف با domain های مختلف میپردازند. و در نهایت جان به خواندن و تحلیل آن کد ها از منظر معماری نرم افزار میپردازد :)

https://youtu.be/bmSAYlu0NcY?si=Nusz7U8mLId_D4gG

این کتاب واقعا العاده ست! clue هایی که میده رو واقعا useful یافتم.

تو این ویدیو هم نویسنده ش Mark Richards راجب :

Difference between Atomic vs Eventual Transactions

حرف میزنه.

https://www.youtube.com/watch?v=trmwHdumBrs

پ.ن: این کتاب بشدت پیشنهادیه :)

Orchestration vs Choreography Coordination

▫️Orchestration:

1. Centralized Control: Orchestration involves a central component (the "orchestrator") that dictates the flow of interactions between services. This orchestrator is responsible for telling each service what to do and when to do it.

2. Command-Driven: The orchestrator issues commands to the services, instructing them to perform specific actions.  

3. Characteristics:

3.1: Provides clear visibility into the workflow.

3.2: Simplifies error handling, as the orchestrator can manage retries and compensations.  

3.3: Can introduce a single point of failure if the orchestrator fails.  

3.4: Can lead to tighter coupling between the orchestrator and the services.

4. Analogy: A conductor leading an orchestra, telling each musician when to play.

▫️Choreography:

1. Decentralized Control: Choreography relies on services communicating with each other through events. Each service is responsible for knowing when to act based on the events it receives.
There is no central coordinator.

2. Event-Driven: Services publish events when they complete a task, and other services subscribe to those events.

3. Characteristics:

3.1: Promotes loose coupling between services.  

3.2: Increases system resilience, as there is no single point of failure.  

3.3: Can make it more difficult to track the overall workflow.

3.4: Can make debugging and troubleshooting more challenging.

4. Analogy: A group of dancers who know their parts and perform together without a leader, responding to each other's movements.

◾️Choosing Between Them:

The choice between orchestration and choreography depends on the specific needs of the application.

- Orchestration is often preferred for complex workflows that require strict control and visibility.

- Choreography is often preferred for highly scalable and resilient systems where loose coupling is essential.  

It is also possible to use a hybrid approach, combining elements of both orchestration and choreography.

این ها پارامتر هایی ست که Software Architect موقع دیزاین معماری یک نرم افزار در نظر میگیرد که راجب ارتباط میان سرویس ها (Communication) و استحکام سرویس ها از نظر ساختاری (Consistency) و هم پایگی (Coordination) آن ها است.

انتخاب هر کدام ازین ها یک trade-off است و اینطور نیست که انتخاب یکی از ان ها بهترین سولوشن ممکن باشد.

یک کورس آموزشی Go از طرف شرکت محبوب RedHat. از دستش ندید‌ :)

https://github.com/RedHatOfficial/GoCourse

برا ویندوز هم tiling window manager ساختن :)

https://github.com/LGUG2Z/komorebi

شایدم میدونستید من نمیدونستم.
ولی خیلی باحاله :>

پ.ن: عیدتونم مبارک❤️🤌🏿

یه HttpRouter خیلی ساده با C ساختم🙂🤌🏿

هدف یادگیری بود که با موفقیت انجام شد.
اگه خواستید میتونید ریپو شو چک کنید :

https://github.com/tahadostifam/HttpRouter-C