Patterns of Enterprise Application Architecture(PoEAA) ฉบับย้อย่อ

เกริ่นนำ

สวัสดีครับวันนี้ ก็จะมาเล่าให้อ่านแบบย้อย่อ เรื่อง Patterns of Enterprise Application Architecture (PoEAA) เป็นการรวบรวมความรู้ด้านการออกแบบซอฟแวร์ระดับ Enterprise ของท่าน อาจารย์ Martins Fowler (2002) ผมอ่าน แล้วนำมาประยุกต์ใช้เอง บาง patterns ก็ถูกฝังรวมไว้กับ framework ที่เราใช้อยู่เป็นประจำ เช่น Java EE, Spring, Rails หรือ .NET Enterprise Library และบาง patterns ใช้เป็นโครงต้นแบบ สำหรับใช้ออกแบบ แล้วเขียน code สร้าง EA ตามเรื่องตามราวของเราออกมา เช่น DTO, Value Object, Domain Model

เอาละเรามาเริ่มอธิบายกันเลยว่า PoEAA มันคืออะไร

PoEAA มันคืออะไร 

ผมจะขอแยกอธิบายเป็น 3 คำ ดังนี้ครับ

Architecture ในที่นี้จะหมายถึง องค์ประกอบ หรือ โครงสร้าง รวมถึงสภาวะแวดล้อม ที่เกี่ยวข้องทั้งภายใน(context) และภายนอก(environment) ของ software application หรือ system ตัวอย่าง เช่น

OSI Layer ที่อธิบายสถาปัตยกรรมของเครื่อข่ายการสื่อสารข้อมูล ซึ่งจะแสดงสถาปัตยกรรมในลักษณะโครงสร้างที่แบ่งออกเป็น 7 layer

Computer Architecture แสดงสถาปัตยกรรมในลักษณะของ องค์ประกอบ และความสัมพันธ์ที่มันทำงานร่วมกัน เพื่อประมวลผลงานจาก program

Network Architecture แสดงองค์ประกอบของอุปกรณ์การสื่อสารข้อมูลเพื่อทำงานร่วมกัน ให้ได้เครือข่ายการสื่อสารข้อมูลตามต้องการ

Enterprise Application(EA) ในที่นี้จะเกี่ยวข้องกับ application ที่ต้องใช้ ข้อมูลที่ซับซ้อน มีปริมาณมาก, ต้องทำงานอยู่ภายใต้กฎ บทบาท กิจกรรม และเหตุผลทางด้านธุรกิจ, มีผู้ใช้เป็นปริมาณมาก หลากหลาย client หลากหลาย device และ ต้องทำงานร่วมกับระบบอื่นๆ ทั้งภายใน และภายนอกด้วย

Software Application อะไรบ้างที่เป็น EA: Payroll, Patient Records, Shipping Tracking, Cost Analysis, Credit Scoring, Insurance, Supply Chain, Accounting, Customer Service, Foreign Exchange Trading

Software Application เหล่านี้ไม่ใช่  EA: Automobile Fuel Injection, Word Processors, Elevator Controllers, Chemical Plant Controllers, Telephone Switches, Operating Systems, Compilers, Games Console(offline)

Patterns  คือ แบบแผนหรือรูปแบบในการใช้แก้ไขปัญหาที่เกิดขึ้นเสมอๆจนเราเข้าใจลักษณะพฤติกรรม และความสัมพันธ์ของสิ่งต่างๆที่อยู่ในบริบทของปัญหาเฉพาะหนึ่ง จนได้รูปแบบที่เป็นต้นแบบสำหรับแก้ปัญหาเฉพาะนี้ออกมา แล้วเราสามารถนำรูปแบบนี้นำกลับมาใช้ใหม่ เพื่อแก้ปัญหาเฉพาะที่มีลักษณะคล้ายๆกันนี้ต่อได้ โดยอาจจะไม่จำเป็นต้องใช้รูปแบบเหมือน patterns ต้นแบบ เพียงแต่ใช้รูปแบบเป็นโครงเพื่อการออกแบบ แล้วแมพสิ่งต่างๆในบริบทของปัญหาให้เข้ากับต้นแบบนี้เท่านั้น ปัญหาก็จะสามารถแก้ไขได้โดยง่ายเมื่อเราประยุกต์ใช้ patterns เดียวกับที่เคยใช้แก้ปัญหาแบบเดียวกันนี้ได้มาก่อน

