Homogeniczność to inaczej jednorodność lub spójność. Odnosząc się do programowania możemy powiedzieć, że nasza aplikacja jest homogeniczna jeśli jej moduły wyglądają w taki sam sposób: są napisane w jednym języku, wykorzystują jeden framework, mają taką samą architekturę itp. Heterogeniczność nie odnosi się tylko do architektury, ale również do takich aspektów jak nazewnictwo, formatowanie kodu, konwencje itp. Dążenie do 100% homogeniczności nie zawsze powinno być naszym celem i zawsze należy do tego podejść pragmatycznie zachowując równowagę pomiędzy homogenicznością, a jej przeciwieństwem – heterogenicznością.
Zalety homogeniczności
Niewątpliwie zaletą homogeniczności naszego programu jest to, że w bardzo łatwy sposób możemy go rozwijać. Skoro cały system jest napisany w jednym języku, frameworku oraz stylu architektonicznym to jego utrzymanie sprawia nam mniej problemów. Możemy bezproblemowo przerzucać członków zespołu pomiędzy poszczególnymi modułami oraz znacznie łatwiej jest nam znaleźć nowe osoby do naszego zespołu, ponieważ wymagamy mniejszej liczby umiejętności, które są potrzebne do rozwijania oraz utrzymywania naszej aplikacji. Ponadto jeśli zdecydujemy się na architekturę rozproszoną np. mikroserwisy to niektóre komponenty naszego systemu będziemy mogli wykorzystać wielokrotnie np. pipeliny, konfiguracje środowisk itp.
Wady homogeniczności
Homogeniczność systemu nie jest jednak bez wad. Tak jak wcześniej wspomniałem należy znaleźć punkt równowagi pomiędzy homogenicznością, a heterogenicznością. W większości przypadków nie będziemy chcieli, aby nasz system był w 100% spójny. Dlaczego? Ponieważ różne problemy wymagają różnych rozwiązań i czasami ta sztywność systemu wywołana przez zgubne dążenie do spójności może nas znacząco ograniczać. Prowadzi to do tego, że implementacja danego rozwiązania może być trudna i czasochłonna tylko dlatego, że staramy się być spójni. Co więcej takie rozwiązanie może być gorsze od innych lub nawet nie spełniać kryteriów akceptacyjnych ustalonych wspólnie z biznesem. Dlaczego? Dana technologia, architektura czy framework może się w ogólne nie nadawać do rozwiązania naszego problemu. W takim wypadku należało by naruszyć homogeniczność naszego systemu i użyć takiego rozwiązania, które spełnia nasze oczekiwania.