Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

これから学ぶ人のための ソフトウェアアーキテクチャ入門: Software architect...

これから学ぶ人のための ソフトウェアアーキテクチャ入門: Software architecture is a tool to enhance our humanity

Developers Summit2023 Summer #devsumi での発表資料です
https://event.shoeisha.jp/devsumi/20230727/session/4471/ #devsumiC

Koji SHIMADA

July 27, 2023
Tweet

More Decks by Koji SHIMADA

Other Decks in Technology

Transcript

  1. Wandering down our corridor a while ago, I saw my

    colleague Dave Rice in a particularly grumpy mood. My brief question caused a violent statement, “We shouldn’t interview anyone who has ‘architect’ on his resume.” At first blush, this was an odd turn of phrase, because we usually introduce Dave as one of our leading architects. The reason for his title schizo- phrenia is the fact that, even by our industry’s standards, “architect” and “architecture” are terribly overloaded words. For many, the term “software architect” fits per- fectly with the smug controlling im- age at the end of Matrix Reloaded. Yet even in firms that have the greatest contempt for that image, chitect.) However, as so often occurs, inside the blighted cynicism is a pinch of truth. Un- derstanding came to me after reading a posting from Ralph Johnson on the Extreme Program- ming mailing list. It’s so good I’ll quote it all. A previous posting said The RUP, working off the IEEE definition, defines architecture as “the highest level concept of a sys- tem in its environment. The architecture of a soft- ware system (at a given point in time) is its orga- nization or structure of significant components interacting through interfaces, those components being composed of successively smaller compo- nents and interfaces.” Johnson responded: I was a reviewer on the IEEE standard that used Who Needs an Architect? Martin Fowler IUUQTNBSUJOGPXMFSDPNJFFF4PGUXBSFXIP/FFET"SDIJUFDUQEG
  2. lʜΞʔΩςΫνϟ͸ɺιϑτ΢ΣΞ͚ͩʹґଘ͍ͯ͠ΔΘ͚Ͱ ͸͋Γ·ͤΜɻιϑτ΢ΣΞͷͲͷ෦෼ΛॏཁͱΈͳ͔͢ͱ͍͏ ूஂͷ߹ҙʹ΋ґଘ͠·͢ɻΑͬͯɺΞʔΩςΫνϟͱ͸ࣾձత ߏங෺ͳͷͰ͢ʢ·͋ɺιϑτ΢ΣΞ΋ͦ͏Ͱ͕͢ɺΞʔΩςΫ νϟ͸͞Βʹͦ͏Ͱ͢ʣɻʜ 2 IEEE SOFTWARE Published by

    the IEEE Computer Society 0740-7459/03/$17.00 © 2003 IEEE Wandering down our corridor a while ago, I saw my colleague Dave Rice in a particularly grumpy mood. My brief question caused a violent statement, “We shouldn’t interview anyone who has ‘architect’ on his resume.” At first blush, this was an odd turn of phrase, because we usually introduce Dave as one of our leading architects. The reason for his title schizo- phrenia is the fact that, even by our industry’s standards, “architect” and “architecture” are terribly overloaded words. For many, the term “software architect” fits per- fectly with the smug controlling im- age at the end of Matrix Reloaded. Yet even in firms that have the greatest contempt for that image, there’s a vital role for the technical leadership that an architect such as Dave plays. What is architecture? When I was fretting over the title for Pat- terns of Enterprise Application Architecture (Addison-Wesley, 2002), everyone who re- viewed it agreed that “architecture” belonged in the title. Yet we all felt uncomfortable defin- ing the word. Because it was my book, I felt compelled to take a stab at defining it. My first move was to avoid fuzziness by just letting my cynicism hang right out. In a sense, I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important. (Yes, you can imagine a similar phenomenon for ar- chitect.) However, as so often occurs, inside the blighted cynicism is a pinch of truth. Un- derstanding came to me after reading a posting from Ralph Johnson on the Extreme Program- ming mailing list. It’s so good I’ll quote it all. A previous posting said The RUP, working off the IEEE definition, defines architecture as “the highest level concept of a sys- tem in its environment. The architecture of a soft- ware system (at a given point in time) is its orga- nization or structure of significant components interacting through interfaces, those components being composed of successively smaller compo- nents and interfaces.” Johnson responded: I was a reviewer on the IEEE standard that used that, and I argued uselessly that this was clearly a completely bogus definition. There is no high- est level concept of a system. Customers have a different concept than developers. Customers do not care at all about the structure of significant components. So, perhaps an architecture is the highest level concept that developers have of a system in its environment. Let’s forget the devel- opers who just understand their little piece. Ar- chitecture is the highest level concept of the ex- pert developers. What makes a component significant? It is significant because the expert developers say so. So, a better definition would be “In most successful software projects, the expert developers working on that project have a shared understanding of the design Who Needs an Architect? Martin Fowler E d i t o r : M a r t i n F o w l e r I T h o u g h t Wo r k s I f o w l e r @ a c m . o r g
  3. ୈ**෦ΞʔΩςΫνϟελΠϧ ɾϨΠϠʔυΞʔΩςΫνϟ ɾύΠϓϥΠϯΞʔΩςΫνϟ ɾϚΠΫϩΧʔωϧΞʔΩςΫνϟ ɾαʔϏεϕʔεΞʔΩςΫνϟ ɾΠϕϯτۦಈΞʔΩςΫνϟ ɾεϖʔεϕʔεΞʔΩςΫνϟ ɾΦʔέετϨʔγϣϯۦಈαʔϏεࢦ޲ΞʔΩςΫνϟ ɾϚΠΫϩαʔϏεΞʔΩςΫνϟ ɾద੾ͳΞʔΩςΫνϟελΠϧΛબͿ

    ୈ*෦جૅ ɾΞʔΩςΫνϟࢥߟ ɾϞδϡʔϧੑ ɾΞʔΩςΫνϟಛੑ ɾΞʔΩςΫνϟಛੑΛ໌Β͔ʹ͢Δ ɾΞʔΩςΫνϟಛੑͷܭଌͱ౷੍ ɾΞʔΩςΫνϟಛੑͷείʔϓ ɾίϯϙʔωϯτϕʔεࢥߟ ʰιϑτ΢ΣΞΞʔΩςΫνϟͷجૅʱ ୈ***෦ςΫχοΫͱιϑτεΩϧ ɾΞʔΩςΫνϟܾఆ ɾΞʔΩςΫνϟ্ͷϦεΫΛ෼ੳ͢Δ ɾΞʔΩςΫνϟͷਤղ΍ϓϨθϯςʔγϣϯ ɾޮՌతͳνʔϜʹ͢Δ ɾަবͱϦʔμʔγοϓͷεΩϧ ɾΩϟϦΞύεΛ։͘
  4. ඼࣭ಛੑͷ۩ମྫ Մ༻ੑ "WBJMBCJMJUZ ৴པੑ 3FMJBCJMJUZ ςετੑ 5FTUBCJMJUZ εέʔϥϏϦςΟ 4DBMBCJMJUZ ηΩϡϦςΟ

    4FDVSJUZ อकੑ .BJOUBJOBCJMJUZ σϓϩΠੑ %FQMPZBCJMJUZ ଱ো֐ੑ 'BVMU5PMFSBODF ஄ྗੑ &MBTUJDJUZ ύϑΥʔϚϯε 1FSGPSNBODF ճ෮ੑ 3FDPWFSBCJMJUZ ֶश༰қੑ -FBSOBCJMJUZ ΞδϦςΟ "HJMJUZ ݎ࿚ੑ 3PCVTUOFTT ߹๏ੑ -FHBM ϢʔβϏϦςΟ 6TBCJMJUZ ߏ੒༰қੑ $PO fi HVSBCJMJUZ ֦ுੑ &YUFOTJCJMJUZ ࠶ར༻ੑ 3FVTF Մ؍ଌੑ 0CTFSWBCJMJUZ ʜ ʜ ʜ ʜ ʜ
  5. Wandering down our corridor a while ago, I saw my

    colleague Dave Rice in a particularly grumpy mood. My brief question caused a violent statement, “We shouldn’t interview anyone who has ‘architect’ on his resume.” At first blush, this was an odd turn of phrase, because we usually introduce Dave as one of our leading architects. The reason for his title schizo- phrenia is the fact that, even by our industry’s standards, “architect” and “architecture” are terribly overloaded words. For many, the term “software architect” fits per- fectly with the smug controlling im- age at the end of Matrix Reloaded. Yet even in firms that have the greatest contempt for that image, chitect.) However, as so often occurs, inside the blighted cynicism is a pinch of truth. Un- derstanding came to me after reading a posting from Ralph Johnson on the Extreme Program- ming mailing list. It’s so good I’ll quote it all. A previous posting said The RUP, working off the IEEE definition, defines architecture as “the highest level concept of a sys- tem in its environment. The architecture of a soft- ware system (at a given point in time) is its orga- nization or structure of significant components interacting through interfaces, those components being composed of successively smaller compo- nents and interfaces.” Johnson responded: I was a reviewer on the IEEE standard that used Who Needs an Architect? Martin Fowler IUUQTNBSUJOGPXMFSDPNJFFF4PGUXBSFXIP/FFET"SDIJUFDUQEG
  6. ʜʮ΄ͱΜͲͷ੒ޭ͢Διϑτ΢ΣΞϓϩδΣΫτͰ͸ɺͦͷϓϩ δΣΫτʹܞΘΔઐ໳Ոͷ։ൃऀ͸ɺγεςϜઃܭͷڞ௨ͷཧղΛ ͍࣋ͬͯ·͢ɻ͜ͷڞ௨ͷཧղΛɺʰΞʔΩςΫνϟʱͱݺͿͷͰ ͢ɻ͜ͷཧղʹ͸ɺγεςϜ͕ͲͷΑ͏ʹίϯϙʔωϯτʹ෼ׂ͞ ΕΔ͔ɺίϯϙʔωϯτ͕ΠϯλϑΣʔεΛհͯ͠ͲͷΑ͏ʹର࿩ ͢Δؚ͔͕·Ε·͢ɻ 2 IEEE SOFTWARE Published

    by the IEEE Computer Society 0740-7459/03/$17.00 © 2003 IEEE Wandering down our corridor a while ago, I saw my colleague Dave Rice in a particularly grumpy mood. My brief question caused a violent statement, “We shouldn’t interview anyone who has ‘architect’ on his resume.” At first blush, this was an odd turn of phrase, because we usually introduce Dave as one of our leading architects. The reason for his title schizo- phrenia is the fact that, even by our industry’s standards, “architect” and “architecture” are terribly overloaded words. For many, the term “software architect” fits per- fectly with the smug controlling im- age at the end of Matrix Reloaded. Yet even in firms that have the greatest contempt for that image, there’s a vital role for the technical leadership that an architect such as Dave plays. What is architecture? When I was fretting over the title for Pat- terns of Enterprise Application Architecture (Addison-Wesley, 2002), everyone who re- viewed it agreed that “architecture” belonged in the title. Yet we all felt uncomfortable defin- ing the word. Because it was my book, I felt compelled to take a stab at defining it. My first move was to avoid fuzziness by just letting my cynicism hang right out. In a sense, I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important. (Yes, you can imagine a similar phenomenon for ar- chitect.) However, as so often occurs, inside the blighted cynicism is a pinch of truth. Un- derstanding came to me after reading a posting from Ralph Johnson on the Extreme Program- ming mailing list. It’s so good I’ll quote it all. A previous posting said The RUP, working off the IEEE definition, defines architecture as “the highest level concept of a sys- tem in its environment. The architecture of a soft- ware system (at a given point in time) is its orga- nization or structure of significant components interacting through interfaces, those components being composed of successively smaller compo- nents and interfaces.” Johnson responded: I was a reviewer on the IEEE standard that used that, and I argued uselessly that this was clearly a completely bogus definition. There is no high- est level concept of a system. Customers have a different concept than developers. Customers do not care at all about the structure of significant components. So, perhaps an architecture is the highest level concept that developers have of a system in its environment. Let’s forget the devel- opers who just understand their little piece. Ar- chitecture is the highest level concept of the ex- pert developers. What makes a component significant? It is significant because the expert developers say so. So, a better definition would be “In most successful software projects, the expert developers working on that project have a shared understanding of the design Who Needs an Architect? Martin Fowler E d i t o r : M a r t i n F o w l e r I T h o u g h t Wo r k s I f o w l e r @ a c m . o r g
  7. ͞·͟·ͳࢹ఺͔ΒγεςϜͷߏ଄Λݕ౼͢Δ γφϦΦ ࿦ཧϏϡʔ ϓϩηεϏϡʔ ࣮૷Ϗϡʔ σϓϩΠϝϯτϏϡʔ ݕূ ؔ࿈ ந৅֓೦ͷߏ଄ ɾϞδϡʔϧߏ଄

    ɾ࿦ཧσʔλϞσϧ ɾʜ ιϑτ΢ΣΞϞδϡʔϧͷߏ੒؅ཧ ɾσΟϨΫτϦߏ଄ ɾϦϙδτϦߏ଄ ɾϏϧυ୯Ґ ɾ෺ཧσʔλϞσϧ ࣮ߦ࣌ͷߏ଄ ɾ௨৴ߏ଄ ɾʜ σϓϩΠߏ଄ ɾσϓϩΠϝϯτύΠϓϥΠϯ ɾΠϯϑϥߏ଄ ɾʜ ̐ʴ̍Ϗϡʔ
  8. ͞·͟·ͳࢹ఺͔ΒγεςϜͷߏ଄Λݕ౼͢Δ γφϦΦ ࿦ཧϏϡʔ ϓϩηεϏϡʔ ࣮૷Ϗϡʔ σϓϩΠϝϯτϏϡʔ ݕূ ؔ࿈ ந৅֓೦ͷߏ଄ ɾϞδϡʔϧߏ଄

    ɾ࿦ཧσʔλϞσϧ ɾʜ ࣮ߦ࣌ͷߏ଄ ɾ௨৴ߏ଄ ɾʜ σϓϩΠߏ଄ ɾσϓϩΠϝϯτύΠϓϥΠϯ ɾ෺ཧߏ଄ ɾʜ ̐ʴ̍Ϗϡʔ ͢΂ͯͷϏϡʔΛԣஅͯ͠ઃܭͷ੔߹ੑΛऔΓͳ͕Βߏ଄Λܾఆ͍ͯ͘͠ ιϑτ΢ΣΞϞδϡʔϧͷߏ੒؅ཧ ɾσΟϨΫτϦߏ଄ ɾϦϙδτϦߏ଄ ɾϏϧυ୯Ґ ɾ෺ཧσʔλϞσϧ
  9. ඼࣭ಛੑͷ۩ମྫ Մ༻ੑ "WBJMBCJMJUZ ৴པੑ 3FMJBCJMJUZ ςετੑ 5FTUBCJMJUZ εέʔϥϏϦςΟ 4DBMBCJMJUZ ηΩϡϦςΟ

    4FDVSJUZ อकੑ .BJOUBJOBCJMJUZ σϓϩΠੑ %FQMPZBCJMJUZ ଱ো֐ੑ 'BVMU5PMFSBODF ஄ྗੑ &MBTUJDJUZ ύϑΥʔϚϯε 1FSGPSNBODF ճ෮ੑ 3FDPWFSBCJMJUZ ֶश༰қੑ -FBSOBCJMJUZ ΞδϦςΟ "HJMJUZ ݎ࿚ੑ 3PCVTUOFTT ߹๏ੑ -FHBM ϢʔβϏϦςΟ 6TBCJMJUZ ߏ੒༰қੑ $PO fi HVSBCJMJUZ ֦ுੑ &YUFOTJCJMJUZ ࠶ར༻ੑ 3FVTF Մ؍ଌੑ 0CTFSWBCJMJUZ ʜ ʜ ʜ ʜ ʜ
  10. ͞·͟·ͳࢹ఺͔ΒγεςϜͷߏ଄Λݕ౼͢Δ γφϦΦ ࿦ཧϏϡʔ ϓϩηεϏϡʔ ࣮૷Ϗϡʔ σϓϩΠϝϯτϏϡʔ ݕূ ؔ࿈ ந৅֓೦ͷߏ଄ ɾϞδϡʔϧߏ଄

    ɾ࿦ཧσʔλϞσϧ ɾʜ ࣮ߦ࣌ͷߏ଄ ɾ௨৴ߏ଄ ɾʜ σϓϩΠߏ଄ ɾσϓϩΠϝϯτύΠϓϥΠϯ ɾ෺ཧߏ଄ ɾʜ ̐ʴ̍Ϗϡʔ ͢΂ͯͷϏϡʔΛԣஅͯ͠ઃܭͷ੔߹ੑΛऔΓͳ͕Βߏ଄Λܾఆ͍ͯ͘͠ ιϑτ΢ΣΞϞδϡʔϧͷߏ੒؅ཧ ɾσΟϨΫτϦߏ଄ ɾϦϙδτϦߏ଄ ɾϏϧυ୯Ґ ɾ෺ཧσʔλϞσϧ
  11. ॻ੶ɿ w ʰιϑτ΢ΣΞΞʔΩςΫνϟͷجૅʱʢΦϥΠϦʔδϟύϯʣ w ʰ%FTJHO*UʱʢΦϥΠϦʔδϟύϯʣ w ʰϞϊϦε͔ΒϚΠΫϩαʔϏε΁ʱʢΦϥΠϦʔδϟύϯʣ w ʰΤϥεςΟοΫϦʔμʔγοϓʱʢΦϥΠϦʔδϟύϯʣ w

    ʰਐԽతΞʔΩςΫνϟʱʢΦϥΠϦʔδϟύϯʣ w ʰιϑτ΢ΣΞΞʔΩςΫνϟϋʔυύʔπʱʢΦϥΠϦʔδϟύϯʣ w ʰ࣮ફιϑτ΢ΣΞΞʔΩςΫνϟʱʢ೔ץ޻ۀ৽ฉࣾʣ w ʰ$MFBO"HJMFجຊʹཱͪ໭Εʱʢ,"%0,"8"ʣ w ʰ+VTU&OPVHI4PGUXBSF"SDIJUFDUVSFʱʢ.BSTIBMM#SBJOFSEʣ w ʰ$POUJOVPVT4PGUXBSF"SDIJUFDUVSFʱʢ"EEJTPO8FTMFZ1SPGFTTJPOBMʣ w ʰ5IF%FW0QTϋϯυϒοΫʱʢ೔ܦ#1ࣾʣ 8FCɿ w ͭͳ͕Δੈքͷιϑτ΢ΣΞ඼࣭ΨΠυɹ͋ͨΒ͍͠Ձ஋ఏڙͷͨΊͷ඼࣭Ϟσϧ׆༻ͷ͢͢ΊIUUQTXXXJQBHPKQQVCMJTIUOIUNM w 5IF$MFBO"SDIJUFDUVSFc5IF$MFBO$PEF#MPHIUUQTCMPHDMFBODPEFSDPNVODMFCPCUIFDMFBOBSDIJUFDUVSFIUNM w 8IP/FFETBO"SDIJUFDUIUUQTNBSUJOGPXMFSDPNJFFF4PGUXBSFXIP/FFET"SDIJUFDUQEG w .JOJNVN7JBCMF"SDIJUFDUVSFŠ(PPE&OPVHIJT(PPE&OPVHIJOB4UBSUVQIUUQTXXXTMJEFTIBSFOFU3BOEZ4IPVQNJOJNVNWJBCMF BSDIJUFDUVSFHPPEFOPVHIJTHPPEFOPVHIJOBTUBSUVQ w ʰεύΠμʔϚϯɿΞΫϩεɾβɾεύΠμʔόʔεʱ༧ࠂ̍IUUQTXXXZPVUVCFDPNXBUDI W*8S64D@S&KL ࢀߟจݙ