ﻣﻘﺪﻣﻪ

ﺍﮔﺮ ﭘﻴﺎﺯﻱ ﺭﺍ ﭘﻮﺳﺖ ﺑﮕﻴﺮﻳﺪ ﻣﻄﻤﺌﻨﺎ ﺍﺷﻚ ﺷﻤﺎ ﺭﺍ ﺩﺭﺧﻮﺍﻫﺪ ﺁﻭﺭﺩ ﺍﻟﺒﺘﻪ ﻧﮕﺮﺍﻥ ﻧﺒﺎﺷﺪ ﻗﺮﺍﺭ ﻧﻴﺴﺖ ﺑﺎ ﻳﺎﺩ ﮔﺮﻓﺘﻦ ﺍﻳﻦ pattern ﺍﺷﻚ ﺷﻤﺎ ﺩﺭﺑﻴﺎﺩ ﺑﺮ ﻋﻜﺲ ﻗﺮﺍﺭﺍﺳــﺖ ﺍﺷــﻚ ﻣﺴــﺎﺋﻠﻲ ﺭﺍ ﻛﻪ ﺑﺎ ﺍﻳﻦ ﭘﻴﺎﺯ ﻗﺎﺑﻞ ﺣﻞ ﻫﺴــﺘﻨﺪ ﺭﺍ ﺩﺭﺁﻭﺭﻳﻢ ﺍﺯ ﻧﻈﺮﻣﻦ ﻫﺮ ﺭﺍﻩ ﺣﻠﻲ ﺑﺮﺍﻱ ﻫﺮ ﻣﺴــﻠﻪ ﺍﻱ ﻣﻨﺎﺳـﺐ ﻧﻴﺴـﺖ ﻭ ﻫﺮ ﻣﺴـﺌﻠﻪ ﺍﻱ ﺑﺎ ﺭﺍﻩ ﺣﻞ ﻣﺨﺼـﻮﺹ ﺧﻮﺩ ﻗﺎﺑﻞ ﺍﻧﺠﺎﻡ ﺩﺍﺩﻥ ﺍﺳـﺖ ﺍﻟﺒﺘﻪ ﺑﺮﺍﻱ ﺣﻞ ﻳﻚ ﻣﺴـﺌﻠﻪ ﺷـﻨﺎﺧﺖ ﺩﻗﻴﻖ ﺩﺍﻣﻨﻪ ﻭ ﻧﻴﺎﺯﻣﻨﺪﻫﺎﻱ ﺁﻥ ﺍﺑﺘﺪﺍﻳﻲ ﺗﺮﻳﻦ ﻗﺪﻡ ﺍ ﺳﺖ ﭼﺮﺍ ﻛﻪ ﻫﺮ ﭼﻘﺪﺭ ﺷﻨﺎﺧﺖ ﺷﻤﺎ ﻛﺎﻓﻲ ﺗﺮ ﻭ ﺩﻗﻴﻖ ﺗﺮ ﺑﺎ ﺷﺪ ﻗﻄﻌﺎ ﺭﺍﻩ ﺣﻠﻲ ﺭﺍ ﻛﻪ ﺍﻧﺘﺨﺎﺏ ﺧﻮﺍﻫﻴﺪ ﻛﺮﺩ ﺩﻗﻴﻖ ﺗﺮ ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﻫﺮ ﭼﻘﺪﺭ ﺍﻳﻦ ﺷــﻨﺎﺧﺖ ﻧﺎﻛﺎﻓﻲ ﺗﺮ ﺑﺎﺷــﺪ ﻫﺰﻳﻨﻪ ﻛﻪ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﺗﻐﻴﻴﺮ ﭘﺮﺩﺍﺧﺖ ﺧﻮﺍﻫﻴﺪ ﻛﺮﺩ ﺑﻴﺸــﺘﺮ ﻭ ﺑﻴﺸــﺘﺮ ﺧﻮﺍﻫﺪ ﺑﻮﺩ.ﺑﻨﺎﺑﺮﺍﻳﻦ ﺍﻳﻦ ﭘﻴﺎﺯ ﺑﺮﺍﻱ ﻃﺒﺦ ﻫﺮ ﻏﺬﺍﻳﻲ ﻣﻨﺎﺳﺐ ﻧﺨﻮﺍﻫﺪ ﺑﻮﺩ.

ﺩﺭ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﺳﻌﻲ ﺷﺪﻩ ﺍﺳﺖ ﻛﻪ ﺍﺑﺘﺪﺍ ﺑﺎ ﺑﺮﺭﺳﻲ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﺍﻱ ،ﻭ ﺷﻨﺎﺧﺖ ﻣﻌﺎﻳﺐ ﻭ ﻣﺸﻜﻼﺕ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ، ﺩﺭ ﭘﻲ ﺍﺭﺍﺋﻪ ﺭﺍﻩ ﺣﻠﻲ ﺩﻳﮕﺮ ﻭ ﻃﺮﺣﻲ ﻧﻮﻱ ﺩﻳﮕﺮﻱ ﺑﺎﺷﻴﻢ ﻭ ﺑﻪ ﻣﻌﺮﻓﻲ ﻣﻌﻤﺎﺭﻱ ﭘﻴﺎﺯﻱ ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ ﺑﻪ ﻧﻘﺎﻁ ﻗﻮﺕ ﻭ ﺿﻌﻒ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺧﻮﺍﻫﻢ ﭘﺮﺩﺍﺧﺖ.

ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﺍﻱ

ﺗﺎ ﺯﻣﺎﻧﻬﺎﻱ ﻃﻮﻻﻧﻲ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﺍﻱ ﻛﻪ ﺑﺎ ﺍﻟﻬﺎﻡ ﺍﺯ ﺍﺳــﺘﻨﺎﺩﺍﺭﺩ ﺟﻬﺎﻧﻲ OSI 7 – Layer ﺩﺭ ﻛﺘﺎﺏ Pattern-oriented Software Architecture ﻣﻄﺮﺡ ﺷﺪ ﺷﺎﻳﺪ ﺍﻳﺪﻩ ﺁﻝ ﺗﺮﻳﻦ ﮔﺰﻳﻨﻪ ﺑﺮﺍﻱ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻭ ﭼﺎﺭﭼﻮﺏ ﺩﻫﻲ ﺑﻪ ﻛﻼﺱ ﻭ ﻣﺎﮊﻭﻝ ﻫﺎﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺧﻮﺩ ﻣﻲ ﺩﻳﺪﻡ ﺍﻣﺎ ﺑﺎ ﭘﻴﭽﻴﺪﻩ ﺗﺮ ﺷــﺪﻥ ﻣﺴــﺎﺋﻞ ﻧﻴﺎﺯ ﺑﻪ ﺭﺍﺣﻞ ﻫﺎﻱ ﺟﺪﻳﺪﺗﺮﻱ ﻣﻄﺮﺡ ﺷــﺪ. ﺩﺭ ﺍﺩﺍﻣﻪ ﻫﻤﭽﻨﻴﻦ ﺑﻪ ﺍﺷــﺘﺒﺎﻩ ﺭﺍﻳﺠﻲ ﻛﻪ ﺑﻴﻦ ﺩﻭ ﻣﻔﻬﻮﻡ Layer ﻭ tire ﺑﻪ ﻭﺟﻮﺩ ﻣﻲ ﺁﻳﺪ ﻧﻴﺰ ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ.

ﺗﺎﺭﻳﺨﭽﻪ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﺍﻱ

ﺩﺭ ﺳﺎﻝ 1996 ﭼﻨﺪ ﺗﻦ ﺍﺯ ﻣﻬﻨﺪﺳﻴﻦ ﺑﺎ ﻧﺎﻡ Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad Michael Stal ﺑﻪ ﺩﻧﺒﺎﻝ ﺍﻟﮕﻮ ﻫﺎﻱ ﺑﻮﺩﻥ ﻛﻪ ﺑﺘﻮﺍﻧﻨﺪ ﺗﻮ ﺳﻂ ﺁﻧﻬﺎ ﺍﺟﺰﺍء ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺭﺍ ﺑ ﺼﻮﺭﺕ ﺣ ﺴﺎﺏ ﺷﺪﻩ ﺍﻱ ﻛﻨﺎﺭ ﻫﻢ ﻗﺮﺍﺭ ﺩﻫﻨﺪ ﺗﺎ ﺍﺯ ﺑﻪ ﻭﺟﻮﺩ ﺁﻣﺪﻥ ﻳﻚ ﻣﺎﻛﺎﺭﻭﻧﻲ ﺍ ﺳﺎ ﺳﻲ ﺍﺯ ﻛﺪﻫﺎ ﺟﻠﻮﮔﻴﺮ ﻛﻨﺪ ﺩﺭ ﻧﻬﺎﻳﺖ ﻧﺘﻴﺠﻪ ﺗﺤﻘﻴﻘﺎﺕ ﺧﻮﺩ ﺭﺍ ﺩﺭ ﻛﺘﺎﺑﻲ ﺑﻪ ﻧﺎﻡ Pattern-oriented Software Architecture ﻣﻄﺮﺡ ﻛﺮﺩﻧﺪ.ﺩﺭ ﺍﻳﻦ ﻛﺘﺎﺏ ﺍﻟﮕﻮﻱ ﺑﻪ ﻧﺎﻡ N-layer ﺭﺍ ﻣﻄﺮﺡ ﻛﺮﺩﻥ ﻛﻪ ﺑﺮﺍﺳﺎﺱ ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ISO 7 ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺗﻮﺳﻂ ﺳﺎﺯﻣﺎﻥ ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ﺑﻴﻦ ﺍﻟﻠﻤﻠﻲ ﺍﻟﻬﺎﻡ ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﺑﻮﺩ.

