Forwarded from Masoud Bahrami
New Article: Introducing Goal-Oriented Software Architecture!
Ever feel like your software gets lost in technical details instead of focusing on what your business needs? In my new article, I introduce Goal-Oriented Architecture, a new architectural style developed to address challenges often seen in common approaches like Clean, Onion, Ports and Adapters, and Vertical Slicing architectures.
It's a fresh way to build software that puts your real business objectives, your "goals", right at the core.
Discover how it makes systems clearer, more effective, and perfectly aligned with your business vision 👇:
https://masoudbahrami.com/article/introducing-goal-oriented-software-architecture/
Ever feel like your software gets lost in technical details instead of focusing on what your business needs? In my new article, I introduce Goal-Oriented Architecture, a new architectural style developed to address challenges often seen in common approaches like Clean, Onion, Ports and Adapters, and Vertical Slicing architectures.
It's a fresh way to build software that puts your real business objectives, your "goals", right at the core.
Discover how it makes systems clearer, more effective, and perfectly aligned with your business vision 👇:
https://masoudbahrami.com/article/introducing-goal-oriented-software-architecture/
❤2
Forwarded from Masoud Bahrami
Have you ever been tasked with building software for a complex business process and felt like you're staring at a tangled ball of yarn?
What if you could start with the finished masterpiece and unravel it backward?
That's the aim of Exploratory Domain Discovery (EDD), a collaborative tool introduced by Masoud Bahrami.
Imagine you need to automate hotel room pricing
✅ The Desired End: The customer sees the correct final price.
🤔 Work Backward: What steps led to that price? (Discounts applied, base rate set, availability checked.)
🔄 Find Cycles: "Pricing periods" and "daily availability" are clear repeating patterns here!
By starting at the desired end result and working backward, using simple examples, EDD helps teams understand complex problems clearly. It's all about finding the main point and its surrounding details to build smarter solutions.
What if you could start with the finished masterpiece and unravel it backward?
That's the aim of Exploratory Domain Discovery (EDD), a collaborative tool introduced by Masoud Bahrami.
Imagine you need to automate hotel room pricing
✅ The Desired End: The customer sees the correct final price.
🤔 Work Backward: What steps led to that price? (Discounts applied, base rate set, availability checked.)
🔄 Find Cycles: "Pricing periods" and "daily availability" are clear repeating patterns here!
By starting at the desired end result and working backward, using simple examples, EDD helps teams understand complex problems clearly. It's all about finding the main point and its surrounding details to build smarter solutions.
❤1
Forwarded from Masoud Bahrami
Math: Discovered or invented? And Why It Matters to Dev Guys❗
There's a fundamental question that has puzzled thinkers
for centuries: Is mathematics discovered, or is it invented? This long-standing debate within the philosophy of mathematics isn't just an academic exercise.
For us in software development, as designers, modelers, architects, and developers, understanding this dichotomy, and its nuances, directly impacts how we approach complex problems and build robust systems.
--------------------
✅ The "Discovered" View:
From the perspective that mathematical truths exist independently of human thought, software professionals often find themselves acting as explorers. When I delved into domains like accounting or payroll, I encountered deeply embedded principles and seemingly immutable rules.
The precise logic of financial transactions, the established principles of double-entry bookkeeping, the complex yet consistent calculations for tax liabilities or social contributions, these feel-like inherent truths governing how money and compensation work.
We are accurately modeling fundamental relationships that exist independently, uncovering the mathematical structure of the real world within that domain.
--------------------
✅ The "Invented" View:
Aligned with the view that mathematics is a human-constructed system of symbols and rules we create, much of what we do in software involves invention. While the core accounting principles might be discovered, the way we implement them within a digital system is a creative act of invention. We invent abstract data structures to represent ledgers, design custom algorithms to handle intricate tax rules across different jurisdictions, or devise new abstract models for payroll processing that ensure scalability, auditability, and performance.
Example:
Consider the solution we invent for managing a large-scale accounting ledger. While debits and credits are discovered principles, the invented part is how we represent, store, and process millions of transactions efficiently in software. This involves devising custom data structures for journal entries, creating indexing strategies for rapid querying, and designing algorithms for real-time balance calculations. These aren't just paper-to-digital translations; they're new mathematical constructs and rules invented to harness computational power, ensuring consistency and performance in complex digital environments.
--------------------
✅ The Nuance of the Dichotomy:
Some philosophers, like George Lakoff, argue that this dichotomy is too simplistic, suggesting mathematics emerges from our embodied human experience. From a software professional's perspective, this nuanced view resonates strongly. We are constantly observing and discovering the underlying mathematical nature of the problem space, recognizing the inherent patterns and constraints. Simultaneously, we are inventing abstract tools, languages, and systems, from low-level algorithms to high-level architectural patterns, to articulate, solve, and extend those problems.
🧐For Example:
The recognition of recurring problems in software led to the discovery of design patterns as effective solutions. However, the formalization and naming of these patterns, along with the rules for their application, were distinct acts of invention that codified and communicated this discovered knowledge in a reusable, mathematical way.
--------------------
Understanding this dynamic, knowing when we are accurately reflecting a discovered truth versus when we are inventing a new paradigm, is crucial for making sound design decisions, ensuring system integrity, fostering innovation, and ultimately, building effective software solutions.
- Masoud Bahrami
There's a fundamental question that has puzzled thinkers
for centuries: Is mathematics discovered, or is it invented? This long-standing debate within the philosophy of mathematics isn't just an academic exercise.
For us in software development, as designers, modelers, architects, and developers, understanding this dichotomy, and its nuances, directly impacts how we approach complex problems and build robust systems.
--------------------
✅ The "Discovered" View:
From the perspective that mathematical truths exist independently of human thought, software professionals often find themselves acting as explorers. When I delved into domains like accounting or payroll, I encountered deeply embedded principles and seemingly immutable rules.
The precise logic of financial transactions, the established principles of double-entry bookkeeping, the complex yet consistent calculations for tax liabilities or social contributions, these feel-like inherent truths governing how money and compensation work.
A big confession:
I simply discover that I'm not(and must not!) invent the principle that a debit equals a credit, or that gross pay minus deductions equals net pay.
We are accurately modeling fundamental relationships that exist independently, uncovering the mathematical structure of the real world within that domain.
--------------------
✅ The "Invented" View:
Aligned with the view that mathematics is a human-constructed system of symbols and rules we create, much of what we do in software involves invention. While the core accounting principles might be discovered, the way we implement them within a digital system is a creative act of invention. We invent abstract data structures to represent ledgers, design custom algorithms to handle intricate tax rules across different jurisdictions, or devise new abstract models for payroll processing that ensure scalability, auditability, and performance.
Example:
Consider the solution we invent for managing a large-scale accounting ledger. While debits and credits are discovered principles, the invented part is how we represent, store, and process millions of transactions efficiently in software. This involves devising custom data structures for journal entries, creating indexing strategies for rapid querying, and designing algorithms for real-time balance calculations. These aren't just paper-to-digital translations; they're new mathematical constructs and rules invented to harness computational power, ensuring consistency and performance in complex digital environments.
--------------------
✅ The Nuance of the Dichotomy:
Some philosophers, like George Lakoff, argue that this dichotomy is too simplistic, suggesting mathematics emerges from our embodied human experience. From a software professional's perspective, this nuanced view resonates strongly. We are constantly observing and discovering the underlying mathematical nature of the problem space, recognizing the inherent patterns and constraints. Simultaneously, we are inventing abstract tools, languages, and systems, from low-level algorithms to high-level architectural patterns, to articulate, solve, and extend those problems.
🧐For Example:
The recognition of recurring problems in software led to the discovery of design patterns as effective solutions. However, the formalization and naming of these patterns, along with the rules for their application, were distinct acts of invention that codified and communicated this discovered knowledge in a reusable, mathematical way.
Our work is a continuous cycle of recognizing existing mathematical structures and then creatively constructing the digital scaffolding around them.--------------------
Understanding this dynamic, knowing when we are accurately reflecting a discovered truth versus when we are inventing a new paradigm, is crucial for making sound design decisions, ensuring system integrity, fostering innovation, and ultimately, building effective software solutions.
- Masoud Bahrami
YouTube
George Lakoff - Is Mathematics Invented or Discovered?
Donate to Closer To Truth and help us keep our content free and without paywalls: https://shorturl.at/OnyRq
Free access Closer to Truth's library of 5,000 videos: https://bit.ly/2UufzC7
Mathematics describes the real world of atoms and acorns, stars and…
Free access Closer to Truth's library of 5,000 videos: https://bit.ly/2UufzC7
Mathematics describes the real world of atoms and acorns, stars and…
Forwarded from Masoud Bahrami
For a long time, I struggled with complex domains like accounting and payroll. My initial mistake🙋♂️? Thinking I had to invent a better double-entry bookkeeping system or a new way to handle credit/debit equality.
But DDD revealed two profound truths:
🟣 Deep Understanding is Key: The more effort I invested in truly understanding the problem domain the more clearly the right solution emerged.
🟣 Needs vs. Wants: What customers or domain experts express are often just wants. My role shifted to using these wants as clues to uncover the real underlying needs.
I realized my job wasn't to reinvent established accounting principles. Instead it was to discover their true essence and the profound ideas behind them.
At the same, for modeling and designing concepts like ledge, my primary goal was to invent the best solution for them.
A financial ledger, for instance, is far more than just a simple database table separated by year; it's a rich, living concept that demands careful, accurate representation.
But DDD revealed two profound truths:
🟣 Deep Understanding is Key: The more effort I invested in truly understanding the problem domain the more clearly the right solution emerged.
🟣 Needs vs. Wants: What customers or domain experts express are often just wants. My role shifted to using these wants as clues to uncover the real underlying needs.
I realized my job wasn't to reinvent established accounting principles. Instead it was to discover their true essence and the profound ideas behind them.
At the same, for modeling and designing concepts like ledge, my primary goal was to invent the best solution for them.
A financial ledger, for instance, is far more than just a simple database table separated by year; it's a rich, living concept that demands careful, accurate representation.
❤3
🎯 اطلاع رسانی پیشثبتنام ورکشاپ دو روزه معماری
📌 عنوان کارگاه: Designing Goal-Oriented Architecture
🧠 با تمرکز بر حل چالشهای پیشرفته DDD Plus
📅 مدت: دو روز — ۱۶ ساعت آموزشی
👥 مناسب برای: برنامهنویسان، معماران نرمافزار، مدیران محصول و CTOها
📍 بهصورت حضوری / ظرفیت محدود: حداکثر ۱۵ نفر
در این ورکشاپ یاد میگیریم چطور معماری سیستم را از «اهداف واقعی» شروع کنیم ، نه از فریمورکها و ساختارهای از پیشفرضشده.
بهجای آموزش تئوری، روی چالشهای واقعی و پیچیده کار میکنیم.
👇 اطلاعات بیشتر و ثبتنام:
https://domaindrivendesign.ir/product/%d9%88%d8%b1%da%a9%d8%b4%d8%a7%d9%be-designing-goal-oriented-architecture-with-ddd-plus-challenges/
👇لینک مستقیم فرم پیش ثبتنام:
کلیک کنید
📌 عنوان کارگاه: Designing Goal-Oriented Architecture
🧠 با تمرکز بر حل چالشهای پیشرفته DDD Plus
📅 مدت: دو روز — ۱۶ ساعت آموزشی
👥 مناسب برای: برنامهنویسان، معماران نرمافزار، مدیران محصول و CTOها
📍 بهصورت حضوری / ظرفیت محدود: حداکثر ۱۵ نفر
در این ورکشاپ یاد میگیریم چطور معماری سیستم را از «اهداف واقعی» شروع کنیم ، نه از فریمورکها و ساختارهای از پیشفرضشده.
بهجای آموزش تئوری، روی چالشهای واقعی و پیچیده کار میکنیم.
👇 اطلاعات بیشتر و ثبتنام:
https://domaindrivendesign.ir/product/%d9%88%d8%b1%da%a9%d8%b4%d8%a7%d9%be-designing-goal-oriented-architecture-with-ddd-plus-challenges/
👇لینک مستقیم فرم پیش ثبتنام:
کلیک کنید
مکتبخانه DDD
ورکشاپ Designing Goal-Oriented Architecture: with DDD Plus Challenges | مکتبخانه DDD
دوره آموزشی دو روزه معماری Goal-Orinted Architecture بصورت عملی و مبتنی بر سناریوهای DDD Plus
کانال مکتبخانه DDD
🎯 اطلاع رسانی پیشثبتنام ورکشاپ دو روزه معماری 📌 عنوان کارگاه: Designing Goal-Oriented Architecture 🧠 با تمرکز بر حل چالشهای پیشرفته DDD Plus 📅 مدت: دو روز — ۱۶ ساعت آموزشی 👥 مناسب برای: برنامهنویسان، معماران نرمافزار، مدیران محصول و CTOها 📍 بهصورت…
✨صبح همگی عزیزان بخیر🌱
ظرفیت پیشثبتنام کارگاه Designing Goal-Oriented Architecture در کمتر از یک روز تکمیل شد! از استقبال شما سپاسگزاریم.❤️ 🙏
به زودی با عزیزانی که موفق به ثبتنام شدن تماس میگیریم تا مرحله بعدی رو تکمیل کنیم.
برای دوستانی هم که جا موندن: داریم بررسی میکنیم که بتونیم ظرفیت رو یه کوچولو بیشتر کنیم! اگه شد، همینجا اطلاع میدیم 💬👀
ظرفیت پیشثبتنام کارگاه Designing Goal-Oriented Architecture در کمتر از یک روز تکمیل شد! از استقبال شما سپاسگزاریم.❤️ 🙏
به زودی با عزیزانی که موفق به ثبتنام شدن تماس میگیریم تا مرحله بعدی رو تکمیل کنیم.
برای دوستانی هم که جا موندن: داریم بررسی میکنیم که بتونیم ظرفیت رو یه کوچولو بیشتر کنیم! اگه شد، همینجا اطلاع میدیم 💬👀
Forwarded from Masoud Bahrami
🚀 Need advanced date/time manipulation in .NET?
I'm excited to announce the release of Quantum.Tempo v1.0.0, a powerful, calendar-agnostic date/time framework for .NET!
🔹 Intuitive string-based API for dates, times, intervals, and durations
🔹 Supports multiple calendars: Gregorian, Persian (Shamsi), Hijri, and custom
🔹 Recurrence rules (RRULE), interval algebra, fuzzy date parsing, and timezone support
🔹 Comes with a handy REPL CLI for interactive exploration
🔹 Fully ISO-compliant and localization-ready
Check it out on NuGet:
👉 https://www.nuget.org/packages/Quantum.Tempo/
🌟 Try it, contribute, and let's make date/time handling in .NET simpler and smarter!
I'm excited to announce the release of Quantum.Tempo v1.0.0, a powerful, calendar-agnostic date/time framework for .NET!
🔹 Intuitive string-based API for dates, times, intervals, and durations
🔹 Supports multiple calendars: Gregorian, Persian (Shamsi), Hijri, and custom
🔹 Recurrence rules (RRULE), interval algebra, fuzzy date parsing, and timezone support
🔹 Comes with a handy REPL CLI for interactive exploration
🔹 Fully ISO-compliant and localization-ready
Check it out on NuGet:
👉 https://www.nuget.org/packages/Quantum.Tempo/
🌟 Try it, contribute, and let's make date/time handling in .NET simpler and smarter!
www.nuget.org
Quantum.Tempo 1.0.2
Quantum.Tempo is a powerful, calendar-agnostic .NET library for intuitive and ISO-compliant manipulation of dates, times, intervals, and durations. It supports Gregorian, Persian (Shamsi), Hijri, and custom calendars using a clean, string-based API. Features…
Forwarded from Masoud Bahrami
💡Sequencer Design Pattern
In my experience modeling and designing complex domains, I've utilized not only existing design patterns and heuristics but also developed a unique perspective on problems.
I’ve observed that many issues inherently possess a sense of repetition and circularity. For example, an hour can be modeled as a sequencer that completes 24 cycles, encompassing minutes that each complete 60 cycles.
Similarly, consider how a dollar is represented in cents; after every 100 cents, it wraps into a dollar.
To address these types of problems, I introduced the Sequencer Design Pattern, which can be beneficial in various situations.
Read the article and see examples here👇
https://masoudbahrami.com/article/introducing-sequencer-pattern/
In my experience modeling and designing complex domains, I've utilized not only existing design patterns and heuristics but also developed a unique perspective on problems.
I’ve observed that many issues inherently possess a sense of repetition and circularity. For example, an hour can be modeled as a sequencer that completes 24 cycles, encompassing minutes that each complete 60 cycles.
Similarly, consider how a dollar is represented in cents; after every 100 cents, it wraps into a dollar.
To address these types of problems, I introduced the Sequencer Design Pattern, which can be beneficial in various situations.
Read the article and see examples here👇
https://masoudbahrami.com/article/introducing-sequencer-pattern/
Masoud Bahrami
Introducing The Sequencer Pattern
Learn the Sequencer Pattern: a behavioral design pattern for bounded, wrap-around progressions (time, currency, buffers). Includes UML, JS examples, test strategy, and composition best practices.
❤1
🎯 ثبتنام عمومی برای ورکشاپ Goal-Oriented Software Architecture (GOA) شروع شده است.
همانطور که قبلاً اشاره شد، این کارگاه دو روزه با تمرکز بر حل چالشهای پیشرفته DDD Plus برگزار میشود و به شما کمک میکند تا:
🟣 یاد بگیرید چطور معماری سیستم را از «اهداف واقعی» شروع کنید.
🟣 به جای تئوری، روی چالشهای پیچیده و واقعی کار کنید و تجربه کسب نمایید.
ظرفیت این دوره به صورت حضوری و محدود است.
📅 مدت: دو روز — ۱۶ ساعت آموزشی. تاریخ 27 و 28 شهریور 1404
👥 اگر برنامهنویس، معمار نرمافزار، مدیر محصول یا CTO هستید، این کارگاه برای شما مفید میباشد.
برای اطلاعات بیشتر و ثبتنام، از طریق لینک زیر اقدام کنید:
https://evand.com/events/masoud-bahrami-goa-workshop
برای آشنایی عمیقتر با مفاهیم، میتوانید مقالههای زیر را مطالعه کنید:
🧠 Goal-Oriented Architecture: https://masoudbahrami.com/article/introducing-goal-oriented-software-architecture/
❓DDD Plus Challenges: https://domaindrivendesign.ir/tag/ddd-plus/
منتظر دیدار شما در این ورکشاپ کاربردی هستیم.
همانطور که قبلاً اشاره شد، این کارگاه دو روزه با تمرکز بر حل چالشهای پیشرفته DDD Plus برگزار میشود و به شما کمک میکند تا:
🟣 یاد بگیرید چطور معماری سیستم را از «اهداف واقعی» شروع کنید.
🟣 به جای تئوری، روی چالشهای پیچیده و واقعی کار کنید و تجربه کسب نمایید.
ظرفیت این دوره به صورت حضوری و محدود است.
📅 مدت: دو روز — ۱۶ ساعت آموزشی. تاریخ 27 و 28 شهریور 1404
👥 اگر برنامهنویس، معمار نرمافزار، مدیر محصول یا CTO هستید، این کارگاه برای شما مفید میباشد.
برای اطلاعات بیشتر و ثبتنام، از طریق لینک زیر اقدام کنید:
https://evand.com/events/masoud-bahrami-goa-workshop
برای آشنایی عمیقتر با مفاهیم، میتوانید مقالههای زیر را مطالعه کنید:
🧠 Goal-Oriented Architecture: https://masoudbahrami.com/article/introducing-goal-oriented-software-architecture/
❓DDD Plus Challenges: https://domaindrivendesign.ir/tag/ddd-plus/
منتظر دیدار شما در این ورکشاپ کاربردی هستیم.
❤1
نقطه | جایی که هر چیز آغاز میشود.
سلام دوستان عزیز و گرامی ✨
میخواهیم از «نقطه» بگیم.
نه یک نقطهی ساده؛ بلکه نقطهای که آغازگر همه چیز است.
نقطهای که برای نویسنده اولین واژه است، برای نقاش اولین ضربه قلممو و برای ما برنامهنویسها، اولین خط کد.
همان جرقهای که از دلش معماریها، محصولها و مسیرهای بزرگ ساخته میشوند.
ما باور داریم:
هر ایدهای از یک نقطه شروع میشود.
یک نقطه در ذهن، یک نقطه روی تخته سفید، یک نقطه در اولین commit.
نقطه، جایی برای گردهمآیی ماست.
جایی برای همفکری، برای بازگشت به اصول و برای کشف کردن. جایی که از یک نقطه، یک مسیر میسازیم و از یک ایده، یک جامعهی پویا.
بهزودی با اولین برنامه میایم، تا اولین نقطهی این مسیر رو با هم بگذاریم.
👀 منتظر خبرهای بعدی باشید...
سلام دوستان عزیز و گرامی ✨
میخواهیم از «نقطه» بگیم.
نه یک نقطهی ساده؛ بلکه نقطهای که آغازگر همه چیز است.
نقطهای که برای نویسنده اولین واژه است، برای نقاش اولین ضربه قلممو و برای ما برنامهنویسها، اولین خط کد.
همان جرقهای که از دلش معماریها، محصولها و مسیرهای بزرگ ساخته میشوند.
ما باور داریم:
هر ایدهای از یک نقطه شروع میشود.
یک نقطه در ذهن، یک نقطه روی تخته سفید، یک نقطه در اولین commit.
نقطه، جایی برای گردهمآیی ماست.
جایی برای همفکری، برای بازگشت به اصول و برای کشف کردن. جایی که از یک نقطه، یک مسیر میسازیم و از یک ایده، یک جامعهی پویا.
بهزودی با اولین برنامه میایم، تا اولین نقطهی این مسیر رو با هم بگذاریم.
👀 منتظر خبرهای بعدی باشید...
❤6
Noghteh | A point to begin, to think, to build
هر مسیر بزرگ با یک نقطه کوچک شروع میشود…
در صفرمین جلسه نقطه، مسعود بهرامی یک سخنرانی کوتاه با عنوان "نقطهی صفر" ارائه میدهد.
در ادامه برنامه:
- گفتوگوی آزاد با شرکتکنندگان
- پرسش و پاسخ
- برداشتها و نکات کلیدی برای آغاز مسیر
📅 زمان: سهشنبه، 19:00 – 20:15 (به وقت تهران)
📍 آنلاین
🔗 ثبتنام در Luma
📖 اطلاعات بیشتر: صفحه رویداد
هر مسیر بزرگ با یک نقطه کوچک شروع میشود…
در صفرمین جلسه نقطه، مسعود بهرامی یک سخنرانی کوتاه با عنوان "نقطهی صفر" ارائه میدهد.
در ادامه برنامه:
- گفتوگوی آزاد با شرکتکنندگان
- پرسش و پاسخ
- برداشتها و نکات کلیدی برای آغاز مسیر
📅 زمان: سهشنبه، 19:00 – 20:15 (به وقت تهران)
📍 آنلاین
🔗 ثبتنام در Luma
📖 اطلاعات بیشتر: صفحه رویداد
❤1👍1🔥1
برنامه از 30 دقیقه دیگه آغاز میشه. منتظر دیدن و شنیدن شما عزیزان هستیم😍
Forwarded from Masoud Bahrami
What if you could refactor a codebase by starting with the end in mind❓
My latest article Backward Refactoring introduces a new mindset for large code changes. Learn to use your tests and compiler as a blueprint, guiding you from the ideal end state back to reality, one safe step at a time. It’s a method for turning a chaotic refactor into a series of deliberate, low-risk steps.
🔸The Backward Refactoring Approach in a Nutshel:
Read Part 1 and start thinking backward. 👇
https://masoudbahrami.com/article/backward-refactoring-a-new-approach-for-big-code-changes/
Refactoring doesn't have to be a blind journey 🗺️.My latest article Backward Refactoring introduces a new mindset for large code changes. Learn to use your tests and compiler as a blueprint, guiding you from the ideal end state back to reality, one safe step at a time. It’s a method for turning a chaotic refactor into a series of deliberate, low-risk steps.
🔸The Backward Refactoring Approach in a Nutshel:
Backward Refactoring is a strategic mindset for tackling big code changes. Instead of starting with the current, messy code, you begin with the end in mind. The core idea is to first write the ideal, clean code you want to have.
This ideal code will immediately produce a cascade of compiler errors. These errors are not failures; they are your most valuable guideposts. Each error points to a specific part of the legacy code that needs to be refactored. This transforms an overwhelming project into a clear, step-by-step roadmap, allowing you to make small, safe changes while your tests act as a continuous safety net. It’s like solving a puzzle by starting with the finished picture and working backward.
Read Part 1 and start thinking backward. 👇
https://masoudbahrami.com/article/backward-refactoring-a-new-approach-for-big-code-changes/
Masoud Bahrami
Backward Refactoring: A New Approach for Big Code Changes
Refactoring feels like navigating a dense forest. Learn the Backward Refactoring method, where your ideal code becomes a map and the compiler's errors are your compass to a clean, maintainable codebase.
❤2👍2
Forwarded from Masoud Bahrami
Is Mathematics Invented or Discovered?
Silvia Jonas, Professor of Philosophy at the University of Bamberg, shares her answer:👇
Watch here
At first glance, this may seem like a silly overly simple or even irrelevant question especially for software engineers or product people. But for me the curiosity behind it goes much deeper. For me It’s not just about passing time by watching a video on YouTube on maths problems, it’s about following a question that has fascinated people for centuries.
------
Here’s what I keep asking myself:
🔵 Why has this question survived history? If it didn’t matter why do we still ask it after thousands of years?
🔵 Where did it start? Did someone just wake up and wonder Is math invented or discovered? Or was it born from frustration trying to explain something and stumbling upon this puzzle?
🔵 Is there even a provable answer? Or is it like asking about the meaning of life always open, never settled?
🔵 What’s at stake? How does it affect science, philosophy, or our view of reality, depending on whether math is invented or discovered?
🔵 Universality: If math is invented why does it describe the universe so precisely? If discovered where exists it before we find it?
🔵 Creativity vs. discovery: When a mathematician proves a theorem is she creating something new like a painter or uncovering something always there like an explorer?
🔵 Levels of invention/discovery: Could it be both? Numbers invented relationships discovered? Does that distinction hold?
🔵 Mind vs. reality: Is math a product of the human brain or is it embedded in reality regardless of us?
🔵 Impact on truth: If invented, is mathematics arbitrary? Could we invent it differently and still build airplanes, algorithms, or AI?
🔵 Philosophical gateway: Doesn’t this question lead to even deeper ones: What is reality? What is knowledge? What is truth?
----
🙆 Why should software engineers care?
Sometimes, the most valuable skill isn’t finding the answer it’s asking the right questions and thinking deeply. Fundamental questions even if abstract or seemingly unrelated train us to explore problems challenge assumptions and see hidden connections. Often spending time understanding the question is more important than rushing to an answer.
------
That’s why I love this question. It starts small nvented or discovered?, but quickly grows into a journey across history science philosophy and even the way we think about software.
Silvia Jonas, Professor of Philosophy at the University of Bamberg, shares her answer:👇
Watch here
At first glance, this may seem like a silly overly simple or even irrelevant question especially for software engineers or product people. But for me the curiosity behind it goes much deeper. For me It’s not just about passing time by watching a video on YouTube on maths problems, it’s about following a question that has fascinated people for centuries.
------
Here’s what I keep asking myself:
🔵 Why has this question survived history? If it didn’t matter why do we still ask it after thousands of years?
🔵 Where did it start? Did someone just wake up and wonder Is math invented or discovered? Or was it born from frustration trying to explain something and stumbling upon this puzzle?
🔵 Is there even a provable answer? Or is it like asking about the meaning of life always open, never settled?
🔵 What’s at stake? How does it affect science, philosophy, or our view of reality, depending on whether math is invented or discovered?
🔵 Universality: If math is invented why does it describe the universe so precisely? If discovered where exists it before we find it?
🔵 Creativity vs. discovery: When a mathematician proves a theorem is she creating something new like a painter or uncovering something always there like an explorer?
🔵 Levels of invention/discovery: Could it be both? Numbers invented relationships discovered? Does that distinction hold?
🔵 Mind vs. reality: Is math a product of the human brain or is it embedded in reality regardless of us?
🔵 Impact on truth: If invented, is mathematics arbitrary? Could we invent it differently and still build airplanes, algorithms, or AI?
🔵 Philosophical gateway: Doesn’t this question lead to even deeper ones: What is reality? What is knowledge? What is truth?
----
🙆 Why should software engineers care?
Sometimes, the most valuable skill isn’t finding the answer it’s asking the right questions and thinking deeply. Fundamental questions even if abstract or seemingly unrelated train us to explore problems challenge assumptions and see hidden connections. Often spending time understanding the question is more important than rushing to an answer.
------
That’s why I love this question. It starts small nvented or discovered?, but quickly grows into a journey across history science philosophy and even the way we think about software.
YouTube
Silvia Jonas - Is Mathematics Invented or Discovered?
Contribute what you can to help Closer To Truth continue exploring the world's deepest questions without paywalls: https://shorturl.at/l3q6G
Mathematics describes the real world of atoms and acorns, stars and stairs, with remarkable precision. So is mathematics…
Mathematics describes the real world of atoms and acorns, stars and stairs, with remarkable precision. So is mathematics…
Masoud Bahrami
Is Mathematics Invented or Discovered? Silvia Jonas, Professor of Philosophy at the University of Bamberg, shares her answer:👇 Watch here At first glance, this may seem like a silly overly simple or even irrelevant question especially for software engineers…
اولش شاید این سوال خیلی ساده یا حتی بیربط به نظر بیاد مخصوصا برای ما برنامهنویسها و آدمای محصول، ولی برای من داستانش خیلی عمیقتر از این حرفاست. دیدن و دنبال کردن این جور پرسشها فقط پر کردن وقت آزاد نیست و کمک میکنه ذهن کنجکاو و فعالتری در مواجه با مسائل داشته باشم
من به شخصه اینا رو از خودم میپرسم
🔹 چرا این سوال هنوز زندهست؟ اگه مهم نبود چرا بعد این همه سال هنوز بحثش داغه؟
🔹 اصلا از کجا شروع شد؟ یه نفر همینجوری یه روز از خواب بیدار شد و پرسید ریاضی اختراع شده یا کشف؟ یا وسط یه مشکل علمی گیر کرده بود و این سوال براش پیش اومد؟
🔹 اصلا جواب قطعی داره یا مثل معنای زندگی همیشه باز میمونه؟
🔹 اینکه جواب چی باشه چه تاثیری روی علم، فلسفه یا حتی نگاه ما به واقعیت میذاره؟
🔹 اگه ریاضی اختراعه چرا اینقدر دقیق جهان رو توضیح میده؟ اگه کشفه، قبل از کشف کجا بوده؟
🔹 وقتی یه ریاضیدان یه قضیه رو ثابت میکنه داره یه چیز تازه میسازه مثل یه هنرمند، یا یه چیز از قبل بوده رو پیدا میکنه مثل یه کاشف؟
🔹 شاید بعضی بخشاش اختراعه، بعضیاش کشف. این مرزبندی اصلا معنی داره؟
🔹 ریاضی ساخته ذهن ماست یا توی خود واقعیت جا خوش کرده؟
🔹 اگه اختراعه، یعنی میتونستیم یه ریاضی دیگه اختراع کنیم و بازم هواپیما، الگوریتم و هوش مصنوعی داشته باشیم؟
🔹 این سوال در نهایت در رو باز نمیکنه به سوالای خیلی بنیادیتر؟ مثل اینکه واقعیت چیه، دانش چیه، حقیقت یعنی چی؟
و خب چرا برای ما مهندسای نرمافزار مهمه؟ چون خیلی وقتا مهمتر از جواب، خود سوال پرسیدنه. اینکه یاد بگیریم عمیق فکر کنیم، فرضیات رو به چالش بکشیم و ارتباطهای پنهان رو ببینیم. حتی بعضی وقتا خود سوال مهمتر از جوابه. و مهمتر اینکه گاهی برخی سوالات، کلید باز شدن دریچهای به سوی سوالات مهمتری و کلیدیتره. گاهی سوالات درست تاثیر بیشتر نسبت به پاسخهای دقیق دارند.
همین باعث میشه این سوال برام جذاب باشه. خیلی کوچیک شروع میشه: اختراع یا کشف؟ ولی به یکباره سوالات مهمتری رو توی ذهنم باز میکنه
من به شخصه اینا رو از خودم میپرسم
🔹 چرا این سوال هنوز زندهست؟ اگه مهم نبود چرا بعد این همه سال هنوز بحثش داغه؟
🔹 اصلا از کجا شروع شد؟ یه نفر همینجوری یه روز از خواب بیدار شد و پرسید ریاضی اختراع شده یا کشف؟ یا وسط یه مشکل علمی گیر کرده بود و این سوال براش پیش اومد؟
🔹 اصلا جواب قطعی داره یا مثل معنای زندگی همیشه باز میمونه؟
🔹 اینکه جواب چی باشه چه تاثیری روی علم، فلسفه یا حتی نگاه ما به واقعیت میذاره؟
🔹 اگه ریاضی اختراعه چرا اینقدر دقیق جهان رو توضیح میده؟ اگه کشفه، قبل از کشف کجا بوده؟
🔹 وقتی یه ریاضیدان یه قضیه رو ثابت میکنه داره یه چیز تازه میسازه مثل یه هنرمند، یا یه چیز از قبل بوده رو پیدا میکنه مثل یه کاشف؟
🔹 شاید بعضی بخشاش اختراعه، بعضیاش کشف. این مرزبندی اصلا معنی داره؟
🔹 ریاضی ساخته ذهن ماست یا توی خود واقعیت جا خوش کرده؟
🔹 اگه اختراعه، یعنی میتونستیم یه ریاضی دیگه اختراع کنیم و بازم هواپیما، الگوریتم و هوش مصنوعی داشته باشیم؟
🔹 این سوال در نهایت در رو باز نمیکنه به سوالای خیلی بنیادیتر؟ مثل اینکه واقعیت چیه، دانش چیه، حقیقت یعنی چی؟
و خب چرا برای ما مهندسای نرمافزار مهمه؟ چون خیلی وقتا مهمتر از جواب، خود سوال پرسیدنه. اینکه یاد بگیریم عمیق فکر کنیم، فرضیات رو به چالش بکشیم و ارتباطهای پنهان رو ببینیم. حتی بعضی وقتا خود سوال مهمتر از جوابه. و مهمتر اینکه گاهی برخی سوالات، کلید باز شدن دریچهای به سوی سوالات مهمتری و کلیدیتره. گاهی سوالات درست تاثیر بیشتر نسبت به پاسخهای دقیق دارند.
همین باعث میشه این سوال برام جذاب باشه. خیلی کوچیک شروع میشه: اختراع یا کشف؟ ولی به یکباره سوالات مهمتری رو توی ذهنم باز میکنه
❤1
🔹 ویدئوی جدید منتشر شد! 🔹
📌 موضوع: "مقدمهای بر معماری نرمافزار"
در این ویدئو 40 دقیقهای به موارد زیر پرداختم:
🔹چرا خیلی از نرمافزارها بعد از مدتی فرو میپاشن
🔹تفاوت بین کدنویسی و معماری
🔹یک مثال واقعی: سیستم سفارش غذای آنلاین
🔹مشکل اساسی تفکر CRUD
🔹معماری چندبُعدی: ساختار، رفتار، کیفیتها، تکامل، تیمها و ارتباطات
🔹و اینکه چطور تصمیمهای امروز میتونن آینده سیستم رو بسازن یا خراب کنن
🎥 لینک تماشا در یوتیوب:
👉 https://www.youtube.com/watch?v=X9rd9hh4-DU&t
اگر به توسعه نرمافزار، معماری، یا طراحی سیستم علاقه داری، این ویدئو میتونه دیدگاهت رو عوض کنه.
📌 موضوع: "مقدمهای بر معماری نرمافزار"
در این ویدئو 40 دقیقهای به موارد زیر پرداختم:
🔹چرا خیلی از نرمافزارها بعد از مدتی فرو میپاشن
🔹تفاوت بین کدنویسی و معماری
🔹یک مثال واقعی: سیستم سفارش غذای آنلاین
🔹مشکل اساسی تفکر CRUD
🔹معماری چندبُعدی: ساختار، رفتار، کیفیتها، تکامل، تیمها و ارتباطات
🔹و اینکه چطور تصمیمهای امروز میتونن آینده سیستم رو بسازن یا خراب کنن
🎥 لینک تماشا در یوتیوب:
👉 https://www.youtube.com/watch?v=X9rd9hh4-DU&t
اگر به توسعه نرمافزار، معماری، یا طراحی سیستم علاقه داری، این ویدئو میتونه دیدگاهت رو عوض کنه.
YouTube
What is Software Architecture? Beyond CRUD, Patterns, and the Future of Your System
What if I told you your software could collapse next year—just because of the decisions you make today?
That’s the reality of software architecture.
In this 40-minute deep dive, I’ll walk you through:
What software architecture really means (and why it’s…
That’s the reality of software architecture.
In this 40-minute deep dive, I’ll walk you through:
What software architecture really means (and why it’s…
❤5❤🔥2
سلام به همگی دوستان👋
اگر در رویداد نقطهی صفر همراه ما بودید، میدانید که آغاز یک مسیر چقدر حیاتی است. حالا وقت آن است که به یکی از مهمترین چالشهای این مسیر بپردازیم: بدهی فنی.
در دنیای مهندسی نرمافزار، بدهی فنی (Technical Debt) اغلب به عنوان کد شلخته یا غیراصولی شناخته میشود؛ اما آیا واقعاً به همین سادگی است؟
مسعود بهرامی در دومین رویداد نقطه با ارائهای با عنوان بدهی فنی: فراتر از کد، فراتر از استعاره، دیدگاه شما را نسبت به این مفهوم تغییر خواهد داد. در این رویداد، بررسی میکنیم که چطور بدهی فنی فراتر از کد است و چرا باید از این استعاره ساده فاصله بگیریم تا به درک واقعی از تأثیر آن بر پروژهها و سازمانها برسیم.
بعد از ارائه، فرصت برای گفتوگوی آزاد فراهم است. این بهترین زمان برای به اشتراک گذاشتن تجربیات و سؤالات شماست.
جزئیات رویداد
سخنران: مسعود بهرامی
📅 زمان: سهشنبه 1 مهرماه 1404، 19:00 – 20:30 (به وقت تهران)
📍 آنلاین
📖 اطلاعات بیشتر: ثبتنام در Luma
منتظرتان هستیم تا با هم به عمق این موضوع برویم و دیدگاههایمان را به اشتراک بگذاریم.
اگر در رویداد نقطهی صفر همراه ما بودید، میدانید که آغاز یک مسیر چقدر حیاتی است. حالا وقت آن است که به یکی از مهمترین چالشهای این مسیر بپردازیم: بدهی فنی.
در دنیای مهندسی نرمافزار، بدهی فنی (Technical Debt) اغلب به عنوان کد شلخته یا غیراصولی شناخته میشود؛ اما آیا واقعاً به همین سادگی است؟
مسعود بهرامی در دومین رویداد نقطه با ارائهای با عنوان بدهی فنی: فراتر از کد، فراتر از استعاره، دیدگاه شما را نسبت به این مفهوم تغییر خواهد داد. در این رویداد، بررسی میکنیم که چطور بدهی فنی فراتر از کد است و چرا باید از این استعاره ساده فاصله بگیریم تا به درک واقعی از تأثیر آن بر پروژهها و سازمانها برسیم.
بعد از ارائه، فرصت برای گفتوگوی آزاد فراهم است. این بهترین زمان برای به اشتراک گذاشتن تجربیات و سؤالات شماست.
جزئیات رویداد
سخنران: مسعود بهرامی
📅 زمان: سهشنبه 1 مهرماه 1404، 19:00 – 20:30 (به وقت تهران)
📍 آنلاین
📖 اطلاعات بیشتر: ثبتنام در Luma
منتظرتان هستیم تا با هم به عمق این موضوع برویم و دیدگاههایمان را به اشتراک بگذاریم.
Luma
Noghteh | The First Meeutp · Luma
Join us for the second official Noghteh meetup! Following up on our inaugural "Noghteh #0" event, we're diving deep into a topic that every developer, manager,…
Forwarded from Masoud Bahrami
خلق از دلِ لحظه
خلق کردن برای من، مرز نمیشناسد. نه در بند صفر و یک میماند و نه در فاز کوانتوم و نه در نتهای موسیقی. این بداههنوازی آماتور، مانند یک ایدهی نرمافزاری درخشان، از دلِ یک آن بیبرنامه متولد شد؛ لحظهای که فقط به ندای درونم گوش دادم و گذاشتم جاری شوم.
نرمافزار و موسیقی، هر دو یک زبان واحد دارند: زبانِ خلق در لحظه. جایی که تمرینهای پنهان، ناگهان به یک اثر تبدیل میشوند و هر اشتباه، پلهای برای رسیدن به کمال میشود. این قطعهی کوچک، حاصل ترکیب یکسری عوامل آماتور با یک نوازش آماتور سهتار است، که برآیندش هم آماتور است. اما امیدوارم به دلِ شما بنشیند
ببینید و بشنوید👇🏻
https://youtu.be/LurNrEjGhsY
خلق کردن برای من، مرز نمیشناسد. نه در بند صفر و یک میماند و نه در فاز کوانتوم و نه در نتهای موسیقی. این بداههنوازی آماتور، مانند یک ایدهی نرمافزاری درخشان، از دلِ یک آن بیبرنامه متولد شد؛ لحظهای که فقط به ندای درونم گوش دادم و گذاشتم جاری شوم.
نرمافزار و موسیقی، هر دو یک زبان واحد دارند: زبانِ خلق در لحظه. جایی که تمرینهای پنهان، ناگهان به یک اثر تبدیل میشوند و هر اشتباه، پلهای برای رسیدن به کمال میشود. این قطعهی کوچک، حاصل ترکیب یکسری عوامل آماتور با یک نوازش آماتور سهتار است، که برآیندش هم آماتور است. اما امیدوارم به دلِ شما بنشیند
ببینید و بشنوید👇🏻
https://youtu.be/LurNrEjGhsY
YouTube
The Setar Improvisation(Amateor)
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
❤6
Forwarded from Masoud Bahrami
🎥 چهارمین ویدئوی مجموعهی شش بُعد معماری نرمافزار توی یوتیوب منتشر شد.
🌀 معماری نرمافزار خیلی بیشتر از کُد و نموداره.
اون چیزی که یه سیستم رو زنده میکنه و زنده نگه میداره، رفتارشه: جریانها، تعاملات، تصمیمها و واکنشهایی که توی عمل اتفاق میافتن. همینطور انتظاراتی که از سیستم یا محصول داریم. در واقع، انتظارات ما همون رفتارهاییه که از سیستم انتظار داریم ببینیم.
متافور کلاسیک برای نرمافزار، جعبهی سیاهـه: ورودی میره داخل، پردازش انجام میشه، و خروجی همون چیزی میشه که ما بهعنوان رفتار سیستم تجربه میکنیم.
توی این ویدئو در مورد بُعد رفتاری مختصرا صحبت کردم. جایی که معماری واقعی، خودش رو نشون میده.
اینکه سیستم چطور تغییر میکنه، چه ریتمی داره، چطور با محیط درگیر میشه، و تصمیمهای معماری چطور روی تجربهی کاربر و کیفیت نهایی تاثیر میذارن.
اگه معماری رو فقط به ساختار و اجزا محدود کنیم، نصف داستان از دست میره.
ولی وقتی رفتار رو بفهمیم، تازه میشه سیستمی ساخت که نه فقط کار کنه، بلکه رشد کنه، سازگار بشه و پایدار بمونه.
📌 ویدئوی کامل رو ببینید:
https://www.youtube.com/watch?v=KBOk_f0f9ow
🌀 معماری نرمافزار خیلی بیشتر از کُد و نموداره.
اون چیزی که یه سیستم رو زنده میکنه و زنده نگه میداره، رفتارشه: جریانها، تعاملات، تصمیمها و واکنشهایی که توی عمل اتفاق میافتن. همینطور انتظاراتی که از سیستم یا محصول داریم. در واقع، انتظارات ما همون رفتارهاییه که از سیستم انتظار داریم ببینیم.
متافور کلاسیک برای نرمافزار، جعبهی سیاهـه: ورودی میره داخل، پردازش انجام میشه، و خروجی همون چیزی میشه که ما بهعنوان رفتار سیستم تجربه میکنیم.
توی این ویدئو در مورد بُعد رفتاری مختصرا صحبت کردم. جایی که معماری واقعی، خودش رو نشون میده.
اینکه سیستم چطور تغییر میکنه، چه ریتمی داره، چطور با محیط درگیر میشه، و تصمیمهای معماری چطور روی تجربهی کاربر و کیفیت نهایی تاثیر میذارن.
اگه معماری رو فقط به ساختار و اجزا محدود کنیم، نصف داستان از دست میره.
ولی وقتی رفتار رو بفهمیم، تازه میشه سیستمی ساخت که نه فقط کار کنه، بلکه رشد کنه، سازگار بشه و پایدار بمونه.
📌 ویدئوی کامل رو ببینید:
https://www.youtube.com/watch?v=KBOk_f0f9ow
YouTube
Behavioral Dimension | Software Architecture Series
If structure is about how software is built, behavior is about how it lives and breathes. In this video, I explore the Behavioral Dimension of software architecture, flows, interactions, and dynamics that emerge when components, users, and systems connect.…
❤3
کانال مکتبخانه DDD
سلام به همگی دوستان👋 اگر در رویداد نقطهی صفر همراه ما بودید، میدانید که آغاز یک مسیر چقدر حیاتی است. حالا وقت آن است که به یکی از مهمترین چالشهای این مسیر بپردازیم: بدهی فنی. در دنیای مهندسی نرمافزار، بدهی فنی (Technical Debt) اغلب به عنوان کد شلخته…
سلام به همگی
اولین روز پاییزتون بخیر و شادی باشه🍂🍁
نیمساعت دیگه شروع میکنیم
اولین روز پاییزتون بخیر و شادی باشه🍂🍁
نیمساعت دیگه شروع میکنیم
❤2