ملخص سريع: العمارة النظيفة ، روبرت سي مارتن

ستكون هذه قصة عن انطباع الكتاب ، وكذلك بعض المفاهيم والمعرفة التي تمت دراستها ، بفضل هذا الكتاب

هندسة معمارية

هل تستطيع قراءة هذا المنشور إعطاء إجابة واضحة على السؤال ، ما هي الهندسة المعمارية؟ ما هي الهندسة المعمارية في سياق البرمجة والتصميم؟ ما هو الدور الذي تلعبه؟ هناك الكثير من الغموض في هذا المصطلح. ويبدو أن كل شيء واضح ، لكنه مجردة بطريقة ما ، وبدون دقة. يعتقد مارتن ، وأنا أتفق معه ، أن التطبيق يحتوي على عنصرين:

1. السلوك (السلوك) - الوظائف والمهام التي يؤديها البرنامج (المكون ، الخدمة).
2. الهندسة المعمارية - هذا المصطلح هو أكثر حول تغيير التطبيقات.

ولكن حتى لو كان التطبيق يؤدي المهمة التي يجب أن يؤديها بشكل جيد ، فإن هذا لا يعني على الإطلاق أن لديه بنية جيدة. العمارة ليست حول سلوك التطبيق. العمارة تدور حول سهولة التغيير ، العمارة تدور حول سهولة النشر ، العمارة تدور حول استقلال التنمية. العمارة تدور حول السرعة التي يصل بها الفهم لشخص جديد في الفريق

وإليك كيفية بناء هذه البنية ، وكيفية التخلص من الصداع مع حدوث تغيير طفيف في المتطلبات من PM ، أو من أحد أصحاب المصلحة: هذا ما سيقوله الكتاب.

عن المؤلفين

قبل أن أقول أي شيء عن هذا الكتاب ، أريد أن أقول القليل عن نفسي.
في الوقت الحالي ، أنا مطور قوي جديد متخصص في تطوير الخدمات من خلال ASP .NET CORE.

لقد كنت أعمل في "معرض" واحد منذ عام ، ويبدو أنني أقوم به قليلاً

لقد قرأت هذا الكتاب بالفعل مرتين ، وأوصي الجميع بقراءته:

• مطورو النظم المضمنة ؛
• endchikers الجبهة.
• دعم الظهر
• وحتى devopsam.

بشكل عام ، إلى أي شخص على الأقل يرتبط بطريقة ما بتطوير PP ، أعني التطوير المباشر لـ Saylov و PM'ov المختلفين هنا ، نحن لا نأخذ في الاعتبار هنا (على الرغم من أنه سيكون من المفيد أيضًا معرفة سبب قضاء الخادمة أحيانًا مرتين في مهمة) ، هذا الكتاب.
والآن سأحاول أن أفهم لماذا أعتقد ذلك

قليلا عن مؤلف هذا الكتاب (لأن بالنسبة لي سلطة الكاتب تلعب دورا كبيرا). أعتقد أنك سوف تفهمني ، على الرغم من أن هذا ليس صحيحًا دائمًا ، لكن إذا قال لك شخص موثوق في المجال شيئًا ما ، فأنت تبدي ثقة أكبر بما قاله. على سبيل المثال ، أعتقد أنك تفضل أن تؤمن بالتشخيص الذي يضعه الطبيب لك أكثر من شخص من الحشد (غوغل الأعراض)

يعمل روبرت مارتن - المعروف أيضًا باسم Ankle Bob (العم بوب) - في مجال البرمجة ، ومن أنظمة مختلفة (من خدمات الويب إلى أنظمة التضمين) ، منذ عام 1970. إنه مستشار فني ومهندس معماري ، وكتب في العديد من المجلات التقنية ، وهو مبرمج ذو خبرة كبيرة ، وشخص لعب دورًا رئيسيًا في إنشاء مبادئ SOLID المعروفة (يمكنك قول المبدع). وأريد أيضًا أن أضيف أن قائد فريقي الذي يتمتع بخبرة تزيد عن 15 عامًا نصحني بهذا الكتاب

عن الكتاب

اعتمادا على

قبل قراءة الكتاب ، قرأت الكثير من المقالات حول نفس حبري ، حيث ظهرت كلمة مثل "التبعية". ما هو ، من يعتمد على من ، ماذا يعني بالضبط "يعتمد على" ، وكيف يمكن أن تعتمد فئة ما على شخص ما؟

