هنگامی که صحبت از این می¬شود چگونه یک نرم¬افزار تجاری را طراحی کنیم و از چه الگوهایی استفاده کنیم، این مهم است که تشخیص بدهیم نرم¬افزارهای تجاری همگی متفاوت هستند و این مشکلات متفاوت نیازمند برخوردهای متفاوت هستند. من تعدادی زنگ هشدار دارم و هنگامی که مردم می¬گویند "همیشه این را انجام بده” به صدا در می¬آیند. برای من بیشتر چالش (و علاقه¬مندی) در طراحی، دانش درباره جایگزین¬ها و قضاوت در مورد استفاده از یک جایگزین به جای دیگری است. تعداد زیادی از جایگزین¬ها برای انتخاب از بین آن¬ها وجود دارد، اما من در بین تمام این جایگزین¬ها سه گزینه را انتخاب خواهم کرد.
    یک B2C (business to costumer) فروشگاه آنلاین در نظر بگیرید: مردم با کمی شانس و یک کارت خرید برای خرید جستجو می¬کنند. برای چنین سیستمی ما نیاز به این قابلیت داریم که تعدادی زیادی از کاربران را مدیریت کنیم بنابراین راحل¬مان را نه تنها باید عاقلانه موثر باشد. در مورد منابع استفاده شده باید بصورتی باشد که برای باگذاری بیشتر بتوان با افزایش منابع مشکل را حل کرد. منطق دامنه¬ها برای یک نرم¬افزار باید کاملا قابل فهم باشد: سفارش گرفتن، برخی از محاسبات ساده قیمت گذاری حمل نقل و اطلاعیه¬های حمل و نقل. ما می¬خواهیم هرکسی قادر به دسترسی آسان به سیستم باشد بنابراین این مفهوم بدست می¬آید که بوسیله یک وب¬سایت عمومی ارائه بشود که می¬تواند با طیف وسیعی از مرورگرها مورد استفاده قرار گیرد. منابع داده شامل یگ پایگاه داده برای نگهداری درخواست¬ها و شاید چندین ارتباط با سیستم لیست برای کمک به موجود بودن و ارائه اطلاعات می¬باشد.
    مقایسه کنید این را با یک سیستم که بصورت اتوماتیک پروسه قرارداد اجاره را انجام می¬دهد. از بعضی جهت¬ها این سیستم بسیار ساده¬تر از یک فروشگاه B2C است به این علت تعداد کاربران در یک لحظه زمانی بسیار کمتر از صد نفر است. در حالی که از لحاظ منطق تجاری پیچیده¬تر است. محاسبه ماهانه پرداخت¬ها در یک قرارداد، مدیریت کردن مواردی مانند پرداخت¬های پیش از موعد و قبل از موعد و بررسی اعتبار یکسری از اطلاعات همانند اینکه آیا یک اجاره از قبل رزرو شده است. تمام این¬ها وظایف پیچیده¬ای هستند. از آنجایی که بیشتر رقابت در صنعت اجاره از تنوع محدود قراردادهایی که در گذشته بسته شده¬اند شکل می¬گیرد. یک مدل تجاری پیچیده مانند چیزی که گفته شد بسیار چالش برانگیز است، زیرا قوانین بسیار دلبخواه هستند.
    چنین سیستمی پیچیدگی بیشتری در رابط کاربری (UI) دارد. حداقل به این معنا می¬باشد که از HTML بیشتری استفاده شده است که نشان دهنده یک صحفه پیچده¬تر است. معمولا  سیستم¬هایی که دارای UI با پیچیدگی بالاتری می¬باشند درخواست¬های بیشتری از کاربر دارند که شاید یک با HTML ساده نتوانیم به شکل دلخواه خود در سمت کلاینت برسیم. هرچه تعامل کاربر با سیستم بیشتر شود شرایط برای انجام تراکنش¬های پیچیده¬تر مهیا می¬شود. رزرو یک اجاره ممکن است یک یا دو ساعت طول بکشد در این مدت کاربر در یک تراکنش منطقی قرار دارد. ما همچنین یک طرح پیچیده از پایگاه¬داده که می¬تواند شامل دویست جدول و اتصالاتی به بسته¬ها برای ارزش¬گذاری دارایی و قیمت گذاری است می¬بینیم.

 

    مثال سوم یک سیستم ساده ردیابی هزینه برای یک شرکت کوچک است. چنین سیستمی دارای کابران محدودی می¬باشد. منطق این برنامه ساده است و به راحتی از طریق HTML در شرکت قابل دسترس است. پایگاه¬داده فقط شامل چند جدول می¬باشد. این مورد دارای هیچگونه چالشی نمی¬باشد. این برنامه خیلی سریع باید ساخته شود و همچنین این را باید منظر داشته باشید تعداد افرادی که می¬خواهند بازپرداخت¬ها را محاسبه کنند و این موارد را در سیستم پرداخت حقوق وارد کنند، پیامد مالیت را در نظر داشته باشند، افرادی که برای رئیس دایره مالی گزارش تهیه می¬کنند و ... ممکن است افزایش پیدا کنند. تلاش برای استفاده از معماری برای هر دو سیستم در دو مثال دیگر باعث کاهش سرعت توسعه در این مثال می¬شود. اگر یک سیستم باعث منفعت¬هایی درکسب و کار شود (همانطور که تمام نرم¬افزارهای تجاری به این گونه هستند) تاخیری در این موارد باعث ایجاد هزینه می¬شود. با این حال شما خواهان تصمیماتی در این لحظه نیستید که باعث سخت¬تر شدن رشد در آینده شود. اما باید این را در نظر داشت انعطاف¬پذیری که شما در لحظه می¬خواهید اضافه کنید، اگر نتیجه ندهد، باعث ایجاد پیچیدگی می¬شود که این پیچیدگی می¬تواند ممکن باعث سخت¬تر شدن کارها در آینده بشود و در نتیجه باعث تاخیر در پیشرفت سیستم و گرفتن نتایج مثبت از سیستم شود. اگرچه چنین سیستم¬های کوچک هستند، بیشتر شرکت¬ها دارای تعداد زیادی از آن¬ها هستند بنابراین جمع این اثرات نتیجه تامل برانگیزی خواهد داشت.
    هر سه مثال ما از نرم¬افزارهای تجاری دشواری¬هایی دارند و این دشواری¬ها متفاوت است. در نتیجه شما نمی¬توانید یک معماری کارآمد برای هر سه آن¬ها در نظر بگیرید. انتخاب یک معماری به این معنا می¬باشد، مشکلات ویژه سیستم خود را درک کرده باشید و براساس این ادراک و فهم یک معماری مناسب را انتخاب کنید. به این خاطر است که در این کتاب من یک راه¬حل انحصاری که برای کسب و کار شما مناسب باشد ارائه نمی¬کنم. بجای آن بسیاری از الگوها درباره انتخاب و جایگزین¬ها ارائه می¬گردد. حتی هنگامی که شما یک الگوی خاص را انتخاب می¬کنید آن را با توجه به نیازهای سیستم خود باید اصلاح کنید. شما نمی¬توانید سیستم خود را بدون تامل و تفکر بسازید، تمام چیزی که یک کتاب می¬تواند به شما بدهد اطلاعاتی است که تصمیم خود را براساس آن بگیرید.
    اگر این برروی الگوها تاثیر می¬گذارد، برروی ابزارها هم تاثیر می¬گذارد. اگرچه به نظر می¬رسد انتخاب گروهی کوچکی از ابزارها برای توسعه نرم¬افزار تجاری هوشمندانه است، شما باید این را هم در نظر داشته باشید که ابزار متفاوت برای هدف¬های متفاوت بهترین هستند. بهتر است بدانید استفاده از ابزاری که برای استفاده در موارد دیگری ساخته شده¬اند، نه تنها کمک کننده نیست بلکه باعث بوجود آمدن مشکلاتی می¬شود.