ﺗﻌﺮﻳﻒ ﻣﺪﻝ ﻻﻳﻪ ﺍﻱ

ﺩﺭ ﺍﻳﻦ ﻣﺪﻝ ﭘﻴﭽﺪﻳﮕﻲ ﻫﺎﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺭﺍ ﺑﻪ ﻻﻳﻪ ﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺗﻘﺴــﻴﻢ ﻛﺮﺩﻩ ﻭ ﺩﺭ ﻫﺮ ﻻﻳﻪ ﺑﺨﺸــﻲ ﺍﺯ ﺍﻳﻦ ﭘﻴﭽﻴﺪﮔﻲ ﻫﺎ ﺭﺍ ﻣﺪﻳﺮﻳﺖ ﻛﺮﺩﻩ .ﺍﻳﻦ ﻻﻳﻪ ﻣﺎﻧﻨﺪ ﻻﻳﻪ ﻫﺎﻱ ﻛﻴﻚ ﺑﺮ ﺭﻭﻱ ﻫﻢ ﻗﺮﺍﺭ ﻣﻲ ﮔﻴﺮﻧﺪ.ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻫﺮ ﻻﺑﻪ ﻣﺠﺎﺯ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻻﻳﻪ ﺯﻳﺮﻳﻦ ﺧﻮﺩ ﻣﻲ ﺑﺎﺷﺪ ﻭ ﺍﺯ ﺳــﺮﻭﻳﺲ ﻫﺎﻱ ﻛﻪ ﻻﻳﻪ ﺯﻳﺮﻳﻦ ﺍﺭﺍﺋﻪ ﻣﻲ ﺩﻫﺪ ﻣﻲ ﺗﻮﺍﻧﺪ ﺍﺳــﺘﻔﺎﺩﻩ ﻛﻨﺪ ﺑﻪ ﺍﻳﻦ ﺭﻭﻳﻜﺮﺩ strict layering ﻣﻲ ﮔﻮﻳﻨﺪﺍﻟﺒﺘﻪ ﺩﺭ ﻣﻘﺎﺑﻞ flexible layer ﻣﺤﺪﻭﺩﻳﺖ ﻛﻤﺘﺮﻱ ﺑﺒﻴﻦ ﻻﻳﻪ ﻫﺎ ﺩﺍﺭﺩ ﻭ ﻫﺮ ﻻﻳﻪ ﻣﻲ ﺗﻮﺍﻧﺪ ﺍﺯ ﺳــﺮﻭﻳﺲ ﻻﻳﻪ ﻫﺎﻱ ﺯﻳﺮﻳﻦ ﺧﻮﺩ ﺁﺯﺍﺩﻧﻪ ﺍﺳــﺘﻔﺎﺩﻩ ﻛﻨﺪ ﺍﻳﻦ ﺑﺎﻋﺚ ﻣﻲ ﺷﻮﺩ ﻛﻪ ﺷﻤﺎ ﺍﻧﻌﻄﺎﻑ ﺑﻴﺸﺘﺮﻱ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﻦ ﻭ ﻫﻤﭽﻨﻴﻦ performance ﺑﻴﺸﺘﺮﻱ ﻫﺮ ﭼﻨﺪ ﺩﺭ ﺯﻣﺎﻥ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻛﺎﺭ ﺳﺨﺘﻲ ﭘﻴﺶ ﺭﻭ ﺧﻮﺍﻫﻴﺪ ﺩﺍﺷﺖ.ﺑﻨﺎﺑﺮﺍﻳﻦ ﺑﻪ ﺣﻞ ﻣﺴﻠﻪ ﺷﻤﺎ ﻭﺍﺑﺴﺘﻪ ﺍﺳﺖ ﻛﻪ ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﻻﻳﻪ ﻫﺎ ﺭﺍ strict layering ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﺩ ﻳﺎ ﺑﺼﻮﺭﺕ flexible layer .

 ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﻌﺮﻳﻒ ﻻﻳﻪ ﻭ ﻗﺮﺍﺭ ﺩﺍﺩﻥ ﺍﺟﺰﺍ ﺩﺭ ﻫﺮ ﻻﻳﻪ ﻣﺨﺼﻮﺹ ﺑﺨﻮﺩ ﻣﺎ ﻧﻴﺰ ﻧﻴﺎﺯ ﺑﻪ ﺗﻌﺮﻳﻒ ﻳﻚ ﻣﻌﻴﺎﺭ ﻛﻪ ﺑﺘﻮﺍﻧﻴﻢ ﺑﺮ

ﺍﺳﺎﺱ ﺁﻥ ﻻﻳﻪ ﻫﺎ ﺭﺍ ﺗﻌﺮﻳﻒ .ﻣﺜﻼ ﻣﺎ ﻣﻲ ﺗﻮﺍﻧﻴﻢ ﻻﻳﻪ ﻫﺎ ﺭﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻓﺎﺻﻠﻪ ﺍﻱ ﻛﻪ ﺍﺯ ﺳﺨﺖ ﺍﻓﺰﺍﺭ ﺩﺍﺭﻧﺪ ﺑﺎ ﺗﻮﺟﻪ

ﭘﻴﭽﻴﺪﮔﻲ ﺗﻌﺮﻳﻒ ﻛﻨﻴﻢ ﻭ ﺑﻪ ﻧﺘﻴﺠﻪ ﺯﻳﺮ ﺑﺮﺳﻴﻢ

User-visible elements

Specific application modules

Common services level

Operating system interface level

Operation System

Hardware

ﺩﺭ ﺗ ﺼﻮﻳﺮ ﺯﻳﺮ ﻳﻚ ﻧﻤﻮﻧﻪ ﺍﺯ ﻻﻳﻪ ﺑﻨﺪﻱ ﺭﺍ ﻣ ﺸﺎﻫﺪﻩ ﻣﻲ ﻛﻨﻴﺪ ﻫﺮ ﭼﻨﺪ ﻛﻪ ﻣﻤﻜﻦ ﺍ ﺳﺖ ﺩﺭ ﺑﻌ ﻀﻲ ﻛﺘﺎﺏ ﻫﺎ ﺍﻳﻦ ﺗﺮﺗﻴﺐ ﻭ ﻧﺎﻡ ﻫﺎ

ﻣﺘﻔﺎﻭﺕ ﺑﺎ ﺷﻨﺪ ﺩﺭ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﺑﻪ ﺍﻳﻨ ﺼﻮﺭﺕ ﺩﻳﺪﻩ ﺍﻳﻢ ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﺑﻨﺎﺑﺮ ﭘﺮﻭﮊﻩ ﺧﻮﺩ ﻻﻳﻪ ﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﺩﺍ ﺷﺘﻪ ﺑﺎ ﺷﻴﻦ ﺗﺮﺗﻴﺐ ﻻﻳﻪ ﻫﺎﻱ

ﻣﺜﺎﻝ ﻣﺎ ﺑﺼﻮﺭﺕ ﺯﻳﺮ ﺍﺳﺖ:

presentation or client layer

the process or service layer

the domain or business logic

layer

the data access

ﮔﺎﻫﻲ ﺍﻭﻗﺎﺕ ﺩﺭ ﭘﺮﻭﮊﻫﺎ ،ﻣﻤﻜﻦ ﺍﺳﺖ ﻻﻳﻪ ﺍﻱ ﺑﻪ ﻧﺎﻡ crosscutting layer ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﻭ ﻣﺎﮊﻭﻝ

ﺩﺭﻭﻥ ﺍﻳﻦ layer ﻣﻲ ﺗﻮﺍﻧﺪ ﺑﺮ ﺭﻭﻱ ﺗﻤﺎﻡ ﻻﻳﻪ ﻫﺎﻱ ﺗﺎﺛﻴﺮ ﺩﺍﺷﺘﻪ ﻣﺎﻧﻨﺪ trace,secuirty,logging .

ﺍﻣﺎ ﻣﺰﺍﺑﺎﻳﻲ ﻣﻌﻤﺎﺭ ﻻﻳﻪ ﺍﻱ ﭼﻴﺴﺖ

 ﺍﮔﺮ ﻫﺮ ﻻﻳﻪ ﺑﺨﻮﺑﻲ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺑﺎﺷﺪ ﻭ sepeartion of cenecrn ﺑﺨﻮﺑﻲ ﺭﻋﺎﻳﺖ ﺷﺪﻩ ﺑﺎﺷﺪ ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﺍﺯ ﻻﻳﻪ ﻫﺎ ﺩﺭ