وعندما قرأت الكتاب ، تعلمت نقطتين:

التبعية هي مصطلح يعني أن بعض الفئات (مكون ، خدمة) تعرفها عن فئة أخرى (مكون ، خدمة) ، ويتم تحديد هذه المعرفة على مستوى الكود (الآن javists ، المبادرين ، سوف يفهمني الناس) عن طريق استيراد مساحة اسم معينة . بمعنى آخر: لديك فئة A مع مساحة اسم Default.Classes وفئة B Another.Classes. لذلك ، إذا ظهر رمز الفئة A باستخدام Another.Classes؛ - هذا يعني أن الفئة أ تعتمد على الفئة ب.
لفهم وفقًا للمخطط حيث تكون الفئة التابعة وأين لا - انظر إلى اتجاه السهم: 1) يشير السهم من الفئة A في اتجاه الفئة B. وهذا يعني أن الفئة B أكثر استقلالًا من الفئة A. والتغيرات في الفئة A ، لا "ضرر" للفئة ب

SOLID

أحد الأسباب الرئيسية لقراءة هذا الكتاب كان شرح مبادئ سوليد من المصدر الأصلي ، لأن العم روب طور هذه المبادئ ويمكننا القول أنه بفضله نسمع هذا الاسم - سوليد.
بالنسبة لأولئك الذين ليسوا على دراية - تُقال هذه المبادئ ويُنصح بتصميم تطبيقاتها وفقًا للقواعد الخمس:

S - SRP (مبدأ المسؤولية الفردية)
O - OCP (مبدأ مفتوح مغلق)
L - LSP (مبدأ استبدال Liskov)
I - ISP (مبدأ فصل الواجهة)
D - DIP (مبدأ انعكاس التبعية)

يمكن تطبيق كل هذه المبادئ على مستوى الفئات والأشياء ، وعلى مستوى الوحدات والمكونات ، وعلى مستوى القضبان (الخدمات).

إذا كنت تعتقد أن مبدأ المسؤولية الفردية يدور حول حقيقة أن الفصل ، أو الوحدة يجب أن تفعل شيئًا واحدًا فقط ، فعليك بالتأكيد قراءة الفصل الخاص بـ Solid على الأقل. لأن التعريف الوارد أعلاه هو نتيجة ، ولكن ليس تعريف المبدأ نفسه

حول انعكاس التبعية