เมื่อเข้าใจความหมายของทั้ง 3 คำแล้ว เราก็จะเข้าใจความหมายของ PoEAA ไปโดยปริยาย มันก็คือ รูปแบบเพื่อออกแบบสำหรับ สถาปัตยกรรมของ Enterprise Application นั้นเองครับ

EA มีปัญหาอะไรละถึงได้เกิด Patterns ขึ้นมาช่วยได้

จาก application ตัวอย่าง และประสบการณ์ของเราเอง ก็พอจะทำให้เรามองเห็นปัญหาของ EA ได้บ้างนะครับ ปัญหาปกติที่ EA จะต้องเผชิญ ก็คือ

การคงรักษาไว้ของข้อมูล เพราะ EA ต้องทำงานร่วมกันจึงต้องมีการเก็บ และดึงข้อมูลขึ้นมาใช้ในภายหลังเมื่อไรก็ได้ที่ต้องการ
Persistent data
ข้อมูลจำนวนมาก เพราะ EA เป็นปัญหาทางด้านธุรกิจ ที่ต้องการข้อมูลเชิงประวัติศาสตร์ เพื่อใช้ดูย้อนหลัง หรือใช้วิเคราะห์เชิงสถิติ การออกรายงานรายวัน รายไตรมาส หรือรายปี เยอะครับข้อมูลที่ EA ต้องการ
A lot of data
การเข้าใช้ข้อมูลพร้อมๆกัน เพราะ EA ต้องทำงานร่วมกับผู้ใช้มากมาย กับระบบภายนอกอื่นๆที่มากมายด้วย ปัญหาการเข้าถึงข้อมูล หรือทรัพยากรภายใน EA พร้อมๆกันจึงเกิดขึ้น
Access data concurrently
ส่วนประสานงานกับผู้ใช้(UI) จำนวนมาก เพราะ EA มาจากผู้ใช้หลากหลาย ที่ต้องการข้อมูลที่หลากหลาย ซับซ้อน จึงทำให้เกิด UI screen สำหรับจัดการข้อมูลมากมาย ที่จะต้องสามารถจัดการข้อมูลที่ซับซ้อนด้วย ดังนั้น UI จึงเป็นปัญหาสำคัญที่จะต้องการ แนวทางออกแบบเพื่อจัดการ UI ให้ง่ายขึ้นด้วย
A lot of user interface screens
การบูรณาการกับระบบอื่นๆ เพราะ EA มีความต้องการจากหลากหลายภาคธุรกิจ หลากหลายบริบทของธุรกิจ จึงต้องมีความสัมพันธ์กันแน่นอน เช่น ฝ่ายขายต้อง ส่งข้อมูลสั่งซื้อ ไปยังผ่ายจัดซื้อ ฝ่ายจัดซื้อต้องส่งข้อมูลนี้ต่อไปยัง ฝ่ายคลังเพื่อเบิกสินค้า แล้วส่งไปยังฝ่ายจัดส่งสินค้าเพื่อส่งไปยังลูกค้า เป็นต้น EA ไม่ได้อยู่โดดเดี่ยวแน่นอน
Integrate with other System
ความซับซ้อนของธุรกิจ เพราะ EA คือ application สำหรับธุรกิจ แน่นอนเกี่ยวข้องกับกฎหมาย พฤติกรรม และกิจกรรมทางธุรกิจของมนุษย์  มันจึงมีความไม่คงที่แน่นอนมันเปลี่ยนแปลงไปตามสภาวะแวดล้อมทางสังคม นวัตกรรม และการแข่งขันทางธุรกิจ รูปข้างล่างนี้แสดง enterprise application ขององค์ความรู้ด้าน Game Online ที่ถูกจัดระเบียบให้ไปบรรจุอยู่ในพื้นที่ต่างๆตามหน้าที่ของมันแล้ว
Complex business

จากปัญหาข้างต้นนั้น ทำให้เกิดการเรียนรู้ ทำความเข้าใจ และลงมือทำ จนกระทั่งทำให้เกิดเป็น Patterns ของ EA ขึ้นมา เอาละ ก่อนจะไปรู้จัก Patterns เหล่านั้นกัน เราะจะวางโครงสร้างของ EA กันก่อน โดยจะแบ่ง EA ออกเป็น 3 layer การให้ layer นี้อาจเรียกได้ว่า เราออกแบบ สถาปัตยกรรมของ EA  ที่แบ่งออกมาได้เป็น 3 layer ดังนี้