Context ﺩﻳﮕﺮ ﻣﺠﺪﺩﺍ ﺍﺳﺘﻔﺎﺩﻩ ﻛﻨﻴﺪ ﺑﻪ ﻧﻈﺮ ﻻﻳﻪ Access data ﻣﻮﺭﺩ ﺧﻮﺑﻲ ﺑﺎﺷﺪ.

 ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﻫﺮ ﻻﻳﻪ ﺭﺍ ﺩﺭ tire ﻣﺠﺰﺍ ﻗﺮﺍﺭ ﺩﻫﻴﺪ .ﺑﺎﺍﻳﻨﻜﺎﺭ ﻣﻲ ﺗﻮﺍﻧﻴﺪ performane ، Scalability ﻭ ﺭﺍ ﺍﻓﺰﺍﻳﺶ ﺩﻫﻴﺪ.

 ﭘﻴﺸﻴﺎﻧﻲ ﺍﺯ ﺑﺮﻧﺎﻣﻪ ﺭﺍﺣﺘﺮ ﺍﺳﺖ ﭼﻮﻥ ﺷﻤﺎ ﺑﻪ ﺭﺍﺣﺘﻲ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﻣﺸﻜﻞ ﺩﺭ ﻫﺮ ﻻﻳﻪ ﺑﻪ ﺻﻮﺭﺕ ﻣﺘﻤﺮﻛﺰ ﭘﻴﺪﺍ ﻛﻨﻴﺪ.

 ﺗﻮﺳﻌﻪ ﺑﺮﻧﺎﻣﻪ ﺳﺎﺩﻩ ﺗﺮ ﺧﻮﺍﻫﺪ ﺑﻮﺩ.

 ﺗﺴﺖ ﻛﺮﺩﻥ ﺑﺮﻧﺎﻣﻪ ﺑﺼﻮﺭﺕ ﺳﺎﺩﻩ ﺗﺮﻱ ﺍﻣﻜﺎﻥ ﭘﺬﻳﺮ ﺍﺳﺖ.

 ﻭ…

ﺗﻔﺎﻭﺕ ﻻﻳﻪ ﻭ ﺳﻄﻮﺡ ( Tire vs layers )

Layer

ﻻﻳﻪ ﺍﺷﺎﺭﻩ ﺑﻪ ﺩﺳﺖ ﺑﻨﺪﻱ ﻛﺪﻫﺎ ﺑﺮﻧﺎﻣﻪ ﺑﺼﻮﺭﺕ ﻣﻨﻄﻘﻲ ﻣﻲ ﻧﻤﺎﻳﺪ ﺩﺭ ﻭﺍﻗﻊ ﺑﺎ ﺍﻳﻨﻜﺎﺭ ﭘﻴﭽﻴﺪﮔﻲ ﻫﺎﻱ ﻳﻚ ﻣ ﺴﺌﻠﻪ ﺭﺍ ﺩﺭ ﻻﻳﻪ ﻫﺎﻱ

ﻣﺨﺘﻠﻔﻲ ﺷﻜﺴﺘﻪ ﻭ ﺩﺭ ﻫﺮ ﻻﻳﻪ ﻗﺴﻤﺘﻲ ﺍﺯ ﺍﻳﻦ ﭘﻴﭽﻴﺪﮔﻲ ﺭﺍ ﻣﺪﻳﺮﻳﺖ ﻛﻨﺪ.ﺍﻳﻦ ﺩﺳﺘﻪ ﺑﻨﺪﻱ ﻛﺎﻣﻼ ﺑﺼﻮﺭﺕ ﻣﻨﻄﻘﻲ ﺑﺮﺍﻱ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻛﺪﻫﺎﻱ

ﻛﻪ ﻭﻇﻴﻔﻪ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺍﻳﻦ ﭘﻴﭽﻴﺪﮔﻲ ﻫﺎ ﺭﺍ ﺩﺍﺭﺩ ﺍﻧﺠﺎﻡ ﻣﻲ ﭘﺬﻳﺮﺩ.ﺩﺭ ﺍﻳﻦ ﻣﻔﻬﻮﻡ ﺍﺷﺎﺭﻩ ﺍﻱ ﺑﻪ ﺍﺳﺘﻘﺮﺍﺭ ﻓﻴﺰﻳﻜﻲ ﻻﻳﻪ ﻫﺎ ﻧﻤﻲ ﺷﻮﺩ ﺑﻠﻜﻪ ﻓﻘﻂ

ﻣﺎ ﺑﻪ ﺩﻧﺒﺎﻝ ﺩﺳﺘﻪ ﺑﻨﺪﻱ ﻭ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻣﻨﻄﻘﻲ ﺍﺟﺰﺍﻱ ﺑﺮﻧﺎﻣﻪ ﻫﺴﺘﻴﻢ.

Tire

ﺩﺭ Tire ﻣﺎ ﺑﻪ ﺩﻧﺒﺎﻝ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻛﺪﻫﺎ ﺑﺮ ﺍ ﺳﺎﺱ ﻣﺤﻞ ﺍﺟﺮﺍﻱ ﻛﺪﻫﺎ ﺍﺯ ﻧﻈﺮ ﻓﻴﺰﻳﻜﻲ ﻫ ﺴﺘﻴﻢ .ﺩﺭ ﻭﺍﻗﻌﺎ Tire ﻣﺤﻠﻲ ﺍ ﺳﺖ ﻛﻪ ﻻﻳﻪ ﻫﺎ ﺑﺮ ﺭﻭﻱ ﺁﻥ Deploy ﻭ ﺍﺟﺮﺍ ﻣﻲ ﺷــﻮﻧﺪ.ﻣﺎ ﻣﻲ ﺗﻮﺍﻧﻴﻢ ﺑﺮﺍﻱ ﻫﺮ ﻻﻳﻪ ﻳﻚ Tire ﻭ ﻳﺎ ﻳﻚ ﺳــﺮﻭﺭ ﺟﺪﺍﮔﺎﻧﻪ ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻳﻢ ﻭ ﻳﺎ ﻣﻲ ﺗﻮﺍﻧﻴﻢ ﻳﻚ Tire ﺩﺍﺷـﺘﻪ ﺑﺎﺷـﻴﻢ ﻭ ﺗﻤﺎﻡ Layer ﻫﺎ ﺭﺍ ﺑﺮ ﺭﻭﻱ ﺁﻥ ﺍﺟﺮﺍ ﻛﻨﻴﻢ. ﺑﻨﺎﺑﺮﺍﻳﻦ ﻻﻳﻪ ﻫﺎ ﻳﻚ ﺩﺳـﺘﻪ ﺑﻨﺪﻱ ﻣﻨﻄﻘﻲ ﻫﺴـﺘﻨﺪﺍﻣﺎ Tire ﻫﺎ ﺩﺳﺘﻪ ﺑﻨﺪﻱ ﻓﻴﺰﻳﻜﻲ ﺍﺳﺖ.

ﻭﺍﺑﺴﺘﮕﻲ ﻫﺎﻱ ﻏﻴﺮ ﺿﺮﻭﺭﻱ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ

ﺩﺭ ﺗﻮﻟﻴﺪ ﺳﻴ ﺴﺘﻢ ﻫﺎ ﺍﻧﭽﻪ ﻛﻪ ﺍﻫﻤﻴﺖ ﺩﺍﺭﺩ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻧﻴﺎﺯﻣﻨﺪ ﻫﺎﻱ ﻛ ﺴﺐ ﻭ ﻛﺎﺭ ﻛﺎﺭﺑﺮﺍﻥ ﻭ ﺫﻳﻨﻌﺎﻥ ﺳﻴ ﺴﺘﻢ ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﻛﻪ

ﺑﻪ ﻋﻨﻮﺍﻥ Core domain ﺷﻨﺎﺧﺘﻪ ﻣﻲ ﺷﻮﺩﺍﻳﻦ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻫﺎ ﺑﻪ ﻋﻨﻮﺍﻥ ﻗﻠﺐ ﻭ ﻣﺮﻛﺰ ﺳﻴﺴﺘﻢ ﺑﺎﻳﺪ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﻮﺩ ﻭ ﻫﺮ ﮔﻮﻧﻪ ﻃﺮﺍﺣﻲ ﻭ ﺗﻮﺳﻌﻪ ﺩﻳﮕﺮ ﻣﺎﮊﻭﻝ ﻫﺎ ﺑﺎﻳﺪ ﺑﺮ ﺍﺳﺎﺱ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻛﺴﺐ ﻭ ﻛﺎﺭ (core domain) ﻭ ﺍﻳﻦ ﻻﻳﻪ ﺍﻧﺠﺎﻡ ﭘﺬﻳﺮﺩ .ﺑﻨﺎﺑﺮ ﺑﺎ ﺍﻳﻦ ﻧﮕﺎﻩ ﺩﻳﮕﺮ data access layer ﻧﺒﺎﻳﺪ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺮﻛﺰ ﺳﻴ ﺴﺘﻢ ﻗﺮﺍﺭ ﺑﮕﻴﺮﺩ ﻭ ﺑﺎ ﺗﻐﻴﻴﺮ ﺁﻥ business logic ﻭ ﺩﻳﮕﺮ ﻻﻳﻪ ﻫﺎ ﺭﺍ ﺗﺤﺖ ﺗﺎﺛﻴﺮ ﻗﺮﺍﺭ ﺩﻫﺪ.ﺍﻳﻦ ﻭﺍﺑﺴﺘﮕﻲ ﻛﻪ ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻣﺸﺎﻫﺪﻩ ﻣﻲ ﻛﻨﻴﺪ ﻳﻚ ﻭﺍﺑﺴﺘﮕﻲ ﻏﻴﺮ ﺿﺮﻭﺭﻱ ﺍﺳﺖ ﻛﻪ ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺳﻴﺴﺘﻢ ﺷﻤﺎ ﺑﻪ ﻭﺟﻮﺩ ﺁﻭﺭﺩ.ﺍﻳﻦ ﻧﻮﻉ ﻧﮕﺮﺵ ﻣﺮﻛﺰﻳﺖ ﻗﺮﺍﺭ ﺩﺍﺩﻥ ﻛﺴﺐ ﻭ ﻛﺎﺭ ﺩﺭ ﻣﻌﻤﺎﺭﻱ Domain Driven Design ﻧﻴﺰ ﻣﻄﺮﺡ ﺷﺪﻩ ﺍﺳﺖ.