أريد أن أهتم بشكل خاص بشرح مبدأ انعكاس التبعية (المبدأ الذي هو D من SOLID). أثناء قراءة الكتاب ، فهمت أن هذا ليس مجرد مبدأ ، بل هو أيضًا آلية وأداة يمكنك من خلالها تغيير اتجاه تبعياتك وجعل ، على سبيل المثال ، منطق الأعمال (DOMAIN) مستقلًا عن تفاصيل تطبيق طبقة الوصول إلى البيانات (DAL'a)



على الرغم من أن المبدأ نفسه مع الآخرين في SOLID يعني شيئًا آخر غير الآلية ، إلا أن الآلية نفسها تستخدم في جميع أنحاء الكتاب ، وهذه هي إحدى الطرق الرئيسية لعكس وتغيير اتجاه التبعيات الخاصة بك ، والتي يتم استخدامها بالمناسبة مع DDD

حول اتخاذ القرارات المعمارية

في كثير من الأحيان ، سوف يذكر الكتاب مبدأ اتخاذ القرارات المعمارية الهامة: أي قاعدة بيانات لاستخدامها ، وأي إطار لاستخدامها ، وأي مكتبة تتصل بها ، وماذا تستخدم كمحرك بحث ، إلخ.

لذلك ، يعتقد المؤلف: يجب عليك في اسرع وقت ممكن اتخاذ هذا النوع من القرار. نظرًا لأن المتطلبات يمكن أن تتغير ، وقيود الأداء أيضًا ، يميل العنصر السلوكي نفسه إلى التغيير. أثناء عملية التطوير ، قد يبدو بعض الحلول أقل فعالية من حل آخر ، وأقل ملاءمة من حل آخر. وستحدد قوة البنية الخاصة بك مدى السرعة وبدون ألم في إمكانية استبدال تقنية بأخرى (يقول OCP بالمناسبة).

على سبيل المثال ، فجأة ، قررت استخدام MongoDb بدلاً من Postgresql ، أو الملفات بشكل عام ، أو استخدام البيانات المستهزئة ، والعمليات التي سيتم تنفيذها في الذاكرة. وتحت ظروف معينة - قد يتيح ذلك إعادة كتابة كل المنطق تقريبًا.

لمنع مثل هذه الحالات ، يمكننا استخدام بعض الآليات التي ستدفع وقت اتخاذ القرار إلى أقصى حد ممكن. واحدة من هذه الآليات هي التجريد.

مراجع DDD

DDD - التصميم المستند إلى المجال - هو نهج لتطوير الخدمات ذات المنطق التجاري المعقد ، وهو أمر مهم للتغييرات ، والتي تهدف إلى زيادة فهم وظائف إدارة المشروع (PMs ، مديري المبيعات ، إلخ) ، مع التجديف. وهذا يعني أنه ستكون هناك لغة في كل مكان بين جميع أعضاء المشروع ، ويمكن للجميع فهم الآخر ، وأن كل شخص يفكر في نفس المجال بنفس قواعد العمل.

إذا كنت من مؤيدي DDD ، أو تريد أن تكون واحدًا ، أو أنك لا تفهم شيئًا حيال ذلك ، لكنك تريد أن تفهم ، فهذا الكتاب يجب قراءته ، خاصةً الجزء الثاني من الكتاب.

يوضح المؤلف هنا وجود قاعدة التبعية ، ولماذا بعد ذلك ، ستقوم ببناء بنية التطبيق الصحيحة. لماذا يجب أن تتبع التبعيات تجاه مكونات High Policy ، ولماذا يجب أن يكون المجال (مكون High Policy) مستقلًا عن البنية التحتية وكيف سيبسط النشر والتطوير لك

التلخيص

يتحدث Uncle Rob أيضًا عن الكيفية التي يمكن أن تضر بها تفاصيل التطبيق وتمنعه ​​من التطور دون ألم في المستقبل.

تذكر!
DB هي تفاصيل التنفيذ
العملاء (الويب ، الجوال ، إلخ) - تفاصيل التنفيذ
الأطر هي تفاصيل التنفيذ.

من الضروري الاستخلاص قدر الإمكان وعدم الاعتماد عليه ، وذلك باستخدام انعكاس التبعية الموصوف أعلاه مع الواجهات التجريدية وقاعدة التبعية والآليات الأخرى

طرق بناء الوحدات

أعجبني هذا القسم بشكل خاص كمطور خدمة على ASP .NET CORE. لأنه يصف منهجيات بناء بنية خدمة موحدة من مكونات جاهزة.

وصف روبرت 4 مخططات فصل طبقة محتملة.

لقد أوضح لماذا الآلية المستخدمة بشكل متكرر للهندسة ثلاثية الطبقات: UI (وحدات التحكم) ، الخدمات (المجال) ، DAL (قاعدة البيانات) - سيئة بما فيه الكفاية مقارنة بالآخرين. لم أر الكثير من المشاريع ، لكن في كل منها ، على سبيل المثال ، الخدمة المصغرة ، في النهاية الخلفية ، تستخدم بنية ثلاثية الطبقات.

أيضا ، في كثير من الأحيان ، يتم استخدام بنية خدمة مكون واحد. بشكل عام ، كلاهما ليس سيئًا ، ولكن لديه الكثير من العيوب ، على سبيل المثال ، على سبيل المثال ، كيف تم تصميم الهيكل باستخدام DDD ، خاصةً عندما تكون مهمة للتغيير ، والخدمات المعقدة.

بشكل عام ، انتهى هذا الاستعراض للكتاب. أحببت حقًا الكتاب نفسه ، ولا أشعر بالأسف لما قرأته ، بفضل المؤلف. شكرا لك على اهتمامكم ، أيها القراء الأعزاء ، لا تحكموا بصرامة - يعتمد هذا المنشور على انطباع الكتاب وحماسي الشخصية

تحديث 1.0

خلال المناقشات ، يمكن فهم أن التغيير في التخزين بسهولة والسهلة لن يكون سهلاً ، بطريقة أو بأخرى. في بعض الحالات ، حتى لو كانت عملية الوصول إلى المتجر أمرًا مؤلمًا للغاية ، ومع ذلك ، فمن المشكوك فيه ما الذي يجعل الموقف أسوأ ، ولكن أفضل قليلاً ، على الأقل بسبب استقلال المكون المتغير عن الآخرين.