3 Layer Architecture of EA

อธิบาย 3 Layer Architecture ของ EA

Presentation Layer: เกี่ยวข้องกับส่วนที่ทำหน้าที่นำเสนอต่อประสานกับผู้ใช้จากภายนอก หากเป็นผู้ใช้ที่เป็นบุคคล ก็จะเป็นเรื่องของการแสดงส่วนต่อประสานที่เป็นหน้าจอเพื่อควบคุณผู้ใช้ให้ทำงานกับ EA ได้สะดวก เช่น HTML หรือเมื่อเป็นระบบอื่น ส่วนต่อประสานผู้ใช้ก็จะอยู่ในรูปแบบอื่นเช่น XML, JSON, Binary เป็นต้น ขึ้นอยู่กับการตกลงกันระหว่างผู้ใช้ หรือผู้บริโภคข้อมูล กับผู้ให้บริการ

Domain Layer: เกี่ยวข้องกับส่วนที่ทำหน้าที่เก็บความหมาย กิจกรรม พฤติกรรม กฏเกณ ความสัมพันธ์ หรือจะเรียกว่าเป็นพื้นที่บรรจุองค์ความรู้ของสิ่งต่างๆ ที่มีส่วนเกี่ยวข้องกันไว้ ภายในขอบเขตพื้นที่ของบริบทเฉพาะหนึ่งที่เราสนใจอยู่ สำหรับ EA พื้นที่ของบริบทก็จะมีขอบเขตอยู่ในเรื่องของธุรกิจ หรือเศรษฐกิจ หรือ Business model หนึ่งเท่านั้น

Data Source Layer: เกี่ยวข้องกับการบริหารจัดการเพื่อเข้าถึงการใช้ทรัพยากรที่จำเป็น สำหรับ EA เกือบทั้งหมดของทรัพยกรที่ EA ต้องการคือข้อมูล ที่ถูกบรรจุอยู่ใน Relational Database

โดยการแบ่ง layer ออกเป็น 3 ส่วนนี้ ช่วยให้เราจัดการปัญหา อันได้แก่ การคงรักษาไว้ของข้อมูล และมีปริมาณมาก ซึ่งจะถูกจัดการ และบรรจุไว้ในชั้นของ Data Source,  การจัดการเรื่องของ UI การนำเสนอสารสนเทศ จะบรรจุมันไว้ในชั้นของ Presentation และ องค์ความรู้ทั้งหมดของธุรกิจ Business model จะบรรจุมันไว้ในชั้นของ Domain และในปัญหาอื่นๆ ที่เหลือ จะอยู่ในระดับกรอบนอกครับ นั่นคือตัว Application หรือ Application Server(ตัวอย่าง App Server เช่น Apache, IIS, Glassfish, Websphere) ที่จะบรรจุ Enterprise ลงไปเพื่อนำองค์ประกอบทั้ง 3 layer นั้นมาประกอบเข้าด้วยกัน เพื่อทำงานได้อย่างถูกต้อง ปลอดภัย และมีประสิทธิภาพอีกทีหนึ่ง ซึ่งมันจะต้องควบคุมจัดการ และ configuration สภาวะแวดล้อมทั้งหมดจนสามารถเริ่มต้นประมวลผล programe EA ที่สมบูรณ์พร้อมให้บริการได้ ปัญหาของ Application Server ก็จะถูกแยกออกมาได้อีก 3 patterns ก็คือ

Concurrency Patterns ที่ใช้แก้ปัญหาเรื่อง การเข้าใช้ทรัพยากรพร้อมๆกันเพราะผู้ใช้มีปริมาณมาก มาจากหลากหลายธุรกรรมทางธุรกิจ

Distribution Patterns ที่ใช้แก้ปัญหาการบูรณาการกับระบบอื่นๆ หรือการทำงานร่วมกันกับระบบ EA อื่นๆที่อยู่ ต่างเครื่องกันออกไป(remote)

Session State Patterns ที่ใช้แก้ไขปัญหาที่เกี่ยวข้องกับสถานะข้อมูล และพฤติกรรม หรือทำธุรกรรมทางธุรกิจต่างๆ ของแต่ละผู้ใช้ใภายใน session หนึ่ง