ﺩﺭ ﻭﺍﻗﻊ ﻫﻤﺎﻧﻄﻮﺭ ﻛﻪ ﻣﺸﺎﻫﺪﻩ ﻣﻲ ﻛﻨﻴﺪ ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﺍﻱ Data access ﺩﺭ ﻣﺮﻛﺰ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﺍﺳﺖ ﻭ ﺍﮔﺮ ﺍﻳﻦ ﻻﻳﻪ ﺩﭼﺎﺭ ﺗﻐﻴﻴﺮ ﺑﺸﻮﺩ ﺗﻤﺎﻣﻲ ﻻﻳﻪ ﻫﺎ ﺭﺍ ﺩﭼﺎﺭ ﺗﻐﻴﻴﺮ ﺧﻮﺍﻫﺪ ﻧﻤﻮﺩ ﺩﺭ ﺻﻮﺭﺗﻲ ﻃﺮﺍﺣﻲ ﻣﺎ ﺑﺎﻳﺪ ﺑﺪﺍﻥ ﮔﻮﻧﻪ ﺍﻱ ﺑﺎﺷﺪ ﻛﻪ ﺩﺭ ﺻﻮﺭﺕ ﺗﻐﻴﻴﺮ ﺩﺭ ﺍﻳﻦ ﻻﻳﻪ ﻧﺒﺎﻳﺪ ﻻﻳﻪ ﻫﺎﻱ ﺩﻳﮕﺮ ﺭﺍ ﺩﭼﺎﺭ ﺩﮔﺮﮔﻮﻧﻲ ﻧﻤﺎﻳﻴﺪ.

ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﺍﻱ ﺑﻪ ﺻـﻮﺭﺕ ﻣﺴـﺘﻘﻴﻢ business logic ﺑﻪ data access ﻭﺍﺑﺴـﺘﻪ ﺍﺳـﺖ ﻭ ﺍﺯ ﺳـﻮﻱ ﺩﻳﮕﺮﻻﻳﻪ presentation ﺑﻪ ﺻﻮﺭﺕ ﻏﻴﺮ ﻣﺴﺘﻘﻴﻢ ﺑﻪ data access ﻭﺍﺑ ﺴﺘﻪ ﺍﺳﺖ . ﺑﻠﻪ ﺷﺎﻳﺪ ﻛﻤﻲ ﻋﺠﻴﺐ ﺑﻪ ﻧﻈﺮ ﺑﺮﺳﻴﺪ ﺍﻣﺎ ﺩﺭ ﻭﺍﻗﻌﺎ ﻻﻳﻪ presentation ﺑﻪ data access ﻭﺍﺑﺴﺘﻪ ﺍﺳﺖ..!!! ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻫﻤﻪ ﻻﻳﻪ ﻫﺎ ﺑﻪ ﻧﺤﻮﻱ ﺑﻪ Data access layer ﻭﺍﺑﺴﺘﻪ ﺷﺪﻩ ﺍﻧﺪ.

ﺩﺭ ﻭﺍﻗﻊ ﻻﻳﻪ presentation ﻧﻤﻲ ﺗﻮﺍﻧﺪ ﻛﺎﺭ ﻛﻨﺪ ﺍﮔﺮ ﻻﻳﻪ business logic ﻭﺟﻮﺩ ﻧﺪﺍﺷــﺘﻪ ﺑﺎﺷــﺪ ﻭ ﻫﻤﭽﻨﻴﻦ business logic ﻧﻤﻲتواند ﻛﺎﺭ ﻛﻨﺪ ﺍﮔﺮ data access ﻭﺟﻮﺩ ﻧﺪﺍﺷﺘﻪ ﺑﺎﺷﺪ ﻣﺎﮊﻭﻝ ﻫﺎﻱ ﺯﻳﺮ ﺳﺎﺧﺘﻲ ﺭﺍ ﻧﺎﺩﻳﺪﻩ ﻣﻲ ﮔﻴﺮﻡ ﭼﻮﻥ ﺍﻳﻦ ﻣﺎﮊﻭﻝ ﻫﺎ ﺍﺯ ﻫﺮ ﺳﻴﺴﺘﻤﻲ ﺑﻪ ﺳﻴﺴﺘﻤﻲ ﺩﻳﮕﺮ ﻣﻲ ﺗﻮﺍﻧﺪ ﻣﺘﻔﺎﻭﺕ ﺑﺎ ﺷﺪ ﺍﮔﺮ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﺎ ﺩﻗﺖ ﺑﺮﺭ ﺳﻲ ﻛﻨﻴﻢ ﻣﻼﺣ ﻀﻪ ﻣﻲ ﻛﻨﻴﺪ ﻛﻪ data access layer ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺗﺒﺪﻳﻞ ﺑﻪ ﻗﻠﺐ ﻭ ﻣﺮﻛﺰ ﻛﻞ ﺳــﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﺷــﺪﻩ ﺍﺳــﺖ. ﻭ ﺍﻳﻦ ﻣﺮﻛﺰﻳﺖ ﺑﺎﻋﺚ ﺑﻪ ﻭﺟﻮﺩ ﺁﻣﺪﻥ ﺍﻳﻦ ﻭﺍﺑﺴــﺘﮕﻲ ﻣﻲ ﺷــﻮﺩ ﻛﻪ ﻫﺮ ﺗﻐﻴﻴﺮﻱ ﺩﺭ ﺍﻳﻦ ﻻﻳﻪ ﻣﻲ ﺗﻮﺍﻧﺪ ﻛﻞ ﺩﻳﮕﺮ ﻻﻳﻪ ﻫﺎ ﺭﺍ ﺗﺤﺖ ﺗﺎﺛﻴﺮ ﻗﺮﺍﺭ ﺩﻫﺪ ﻭ ﻣﻲ ﺗﻮﺍﻧﺪ ﺑ ﺼﻮﺭﺕ ﻣﻮﺟﻲ ﺗﻤﺎﻡ ﻛﻞ ﺳﻴ ﺴﺘﻢ ﺭﺍ ﺩﭼﺎﺭ ﺗﻐﻴﻴﺮ ﻛﻨﺪ ﺍﺯ ﺑﺎﻻﺗﺮﻳﻦ ﻻﻳﻪ ﺗﺎ ﭘﺎﻳﻴﻦ ﺗﺮﻳﻦ ﻻﻳﻪ ﺭﺍ ﺩﺭ ﺑﺮ ﺑﮕﻴﺮﺩ.ﻭ ﺍﻳﻦ ﻭﺍﺑ ﺴﺘﮕﻲ ﻏﻴﺮ ﺿﺮﻭﺭﻱ ﺍ ﺳﺖ ﻛﻪ ﻛﻞ ﺳﻴ ﺴﺘﻢ ﺑﻪ data access layer ﭘﻴﺪﺍ ﻛﺮﺩﻩ ﺍﺳﺖ.

ﺍﺯ ﺳﻮﻱ ﺩﻳﮕﺮ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺑ ﺸﺪﺕ ﺑﻪ ﻣﺎﮊﻭﻝ ﻫﺎﻱ ﺯﻳﺮ ﺳﺎﺧﺘﻲ ﻧﻴﺰ ﻭﺍﺑ ﺴﺘﻪ ﺍ ﺳﺖ ﻭ ﻫﻤﺎﻧﻄﻮﺭ ﻛﻪ ﻣ ﺸﺎﻫﺪﻩ ﻣﻲ ﻛﻨﻴﺪ ﻻﻳﻪ ﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻭ ﺑﺼﻮﺭﺕ ﻣﺸﺨﺺ business logic ﺑﻪ ﺷﺪﺕ ﺩﺭﮔﻴﺮ ﻭﺍﺑﺴﺘﮕﻲ ﺑﻪ ﺍﻳﻦ ﻣﺎﮊﻭﻝ ﻫﺎ ﻫﺴﺘﻨﺪ ﺍﻳﻦ ﻭﺍﺑﺴﺘﮕﻲ ﻫﺎ ﺑﺎﻋﺚ ﺑﻪ ﻭﺟﻮﺩ ﺁﻭﺭﺩﻥ ﻣﺸﻜﻼﺗﻲ ﺩﺭ ﺗﺴﺖ ﻭ ﻧﮕﻬﺪﺍﺭﻱ ﺳﻴﺴﺘﻢ ﺧﻮﺍﻫﻨﺪ ﺑﻮﺩ ﻭﻛﺎﺭ ﺭﺍ ﺑﺮﺍﻱ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻭ ﺗﺴﺖ ﻛﺮﺩﻥ ﻻﻳﻪ ﻫﺎ ﺭﺍ ﺳﺨﺖ ﻭ ﺳﺨﺘﺮ ﻣﻲ ﻛﻨﺪ .

ﻧﻘﺸﻪ ﻳﻚ ﺷﻬﺮ ﭼﻴﻦ،ﻛﻪ ﻧﻘﺸﻪ ﺑﺎ ﻣﺤﻮﺭﻳﺖ ﻭ ﻣﺮﻛﺰ ﺑﻮﺩﻥ ﺷﻬﺮ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺍﺳﺖ

ﻗﺒﻞ ﺍﺯ ﻭﺭﻭﺩ ﺑﻪ ﺗﻌﺮﻳﻒ ﻣﻌﻤﺎﺭﻱ Onion Architecture ﻻﺯﻡ ﺍﺳﺖ ﺑﺎ ﻧﮕﺎﻫﻲ ﺑﻪ DDD ﻧﻴﺰ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﻢ.ﭼﺮﺍ ﻛﻪ ﺍﺯ ﻧﻈﺮ ﻣﻨﻄﻖ ﻃﺮﺍﺣﻲ

ﺑﺴﻴﺎﺭ ﺑﻪ ﺑﻪ ﻣﻌﻤﺎﺭﻱ Onion Architecture ﻧﺰﺩﻳﻚ ﻫﺴﺘﻨﺪ.

Domain Driven Design

ﺩﺭ ﺳﺎﻝ 2004 ﺁﻗﺎﻱ Eric Evans ﺩﺭ ﻛﺘﺎﺏ Domain-Driven Design: Tackling Complexity in the Heart of

Software ﺑﺎ ﺍﺭﺍﺋﻪ ﺍﻟﮕﻮﻱ DDD ﻛﻪ ﺑﺎ ﻣﺤﻮﺭﻳﺖ business domain ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺮﻛﺰ ﻭ ﻗﻠﺐ ﺳﻴﺴﺘﻢ ﻫﻤﺮﺍﻩ ﺍﺳﺖ ﺍﺭﺍﺋﻪ ﺩﺍﺩ ﺩﺭ ﺍﻳﻦ ﺍﻟﮕﻮ

business domain ﺑﻪ ﻋﻨﻮﺍﻥ Core domain ﺩﺭ ﻣﺮﻛﺰ ﻃﺮﺍﺣﻲ ﺷﻤﺎ ﻗﺮﺍﺭ ﺧﻮﺍﻫﺪ ﮔﺮﻓﺖ ﻭ ﻃﺮﺍﺣﻲ ﻭ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺳﻴﺴﺘﻢ ﺑﺮ ﺍﺳﺎﺱ ﺍﻳﻦ

ﻣﺮﻛﺰﻳﺖ ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﺍﻳﻦ ﺍﻟﮕﻮ ﺑﺮ ﺳﻪ ﺍﺭﺯﺵ ﺗﻤﺮﻛﺰ ﻳﺎﻓﺘﻪ ﺍﺳﺖ ﻛﻪ ﻋﺒﺎﺭﺳﺖ ﺍﺯ :

 ﺗﻤﺮﻛﺰ ﺍﺳﺎﺳﻲ ﭘﺮﻭﮊﻩ ﺭﺍ ﺑﺮ ﺭﻭﻱ Domain ﻗﺮﺍﺭ ﻣﻲ ﺩﻫﻴﻢ.

 ﺍﺳﺎﺱ ﻃﺮﺡ ﻫﺎﻱ ﭘﻴﭽﻴﺪﻩ ﺑﺮ ﺍﺳﺎﺱ ﻣﺪﻝ ﺩﺍﻣﻨﻪ ﻗﺮﺍﺭ ﻣﻲ ﺩﻫﻴﻢ

 ﺍﻳﺠﺎﺩ ﻫﻤﻜﺎﺭﻱ ﻣﺪﺍﻭﻡ ﺑﻴﻦ ﺧﺒﺮﻩ ﻛﺴﺐ ﻭ ﻛﺎﺭ ﻭ ﺍﻓﺮﺍﺩ ﺗﻜﻨﻴﻜﺎﻝ ﺑﻪ ﻣﻨﻈﻮﺭ ﺣﻞ ﻣﺴﺎﺋﻞ ﻣﺮﺑﻮﻁ ﺑﻪ Domain .

Onion Architecture

ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺍﺯ ﻧﻈﺮ ﺷﻜﻞ ﺷﺒﻴﻪ ﻳﻚ ﭘﻴﺎﺯ ،ﻻﻳﻪ ﻻﻳﻪ ﻣﻲ ﺑﺎ ﺷﺪ ﻭ ﻫﺮ ﭼﻘﺪﺭ ﺑﻪ ﺳﻤﺖ ﻣﺮﻛﺰ ﺣﺮﻛﺖ ﻣﻲ ﻛﻨﻴﻢ ﺑﻪ ﻣﺮﻛﺰﺗﺮﻳﻦ ﻻﻳﻪ

ﻳﻌﻨﻲ business domain ﺧﻮﺍﻫﻴﺪ ﺭﺳـﻴﺪ ﺑﻨﺎﺑﺮﺍﻳﻦ ﺩﺭ ﻣﺮﻛﺰ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺗﻤﺮﻛﺰ ﺑﺮ ﭘﻴﺎﺩﻩ ﺳـﺎﺯﻱ Business ﻣﺮﺑﻮﻁ ﺑﻪ ﻣﺴـﻠﻪ ﺷـﻤﺎ

ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﻭ ﺑﺮ ﺧﻼﻑ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﺍﻱ ، Data access layer , infrastructure ﻛﻪ ﺩﺭ ﻣﺮﻛﺰ ﻭ ﻗﻠﺐ ﺳﻴ ﺴﺘﻢ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﺑﻮﺩ ﺟﺎﻱ

ﺧﻮﺩ ﺭﺍ ﺑﻪ business domain ﺩﺍﺩﻩ ﺍﻧﺪ ﻭ ﺍﻳﻦ ﻻﻳﻪ ﻫﺎ ﺑﻪ ﺧﺎﺭﺟﻲ ﺗﺮﻳﻦ ﻻﻳﻪ ﺍﻧﺘﻘﺎﻝ ﭘﻴﺪﺍ ﻛﺮﺩﻩ ﺍﻧﺪ .ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﻗﺒﻞ ﺩﻳﺪ ﻛﻪ ﺍﻳﻦ ﻻﻳﻪ ﻫﺎ

ﭼﮕﻮﻧﻪ ﺑﺎﻋﺚ ﺑﻪ ﻭﺟﻮﺩ ﺁﻭﺭﺩﻥ ﻳﻚ ﻭﺍﺑﺴﺘﮕﻲ ﻏﻴﺮ ﺿﺮﻭﺭﻱ ﺷﺪﻩ ﺑﻮﺩﻧﺪ . ﺩﺭ ﻻﻳﻪ ﻫﺎﻱ ﺧﺎﺭﺟﻲ ﺍﻳﻦ ﭘﻴﺎﺯ ﻻﻳﻪ ﻫﺎﻱ ﻗﺮﺍﺭ ﻣﻲ ﮔﻴﺮﻧﺪ ﻛﻪ ﻣﻌﻤﻮﻻ

ﺗﻐﻴﻴﺮ ﻣﻲ ﻛﻨ ﻨﺪ ،ﺍﻛﻨﻮﻥ ﺑﺎ ﺍﻳﻦ ﻧﻮﻉ ﻃﺮﺍﺣﻲ ﺗﻐﻴﻴﺮﺍﺕ ﺁﻧ ﻬﺎ ﺗﺎﺛﻴﺮﻱ ﺑﺮ ﺭﻭﻱ Domain Model ﻧﺨﻮﺍﻫ ﻨﺪ ﮔﺬﺍﺷـــﺖ .ﺁ ﻗﺎﻱ Jeffrey

Palermo ﺍﻳﻦ ﻧﻮﻉ ﻃﺮﺍﺣﻲ ﺭﺍ Onion Architecture ﻧﺎﻣﻴﺪ ﻭ ﺩﺭ weblog ﺧﻮﺩ ﻣﻄﺮﺡ ﻛﺮﺩﻧﺪ.

ﺑﮕﺬﺍﺭﻳﺪ ﻧﮕﺎﻩ ﺩﻗﻴﻖ ﺗﺮﻱ ﺑﻪ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺑﻴﻨﺪﺍﺯﻳﻢ.

 ﻗﺎﻧﻮﻥ ﻣﻬﻢ ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺍﻳﻦ ﺍﺳﺖ ﻛﻪ ﻫﺮ ﻻﻳﻪ ﺑﻪ ﻻﻳﻪ ﺩﺭﻭﻧﻲ ﻭﺍﺑﺴﺘﻪ ﻫﺴﺘﻨﺪ ﺍﻣﺎ ﺍﺟﺎﺯﻩ ﻭﺍﺑﺴﺘﮕﻲ ﺑﻪ ﻻﻳﻪ ﺧﺎﺭﺟﻲ ﺭﺍ ﻧﺪﺍﺭﻧﺪ.

 ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺍﻱ ﻣﺴﻠﻪ ﻫﺎﻱ ﭘﻴﭽﻴﺪﻩ ﻭ ﺑﺎ ﺍﻧﺪﺍﺯﻩ ﺑﺰﺭﮒ ﺑﺴﻴﺎﺭ ﻛﺎﺭﺑﺮﺩ ﺧﻮﺍﻫﺪ ﺩﺍﺷﺖ.