ซึ่งก็จะครบทุกๆ patterns ที่ใช้จัดการกับปัญหาใน EA ทั้งหมดได้ ต่อไปเราจะไปดู patterns สำหรับแต่ละ Layer กันก่อน

Patterns ช่วยแก้ปัญหาในระดับ Enterprise 

ตามที่ได้เกริ่นไปเบื้องต้นแล้ว เราได้ แตกปัญหาของ Enterprise ออกเป็น 3 ส่วน ซึ่งในแต่ละส่วนก็จะมี Patterns สำหรับจัดระเบียบโครงสร้างให้มีรูปแบบที่เป็นระเบียบ แบ่งหน้าที่กันอย่างชัดเจน ที่จะทำให้การค้นหา ทำความเข้าใจ เพื่อจัดการแก้ไข ต่อเติมได้สะดวก และง่ายขึ้นในภายหลัง ได้ดังนี้

Presentation Patterns สำหรับ presentation layer นี้มีความซับซ้อนพอสมควร เราจึงแตกหน้าที่ของมันออกมาได้เป็น 3 ส่วนหลัก ซึ่งวิธีการแตกนั้นไม่ได้เอามาจากที่ไหน แต่เอามาจาก Model View Controller นั่นเอง แต่เพื่อให้ดีขึ้นเราต้องการให้ Model และ View ของเรานั้นอิสระกันไปเลย ก็จะใช้ Application Controller ในส่วนของ presentation นี้จะมี patterns เพื่อจัดการ View กับ Controller แยกออกไป ส่วน Model นั้นจะถูกจัดการในส่วนของ Domain Layer ก็ขึ้นอยู่ว่าเราเลือก patterns อะไรมาใช้ สำหรับ View patterns ประกอบไปด้วย 3 patterns ได้แก่ Transform View และ Template View ทั้งสองนี้เป็นแบบ 1 step และแบบพิเศษออกไปก็คือ Two Step View ซึ่งจะแบ่งขั้นตอนการสร้าง UI เป็น 2 step สำหรับส่วนของ Controller นั้นจะเป็นส่วนที่คอยจัดการ input ที่ request มาจากผู้ใช้เลยก็ว่าได้จึงเรียกได้ว่า Input Controller ซึ่งมี patterns ที่อยู่ในส่วนนี้ 2 แบบได้แก่ Page Controller กับ Front Controller ซึ่งตัวอย่างของ Framework ที่ใช้ Page Controller ก็เช่น PHP, JSP, ASP ส่วนตัวอย่างของ Framework ที่ใช้ Front Controller ก็เช่น Struts, Rails, ASP.NET MVC

Domain Patterns ส่วนของ domain layer จะเป็นเรื่องเกี่ยวกับการจัดการโครงสร้างของ logic ความสัมพันธ์ และสิ่งต่างๆใน domain ของเรา จะมี 3 patterns ได้แก่ Transaction ScriptDomain Model และ Table Module ที่ layer นี้ยังมีการแบ่ง layer ออกมาอีกเพื่อให้ชั้นของ Presentation สะดวก และจัดการได้ง่ายขึ้นในการประสานงานกับ domain logic ดังนั้น จึงแบ่ง Domain Layer นี้ออกมาอีกชั้นหนึ่ง เป็น Service Layer

สำหรับวิธีการเลือกว่าเราจะเลือก Patterns อะไร จัดระเบียบ domain logic ของเรานั้น ดูจากภาพข้างล่างนี้เพื่อตัดสินใจครับ โดย แกนนอนแสดงความซับซ้อนของ domain logic และ แกนตั้งแทนระดับความพยายาม หรือแทนต้นทุนทั้งหมดที่เราจะต้องเสียไป เพื่อแก้ไข เปลี่ยนแปลง ต่อเติม domain logic ของเราให้ตอบสนองความต้องการที่มีความซับซ้อนเพิ่มขึ้นอย่างต่อเนื่อง

DomainPatternsEffort