ﺩﺭ ﻣﺮﻛﺰ ﺍﻳﻦ ﭘﻴﺎﺯ ، ﻻﻳﻪ Domain model ﻗﺮﺍﺭ ﺩﺍﺭﺩ،ﻛﻪ object model ﺍﺯ domain ﺷﻤﺎ ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﻛﻪ ﺷﺎﻣﻞ ﺭﻓﺘﺎﺭ ﻭ ﺩﺍﺩﻩ ﻣﻲ

ﺷﻮﺩ.ﺗﻌﺪﺍﺩ ﻻﻳﻪ ﻫﺎ ﺷﻤﺎ ﺩﺭ ﻣﺮﻛﺰ ﺑﺮﻧﺎﻣﻪ (application core) ﺑﺮ ﺍﺳﺎﺱ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﺪ ﻣﺘﻔﺎﻭﺕ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﻮﻧﺪ ﺍﻣﺎ ﺩﺭ

ﻧﻈﺮ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﺪ ﻛﻪ ﺩﺭ ﻣﺮﻛﺰ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ Domain model ﺑﻪ ﻫﻴﭻ ﻻﻳﻪ ﺍﻱ ﻭﺍﺑﺴﺘﻪ ﻧﺨﻮﺍﻫﺪ ﺑﻮﺩ ﭼﺮﺍ ﻛﻪ ﺑﺮ ﺍﺳﺎﺱ ﻗﺎﻧﻮﻥ ﻫﻴﭻ ﻻﻳﻪ ﺍﻱ

ﺑﻪ ﻻﻳﻪ ﺑﻴﺮﻭﻧﻲ ﻭﺍﺑﺴﺘﻪ ﻧﻴﺴﺖ ﻭ ﭼﻮﻥ ﻻﻳﻪ Domain model . ﺩﺭ ﻣﺮﻛﺰ ﻗﺮﺍﺭ ﺩﺍﺭﺩ ﺑﺼﻮﺭﺕ ﻣﻨﻄﻘﻲ ﻧﺒﺎﻳﺪ ﺑﻪ ﻫﻴﭻ ﻻﻳﻪ ﺍﻱ ﻭﺍﺑﺴﺘﮕﻲ ﺩﺍﺷﺘﻪ

ﺑﺎﺷﺪ .ﻭ ﺍﻳﻦ ﻻﻳﻪ ﺗﻤﺮﻛﺰ ﺧﻮﺩ ﺭﺍ ﺑﺮ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻛﺴﺐ ﻭ ﻛﺎﺭ ﻗﺮﺍﺭ ﻣﻲ ﺩﻫﺪ.ﻭ ﺩﻳﮕﺮ ﻻﻳﻪ ﻫﺎ ﺑﺮ ﺍﺳﺎﺱ ﻧﻴﺎﺯﻣﻨﺪ ﻫﺎﻱ Business domain

ﺗﻌﺮﻳﻒ ﻭ ﺑﻪ ﺗﺮﺗﻴﺐ ﺩﺭ ﻻﻳﻪ ﻫﺎﻱ ﺧﺎﺭﺟﻲ ﺍﺯ ﻣﺮﻛﺰ ﻗﺮﺍﺭ ﻣﻲ ﮔﻴﺮﻧﺪ ﻭ ﺑﺨﺸﻲ ﺍﺯ ﭘﻴﭽﻴﺪﮔﻲ ﻭﺍﮔﺬﺍﺭ ﺷﺪﻩ ﺑﻪ ﺧﻮﺩ ﺭﺍ ﻣﺪﻳﺮﻳﺖ ﻭ ﺗﻤﺮﻛﺰ ﻣﻲ

ﻛﻨﺪ.

ﺍﮔﺮ application core ﻧﻴﺎﺯ ﺑﻪ ﻻﻳﻪ data access ﻭ ﻳﺎ infrastructure ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﻳﻚ interface ﺗﻌﺮﻳﻒ ﻣﻲ ﻛﻨﺪ ﻭ ﻣﺘﺪﺩﻫﺎ

ﻭ ﺭﻓﺘﺎﺭﻱ ﻛﻪ ﻧﻴﺎﺯ ﺩﺍﺭﺩ ﺩﺭ ﺁﻥ ﻣﺸــﺨﺺ ﻣﻲ ﻛﻨﺪ ﻭ ﺍﻳﻦ ﻭﻇﻴﻔﻪ ﻻﻳﻪ ﻫﺎﻱ ﺧﺎﺭﺟﻲ ﻫﺴــﺘﻨﺪ ﻛﻪ ﺍﻳﻦ ﺍﻳﻨﺘﺮﻓﻴﺲ ﻫﺎ ﺭﺍ ﭘﻴﺎﺩﻩ ﺳـــﺎﺯﻱ ﻛﻨﻨﺪ

ﺑﻨﺎﺑﺮﺍﻳﻦ ﻻﻳﻪ ﻣﺮﻛﺰﻱ ﻧﻴﺎﺯ ﻫﺎﻱ ﺧﻮﺩ ﺭﺍ ﺑﻪ ﺩﻧﻴﺎﻱ ﺑﻴﺮﻭﻥ ﺍﺯ ﻃﺮﻳﻖ ﺍﻳﻦ ﺍﻳﻨﺘﺮﻓﻴﺲ ﻫﺎ ﻣﻄﺮﺡ ﻣﻲ ﻛﻨﺪ ﺩﺭ ﭘﺎﺳﺦ ﻭﻇﻴﻔﻪ ﻻﻳﻪ ﻫﺎﻱ ﺧﺎﺭﺟﻲ ﭘﻴﺎﺩﻩ

ﺳــﺎﺯﻱ ﻛﺮﺩﻥ ﺍﻳﻦ ﺍﻳﻨﺘﺮﻓﻴﺲ ﻫﺎ ﺭﺍ ﺑﻪ ﻋﻬﺪﻩ ﺩﺍﺭﻧﺪ ﺑﻨﺎﺑﺮﺍﻳﻦ ﻣﺎ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻣﻜﺎﻧﻴﺰﻣﻲ ﻫﺴــﺘﻴﻢ ﻛﻪ ﭘﻴﺎﺩﻩ ﺳــﺎﺯﻱ ﺍﻳﻦ ﺍﻳﻨﺘﺮﻓﻴﺲ ﻫﺎ ﺭﺍ ﺍﺯ ﻻﻳﻪ

ﻫﺎﻱ ﺧﺎﺭﺟﻲ ﺑﻪ ﺁﻥ ﺍﻳﻨﺘﺮﻓﻴﺲ ﻫﺎ ﺗﺰﺭﻳﻖ ﻳﺎ inject ﻛﻨﺪ ﺑﻨﺎﺑﺮﺍﻳﻦ ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺍﺯ inversion of control (IoC) ﺑﻬﺮﻩ ﻣﻲ ﺑﺮﺩ ﻭ ﺍﻳﻦ

ﺗﺰﺭﻳﻖ ﻭﺍﻳﺴﺘﮕﻲ ﻫﺎ ﺭﺍ ﺍﺯ ﺍﻳﻦ ﻃﺮﻳﻖ ﺍﻧﺠﺎﻡ ﺩﻫﻴﺪ.

ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﺍﺯ ﺍﺑﺰﺍﺭﻱ ﻣﺎﻧﻨﺪ spring,ninject,.. ﺑﺪﻳﻦ ﻣﻨﻈﻮﺭ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﺪ.

ﺑﻨﺎﺭﺍﻳﻦ ﻫﻤﺎﻧﻄﻮﺭ ﻛﻪ ﻣﺸﺎﻫﺪﻩ ﻣﻲ ﻛﻨﻴﺪ Application Core ﺑﺮﻧﺎﻣﻪ ﺷﻤﺎ ﺍﺳﺎﺳﺎ ﺑﻪ ﻫﻴﭻ ﺗﻜﻨﻮﻟﻮﮊﻱ ﻭﺍﺑﺴﺘﻪ ﻧﻴﺴﺖ ﺑﻠﻜﻪ ﺍﻳﻦ ﻻﻳﻪ ﻫﺎﻱ

ﺧﺎﺭﺟﻲ ﻫﺴﺘﻨﺪ ﻛﻪ ﻭﻇﻴﻔﻪ ﺩﺭﮔﻴﺮ ﺷﺪﻥ ﻭ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻛﺮﺩﻥ ﺗﻜﻨﻮﻟﻮﮊﻱ ﻫﺎ ﺭﺍ ﺑﻪ ﻋﻬﺪﻩ ﺩﺍﺭﻧﺪ ﺑﻨﺎﺑﺮﺍﻳﻦ ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﺑﺪﻭﻥ ﺍﻳﻨﻜﻪ

Application core ﺧﻮﺩ ﺭﺍ ﺗﻐﻴﻴﺮ ﺩﻫﻴﺪ ﻭ ﺑﻪ ﺩﻟﻴﻞ ﻋﻮﺽ ﻛﺮﺩﻥ ﺗﻜﻨﻮﻟﻮﮊﻱ ﺩﺳﺘﺨﻮﺵ ﺗﻐﻴﻴﺮ ﮔﺮﺩﻧﻨﺪ ﻫﺮ ﻧﻮﻍ ﺗﻐﻴﻴﺮﻱ ﻛﻪ ﻧﻴﺎﺯ ﻣﻲ ﺑﻴﻨﻴﺪ

ﺑﻪ ﻻﻳﻪ ﻫﺎﻱ ﺧﺎﺭﺟﻲ ﺧﻮﺩ ﺩﻫﻴﺪ ﻣﺜﻼ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﺗﻜﻨﻮﻟﻮﮊﻱ ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﺩﻳﺘﺎ ﺑﻴﺲ ، log ، infrastructure ﻭ ﻏﻴﺮﻩ ﺭﺍ ﺑﺪﻭﻥ ﻧﮕﺮﺍﻧﻲ ﺍﺯ ﺗﻐﻴﻴﺮ

ﺑﺮ ﺭﻭﻱ ﺩﻳﮕﺮ ﻻﻳﻪ ﻫﺎ ﺗﻐﻴﻴﺮ ﺩﻫﻴﺪ.

ﺩﺭ ﻻﻳﻪ ﻫﺎﻱ ﺧﺎﺭﺟﻲ ﻣﻌﻤﻮﻻ ﻻﻳﻪ ﻫﺎﻱ UI ﻭ infrastructure ﻭ test ﺭﺍ ﻣﻲ ﺑﻴﻨﻴﻢ.ﻻﻳﻪ ﻫﺎﻱ ﺧﺎﺭﺟﻲ ﻣﻌﻤﻮﻻ ﻣﺎﮊﻭﻝ ﻫﺎﻱ ﻗﺮﺍﺭ ﻣﻲ ﮔﻴﺮﻧﺪ ﻛﻪ

ﻧﺮﺥ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﺁﻧﻬﺎ ﺑﺎﻻ ﺍﺳﺖ.

ﺍﻳﻦ ﺭﻭﻳﻜﺮﺩ ﻣﺎ ﺭﺍ ﻣﺴﺘﻘﻞ ﻣﻲ ﻛﻨﺪ ﺍﺯ ﺯﻳﺮ ﺳﺎﺧﺘﻬﺎﻱ ﻣﺨﺘﻠﻒ ﻭ ﻣﺒﺎﺣﺚ crosscutting ﺷﺎﻣﻞ ﻣﻮﺍﺭﺩ ﺯﻳﺮ:

Database :ﺍﻛﻨﻮﻥ business domain ﻫﺎﻱ ﺷﻤﺎ ﺩﻳﮕﺮ ﻭﺍﺑﺴﺘﻪ ﺑﻪ Database ﻧﻴﺴﺖ

UI :ﺭﺍﺑﻂ ﻛﺎﺭﺑﺮﻱ ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﺪ ﺗﻐﻴﻴﺮ ﻛﻨﺪ ﺑﺪﻭﻥ ﺍﻳﻨﻜﻪ ﭼﻴﺰﻱ ﺩﺭ ﺳﻴﺴﺘﻢ ﺗﻐﻴﻴﺮ ﻛﻨﺪ

framework :ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺎﺳﺎ ﺑﻪ framework ﻫﺎﻱ ﻛﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲ ﻛﻨﻴﺪ ﻭﺍﺑﺴﺘﻪ ﻧﻴﺴﺖ. ﺍﻳﻦ ﺑﻪ ﺷﻤﺎ ﺍﺟﺎﺯﻩ ﻣﻲ

ﺩﻫﺪ ﺍﺯ ﭼﺎﺭﭼﻮﺏ ﻫﺎ ﺑﻪ ﻋﻨﻮﺍﻥ ﺍﺑﺰﺍﺭ ﺍﺳﺘﻔﺎﺩﻩ ﻛﻨﻴﺪ ﺗﺎ ﺳﻴﺴﺘﻢ ﺧﻮﺩ ﺭﺍ ﻣﺤﺪﻭﺩ ﺑﻪ ﻣﺤﺪﻭﺩﻳﺖ ﻫﺎﻱ ﻣﺤﺪﻭﺩ ﺧﻮﺩ ﻛﻨﻴﺪ

External agency : business domain ﻫﺎ ﻫﻴﭻ ﭼﻴﺰ ﺩﺭ ﻣﻮﺭﺩ ﺩﻧﻴﺎ ﺑﻴﺮﻭﻥ ﻧﻤﻲ ﺩﺍﻧﺪ.ﻭ ﻓﻘﻂ ﺗﻤﺮﻛﺰ ﺧﻮﺩ ﺭﺍ ﺑﺮ

ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻣﻨﻄﻖ ﻛﺴﺐ ﻭ ﻛﺎﺭ ﻗﺮﺍﺭ ﻣﻲ ﺩﻫﺪ.

ﻭﺩﺭ ﻧﻬﺎﻳﺖ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺑﺸﺪﺕ ﻗﺎﺑﻠﻴﺖ ﺗﺴﺖ ﻛﺮﺩﻥ ﺭﺍ ﺩﺍﺭﺍﺳﺖ.

Layers vs. Onions

ﺍﮔﺮ ﻣﺎ ﺍﺭﺯﺵ ﻫﺎﻱ ﻛﻪ ﺩﺭ Onion Architecture ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﺑﺮ ﺑﻪ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﺍﻱ ﺍﻋﻤﺎﻝ ﻛﻨﻴﻢ ﺑﻪ ﺷﻜﻞ ﺯﻳﺮ ﺧﻮﺍﻫﻴﻢ ﺭﺳﻴﺪ.

ﺗﻔﺎﻭﺕ ﻫﺎ ﺍﺯ ﺍﻧﺠﺎ ﺁﻏﺎﺯ ﻣﻴﺸﻮﺩ ﻛﻪ DAL ، UI ، Cross-cutting ﺑﻪ ﻫﻤﺮﺍﻩ ﻫﺮ ﭼﻴﺰﻱ ﺩﺭ ﻣﻮﺭﺩ IO ﺑﺎﻳﺪ ﺩﺭ ﻻﻳﻪ ﻫﺎﻱ ﺧﺎﺭﺟﻲ ﻗﺮﺍﺭ ﮔﻴﺮﺩ ﻧﻪ ﺩﺭ

ﺩﺍﺧﻠﻲ ﺗﺮﻳﻦ ﻻﻳﻪ ﻫﺎ.ﺩﻳﮕﺮ ﺗﻔﺎﻭﺕ ﻛﻪ ﺩﺭ ﻣﺪﻝ ﭘﻴﺎﺯﻱ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﺩﺭ ﻣﻘﺎﻳﺴ ـﻪ ﺑﺎ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﺍﻱ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﺁﻥ ﺍﺳ ـﺖ ﻛﻪ ﻻﻳﻪ ﻫﺎﻱ ﺑﺎﻻﺗﺮ

ﻣﻲ ﺗﻮﺍﻧﻨﺪ ﺍﺯ ﻻﻳﻪ ﻫﺎﻱ ﭘﺎﻳﻴﻦ ﺑﻪ ﺭﺍﺣﺘﻲ ﺍﺳــﺘﻔﺎﺩﻩ ﻛﻨﻨﺪ ﻭ ﻧﻪ ﻓﻘﻂ ﺍﺯ ﻻﻳﻪ ﺯﻳﺮﻳﻦ ﺧﻮﺩ ﻫﺮ ﭼﻨﺪ ﺍﻳﻦ ﻧﻜﺘﻪ ﺭﺍ ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﺍﻱ ﻣﻲ ﺗﻮﺍﻥ ﺑﻪ

ﺟﺎﻱ ﺗﻌﺮﻳﻒ ﻻﻳﻪ ﻫﺎ ﺑﺼﻮﺭﺕ strict layering ﺑﺼﻮﺭﺕ Relaxed layers ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻛﺮﺩ.

ﻫﻤﺎﻧﻄﻮﺭ ﻛﻪ ﻣﺸﺎﻫﺪ ﻛﺮﺩﻳﺪ ﺍﮔﺮ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﺍﻱ ﺭﺍ ﺩﺭ ﺩﺍﻳﺮﻫﺎﻱ ﻣﺘﻤﺮﻛﺰ ﻧﺸﺎﻥ ﺩﻫﻴﻢ data access ﺩﺭ ﻣﺮﻛﺰ ﺍﻳﻦ ﺩﺍﻳﺮﻫﺎ ﻗﺮﺍﺭ ﺧﻮﺍﻫﻨﺪ

ﮔﺮﻓﺖ . ﻫﻤﺎﻧﻄﻮﺭ ﻣﺸﺎﻫﺪﻩ ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺑﺎ ﺗﻐﻴﻴﺮ data access ، infrastructure ..ﺗﻐﻴﻴﺮ ﻛﻨﺪ ﺑﺎﻋﺚ ﺗﻐﻴﻴﺮ ﺩﻳﮕﺮ ﻻﻳﻪ ﻫﺎ ﻭ ﺣﺘﻲ

business domain ﺷﻤﺎ ﻣﻲ ﺷﻮﺩ.ﻭ ﺩﻳﮕﺮ ﺗﻔﺎﻭﺕ ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺗﻔﺎﻭﺕ ﺩﺭ ﻣﺪﻳﺮﻳﺖ ﻛﺮﺩﻥ infrastructure ﺍﺳﺖ .ﺩﺭ ﻣﻌﻤﺎﺭﻱ

ﻻﻳﻪ ﺍﻱ ،ﻻﻳﻪ ﻫﺎ ﺑﻄﻮﺭ ﻣﺴﺘﻘﻴﻢ ﺑﺎ ﺍﻳﻦ ﻣﺎﮊﻭﻝ ﻫﺎ ﺩﺭ ﺍﺭﺗﺒﺎﻁ ﻫﺴﺘﻨﺪ ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﭘﻴﺎﺯﻱ ﻣﻨﻄﻖ ﻣﺘﻔﺎﻭﺕ ﻣﻲ ﺑﺎﺷﺪ ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﺍﻳﻦ ﻻﻳﻪ ﻫﺎ ﺍﺯ ﻃﺮﻳﻒ