Data Source Patterns ในชั้นนี้จะเป็น patterns ที่เกี่ยวของกับการเชื่อมต่อไปยัง relational database เพราะเกือบทั้งหมดของ EA ใช้ Data Source ที่เป็น relational database สถาปัตยกรรมในการออกแบบการเข้าถึง database มีอยู่ 4 รูปแบบ ได้แก่ Table Data GatewayRow Data GatewayActive Record และ Data Mapper ซึ่ง Data Mapper นั้นจะมีความซับซ้อนมากกว่าแบบอื่น เพราะต้องจัดการ mapping ระหว่าง Domain Model ที่อยู่บน memory กับ row ใน table ของ relational database จึงมี pattern เพื่อเข้ามาช่วยออกแบบการ mapping ตรงนี้ กับพฤติกรรมในขณะที่จะเขียนหรืออ่าน object ที่อยู่บน memory เหล่านี้กลับไปยัง table เพื่อเก็บไว้หรืออ่านขึ้นมาอีกครั้ง คือ รูปแบบที่จัดการเกี่ยวกับพฤติกรรมการ เขียน หรืออ่าน ระหว่าง Domain Model กับ relational database ได้แก่ Unit of Work, Identity Map และ  Lazy Load แล้วเมื่อต้องการจัดการเกี่ยวกับการ mapping จะแบ่งออกเป็น 2 กลุ่มคือ กลุ่มที่เกี่ยวกับความสัมพันธ์ ได้แก่ Identity Field, Foreign Key Mapping และ Association Table Mapping อีกกลุ่มเกี่ยวกับการสืบทอดของ Domain Model ได้แก่ Single Table Inheritance, Concrete Table Inheritance  และ Class Table Inheritance ต่อจากนั้นก็เป็นเรื่องของการที่เก็บรายละเอียดเกี่ยวกับการ mapping ซึ่งจะใช้ Metadata Mapping บรรจุรายละเอียดของการ map ทั้งหมดไว้ จึงทำให้สามารถใช้ Query Object เพื่อ query object ต่างๆได้โดยไม่ต้องรู้จักชนิดของ Data Source เลย และ patterns สุดท้าย Repository ทำให้ Domain ไม่ต้องสนใจว่า objects เหล่านั้นมาจาก Data Source บน memory หรือบน table space โดยที่ชั้นของ Domain สามารถเรียกใช้ผ่าน Repository ที่มี interface เป็น collection ของ Domain Model ธรรมดาเท่านั้น

หลังจากรู้จัก patterns ใน layer ต่างๆของ Enterprise แล้ว ยังมีปัญหาในส่วนของ Application ที่จะต้องมีกระบวนการ ที่คอยจัดการควบคุมเพื่อให้ผู้ใช้เข้าใช้องค์ประกอบต่างๆของ Enterprise ได้อย่างถูกต้อง และมีประสิทธิภาพ ได้แก่ ปัญหาด้าน Concurrency, การจัดการดูแล State และ การทำงานร่วมกันขององค์ประกอบที่ Distribution ซึ่งมี patterns เพื่อใช้แก้ปัญหาเหล่านั้น ตามลำดับต่อไปนี้

Patterns ช่วยแก้ปัญหาในระดับ Application Server

Concurrency เนื่องจาก EA มีธุรกรรมทางธุรกิจที่เกิดขึ้นพร้อมๆกันมากมายและยาวนาน การควบคุม transaction โดยใช้ relational database ของระบบนั้น ทำได้ไม่ดีพอและมีความเสี่ยงในการเปิด transaction ที่ยาวนานเพื่อควบคุม ธุรกรรมทางธุรกิจที่ต่อเนื่องกันใน relational database ที่มีหลายๆระบบแชร์ร่วมกันใช้ Data Source อยู่ ดังนั้นจึงมีการแตกธุรกรรมทางธุรกิจออกมาเป็นชิ้นเล็กๆเพื่อทำให้การควบคุมธุรกรรมจากระบบ relational database นั้นสั้นลง จึงทำให้เกิดเปัญหาที่เรียกว่า Offline Concurrency ซึ่งนำไปสู่รูปแบบวิธีการจัดการปัญหานี้ มีอยู่ 2 รูปแบบคือ Optimistic Offline Lock กับ Pessimistic Offline Lock จากสองรูปแบบนี้นำไปประยุกต์ใช้กับกลุ่มของ objects ที่เรียกว่า Coarse-Grained Lock หรือ จะซ่อนความซับซ้อนเพื่อทำให้นักพัฒนาสามารถ จัดการ Concurrency ได้โดยง่ายด้วย  Implicit Lock

Session State เป็นการจัดการ State ของผู้ใช้ที่เข้าใช้ EA ในขณะ session หนึ่งๆ State จะบรรจุข้อมูล และกิจกรรม หรือ transaction ทั้งหมดของผู้ใช้ในขณะ session นั้นซึ่งจะสนใจเฉพาะที่จำเป็นต้องเก็บ State ไว้ที่เรียกว่า statefull เท่านั้น patterns ที่ใช้แก้ปัญหา Session State ได้แก่ Client Session State, Server Session State และ Database Session State

Distribution เป็นปัญหาของการทำงานร่วมกันระหว่าง EA กับระบบอื่นๆภายนอกที่อยู่ต่างเครื่องกัน การติดต่อกันตรงนี้เรียกว่า remote มี patterns ที่ช่วยแก้ปัญหาตรงนี้อยู่ 2 patterns ได้แก่ Remote Facade กับ Data Transfer Object โดยที่ Remote Facade จะสร้าง interface ใหม่ที่เหมาะสม และเพิ่มประสิทธิภาพ ให้กับการบริการแบบ remote คือการทำงานระยะห่างกันนั้นมีต้นทุนที่สูงในขั้นตอนการเชื่อมต่อกว่าการทำงานบนเครื่องเดียวกัน ส่วน Data Transfer Object(DTO) นั้นจะสร้าง objects หนึ่งขึ้นมาเพื่อบรรจุสิ่งที่จำเป็นทุกอย่างไว้ก้อนเดียวกัน โดยไม่สนใจความสัมพันธ์หรือลำดับการสืบทอดของ objects เลย ซึ่งจะทำให้การเรียกบริการแบบ remote นั้นน้อยครั้งลงให้มากที่สุดได้

ก่อนจะจบไปดู patterns ที่เป็นต้นแบบ หรือใช้เป็นมูลฐานสำหรับให้ patterns อื่นๆทำไปใช้ประโยชน์ได้

Base Patterns

Gateway ช่วยให้ติดต่อกับระบบภายนอกง่ายๆด้วยช่องทางเดียว

Mapper เป็นตัวกลางสำหรับสร้างข้อมูลเพื่อใช้สื่อสารกันระหว่างสองระบบที่อิสระกันอยู่ หรือต้องการให้มันอิสระกัน

Layer Supertype เป็น type ที่กำหนดให้เป็น supertype ของทุกๆ type ใน layer นั้น

Separated Interface กำหนด interface แล้วแยก package หรือ module ส่วนที่เป็น implementation ของ interface นั้นออกมา

Registry เป็นบริการที่ประกาศไว้ให้ objects ใดๆสามารถค้นหา objects หรือ บริการ ที่ต้องการได้

Value Object เป็น objects ชนิดหนึ่งที่เราไม่สนใจติดตามพฤติกรรม แต่สนใจค่าของมันเท่านั้น เราจึงไม่จำเป็นต้องกำหนด ID

Money ใช้แทนความหมายของเงิน บรรจุสถานะเป็นจำนวนเงิน และสกุลเงิน ไว้ด้วย

Special Case เป็น subclass ที่มีพฤติกรรมพิเศษ หรือแตกต่างออกไปจาก baseclass ไว้สำหรับกรณีเฉพาะ

Plugin ถอดแล้วเสียบองค์ประกอบที่ขึ้นต่อกัน ด้วยการแก้ไข configuration ได้โดยไม่ต้อง compile code ใหม่

Service Stub ช่วยเอาบริการอื่นๆที่เกี่ยวข้องออกไปจาก objects ที่เราสนใจอยู่ ทำให้ไม่ติด หรือเสี่ยงต่อปัญหาในระหว่างการทดสอบ หรือให้ objects ภายใต้การทดสอบนี้ isolation จากบริการอื่นๆภายนอกที่มันขึ้นต่อกันอยู่ได้

Record Set จะแสดงความหมายของข้อมูล ที่มีโครงสร้างเหมือน table ไว้ใน memory ได้ ตัวอย่างเช่น DataSet ของ .NET, ResultSet ของ JAVA

ผมได้สรุปออกมาเป็น Mine Map ตามภาพข้างล่างนี้ครับ

MineMap_PoEAA

ก็ขอเล่าเรื่อง Patterns of Enterprise Application Architecture(PoEAA) ฉบับย้อย่อ ไว้เพียงเท่านี้ ไม่รู้ว่ายาวไปหรือเปล่า หรือว่าย่อเกินไปจนอ่านไม่รู้เรื่อง อย่างไรก็แล้วแต่ เขียนมาถาม ตอบ แนะนำติชมกันได้นะครับ

ขอบคุณครับ
#:P
Advertisements

#agile-software-development, #design, #design-patterns