interface ﻫﺎ ﻣﻲ ﺑﺎﺷﺪ ﻛﻪ ﺩﺭ ﻻﻳﻪ ﻫﺎﻱ ﺩﺍﺧﻠﻲ ﺗﻌﺮﻳﻒ ﻭ ﺩﺭ ﻻﻳﻪ ﺑﻴﺮﻭﻧﻲ ﺍﻳﻦ interface ﻫﺎ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻣﻲ ﺷﻮﺩ ﺍﻣﻜﺎﻥ ﭘﺬﻳﺮ ﺍﺳﺖ.

ﻣﺰﺍﻳﺎﻳﻲ Onion Architecture

 ﺑﺸﺪﺕ ﺑﺎ DDD ﺳﺎﺯﮔﺎﺭ ﺍﺳﺖ ﻭ ﻗﺎﺑﻠﻴﺖ ﺗﺮﻛﻴﺐ ﺷﺪﻥ ﺑﺎ ﺁﻥ ﺭﺍ ﺩﺍﺭﺩ.

Application Core  ﺑﻪ ﻫﻴﭻ ﭼﻴﺰ ﻭﺍﺑﺴﺘﻪ ﻧﻴﺴﺖ ﻭ ﻫﻤﻪ ﭼﻴﺰ ﻭﺍﺑﺴﺘﻪ ﺑﻪ Core ﺍﺳﺖ.

 ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺑﺸﺪﺕ ﺍﻧﻌﻄﺎﻑ ﭘﺬﻳﺮ ﺍﺳﺖ ﻭ ﺷﻤﺎ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﻻﻳﻪ ﻫﺎﻱ ﺑﻴﺮﻭﻧﻲ ﺭﺍ ﺗﻐﻴﻴﺮ ﺑﺪﻫﻴﺪ ﺑﺪﻭﻥ ﺍﻳﻨﻜﻪ ﻻﻳﻪ ﻫﺎﻱ ﺩﺍﺧﻠﻲ ﺗﻐﻴﻴﺮ

ﻛﻨﺪ.

 ﻗﺎﺑﻠﻴﺖ ﺗﺴﺖ ﺑﺎﻻ،ﺑﻪ ﺩﻟﻴﻞ ﺍﻳﻨﻜﻪ Core ﺷﻤﺎ ﺑﻪ ﻫﻴﭻ ﭼﻴﺰﻱ ﻭﺍﺑﺴﺘﻪ ﻧﻴﺴﺖ ﻓﺮﺍﻳﻨﺪ ﺗﺴﺖ ﺑﺴﻴﺎﺭ ﺳﺎﺩﻩ ﺧﻮﺍﻩ ﺑﻮﺩ.

ﻧﻘﺎﻅ ﺿﻌﻒ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ

 ﻓﺮﺍﻳﻨﺪ ﻳﺎﮔﻴﺮﻱ ﻭ ﺩﺭﻙ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻛﺎﺭ ﺯﻣﺎﻥ ﺑﺮﻱ ﺧﻮﺍﻫﺪ ﺑﻮﺩ.

Interface  ﻫﺎ ﺗﻘﺮﻳﺒﺎ ﻫﻤﻪ ﺟﺎ ﻫﺴﺘﻦ.

ﺧﻼﺻﻪ

ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺳــﻌﻲ ﺑﺮ ﺁﻥ ﺩﺍﺭﺩ ﺑﺎ ﻣﺮﻛﺰﻳﺖ ﻗﺮﺍﺭ ﺩﺍﺩﻥ business domain ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺮﻛﺰﻱ ﺗﺮﻳﻦ ﻭ ﺑﺎ ﺍﻫﻤﻴﺖ ﺗﺮﻳﻦ ﺑﺨﺶ

ﺳﻴ ﺴﺘﻢ ﺩﺭ ﺟﺎﻳﮕﺎﻫﻲ ﻛﻪ ﺑﻪ ﻫﻴﭻ ﻣﺎﮊﻭﻟﻲ ﻭ ﻻﻳﻪ ﺍﻱ ﻭﺍﺑ ﺴﺘﻪ ﻧﺒﺎ ﺷﺪ ﻭ ﺑ ﺼﻮﺭﺕ ﻣﺘﻤﺮﻛﺰ ﺑﺮ ﺭﻭﻱ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻣﻨﻄﻖ ﻛ ﺴﺐ ﻭ ﻛﺎﺭ،ﻛﺎﺭﺑﺮﺍﻥ

ﺳﻴ ﺴﺘﻢ ﺗﻤﺮﻛﺰ ﻧﻤﺎﻳﻴﺪ . ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ ﻫﺎﻱ ﻛﻪ ﻧﺮﺥ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﺁﻥ ﺑﺎﻻ ﻣﻲ ﺑﺎ ﺷﺪ ﺩﺭ ﻻﻳﻪ ﻫﺎﻱ ﺑﻴﺮﻭﻧﻲ ﺗﺮ ﻣﺘﻤﺮﻛﺰ ﻣﻲ ﺷﻮﻧﺪ ﻭ ﺑﺎ

ﺗﻐﻴﻴﺮ ﺩﺭﻭﻥ ﺁﻧﻬﺎ ﺗﻐﻴﻴﺮ ﺑﺮ Application Core ﺑﺮﻧﺎﻣﻪ ﺗﺎﺛﻴﺮﻱ ﻧﺨﻮﺍﻫﺪ ﮔﺬﺍﺷـــﺖ.ﺗﻤﺎﻡ ﻧﻴﺎﺯﻣﻨﺪﻳﻬﺎﻱ ﻻﻳﻪ ﻫﺎﻱ ﺩﺭﻭﻧﻲ ﺍﺯ ﻗﺒﻴﻞ ﺫﺧﻴﺮﻩ

ﺍﻃﻼﻋﺎﺕ، IO ، infrastructure ﻭ ﻏﻴﺮﻩ ﺑﻪ ﺩﻧﻴﺎﻱ ﺧﺎﺭﺝ ﺍﺯ ﻃﺮﻳﻖ ﺗﻌﺮﻳﻒ ﺍﻳﻨﺘﺮﻓﻴﺲ ﻫﺎ ﺑﻴﺎﻥ ﻣﻲ ﺷﻮﻧﺪ ﻛﻪ ﺗﻮﺳﻂ ﻻﻳﻪ ﻫﺎﻱ ﺧﺎﺭﺟﻲ ﭘﻴﺎﺩﻩ

ﺳﺎﺯﻱ ﻣﻲ ﺷﻮﻧﺪ. ﺑﻨﺎﺑﺮﺍﻳﻦ ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻣﻲ ﺗﻮﺍﻥ ﺍﺯ inversion of control (IoC) ﺑﺴﻴﺎﺭ ﺑﻬﺮﻩ ﺑﺒﺮﻳﺪ ﻭ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺍﻳﻦ ﺍﻳﻨﺘﺮﻓﻴﺲ

ﻫﺎ ﺭﺍ ﺍﺯ ﺍﻳﻦ ﻃﺮﻳﻖ ﺩﺭ ﻻﻳﻪ ﻫﺎﻱ ﺩﺭﻭﻧﻲ ﺗﺰﺭﻳﻖ ﻧﻤﺎﻳﻴﺪ. ﺑﺪﻳﻦ ﻣﻨﻈﻮﺭ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﺍﺯ ﺍﺑﺰﺍﺭﻱ ﻣﺎﻧﻨﺪ spring,ninject,.. ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﺪ.

ﻳﺎﺩ ﮔﺮﻓﺘﻦ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻛﻤﻲ ﺩﺷﻮﺍﺭ ﺍﺳﺖ ﺍﻣﺎ ﺗﺴﺖ ﻛﺮﺩﻥ ﺁﻥ ﺑ ﺴﻴﺎﺭ ﺳﺎﺩﻩ ﺗﺮ ﺧﻮﺍﻫﺪ ﺑﻮﺩﻭ ﻫﻤﭽﻨﻴﻦ ﭘ ﺸﺘﻴﺒﺎﻧﻲ ﻭ ﺗﻐﻴﻴﺮ ﺩﺭ ﺁﻥ ﻣﻲ ﺗﻮﺍﻧﺪ

ﺑﻪ ﺳﺎﺩﮔﻲ ﺍﻧﺠﺎﻡ ﭘﺬﻳﺮﺩ.

ﺩﻭﺳﺘﺎﻥ ﺧﻮﺑﻢ ﺍﻣﻴﺪﻭﺍﺭﻡ ﻟﺬﺕ ﺑﺮﺩﻩ ﺑﺎﺷﻴﻦ ﻭ ﺧﻮﺷﺤﺎﻝ ﻣﻴﺸﻢ ﻛﻪ ﻧﻈﺮﺍﺗﺘﻮﻥ ﺭﻭ ﺑﻬﻢ ﺍﻳﻤﻴﻞ ﺑﺰﻧﻴﺪ:

https://Github.com/LotfiAli

LotfiAliDev@gmail.com

ﻣﻨﺒﻊ:

https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/

Chop Onions Instead of Layers in Software Architecture

دسته بندی شده در:

برچسب ها:

,