Z zamiarem napisania tego tekstu noszę się już od kilku lat i za każdym razem mówiłem sobie: “ok, jeszcze tylko skończę ten jeden projekt i zobaczymy czy faktycznie ma to sens”. I tak od kilku lat. W końcu jednak udało się.

Wprowadzenie

Popularność podejścia do modeli procesów biznesowych, polegającego na “pokazaniu różnicy”, trwa od czasów popularyzacji re-inżynierii procesów biznesowych (lata 90-te) . Umowy na usługi, zawierające w zakresie opracowanie modelu ‘as-is’ i ‘to-be’ nadal są podpisywane. Zakładam, że decyzje o zakresie projektu to indywidualne potrzeby zamawiających. Ja opiszę swoje doświadczenia i wnioski.

Głównym deklarowanym celem tworzenia obu tych modeli jest zawsze porównanie stanu obecnego i planowanego, a następnie zdecydowanie o tym ‘co dalej’. Zakłada się, że te modele powinny pokazać wartość dodaną projektowanych zmian. Pierwszy problem to konieczność stworzenia dwukrotnie większej ilości dokumentacji, to zaś przekłada sie na czas i koszt. W konsekwencji wdrożenie planowanej zmiany bardzo odsuwa się w czasie. Wynik każdej pierwotnie wykonanej analizy dezaktualizuje się wraz z upływem czasu, tym szybciej im więcej szczegółów ona zawiera. Wpadamy tu w ‘kwadraturę koła’. W artykule Cykl życia… zapytałem: Czego oczekuje biznes: efektu czy produktu? Wyniki analiz i rekomendacje to produkty pracy analityka, wdrożone zmiany organizacyjne czy oprogramowanie to także produkty. Te zawsze można kupić i mieć. A czym jest efekt? Np. zwiększeniem efektywności… A to oznacza, że etap analizy i potem wdrażania rozwiązania, także powinien cechować się efektywnością!

W czasach zmian rynkowych zachodzących w okresie poniżej roku, każda strata czasu jest szkodą, dwukrotne wydłużenie procesu analizy i opracowania rekomendacji szczególnie.

Więc jak, skoro nie dwa modele: ‘as-is’ i ‘to-be’?

Metody

Tu posłużę się prostymi metodami czyli schematy blokowe i rzadko stosowana a bardzo skuteczna: idealizacja . Nawiążę także do mało popularnej a ciekawej i bardzo skutecznej metodyki usprawniania organizacji, także opartej na idealizacji, opisanej przez Ackof’a .

Rezultaty

Kluczem skutecznego planowania rozwoju organizacji jest studium wykonalności planowanych zmian, a do tego bardzo przydatna jest idealizacja jako metoda.

Wytyczenie kierunku działań

Każda organizacja kiedyś powstała i od tego momentu zaczyna żyć (co – uwaga – nie jest tożsame z jej rozwojem). Jeżeli podejmujemy decyzję o wprowadzaniu zmiany (a na początku raczej tylko deklarujemy taki zamiar) pierwszymi rzeczami jakie należy określić są: cel i kierunek zmian. Jak już to wiemy, kolejnym krokiem jest określenie tego co i w jakim czasie chcemy osiągnąć. Pamiętajmy, że ideał może nie być osiągalny, jest jednak zawsze doskonałym wyznacznikiem kierunku (podobnie jak rekordy olimpijskie dla sportowców, którzy wiedzą, że nigdy ich nie przekroczą, ale mimo to wiedzą co i po co trenować). Dlaczego? Bo kluczową wiedzą jest zawsze to, ile mnie dzieli od ideału i czy jest sens go osiągać, bo rozwiązania powinny być wystarczającą dobre, a nie zawsze najlepsze (co najwyżej możliwie najlepsze).

Projektowanie ideału jest takim sposobem myślenia o zmianie, który można przedstawić w prosty sposób: w rozwiązywaniu problemów, praktycznie dowolnego rodzaju, można uzyskać najlepsze wyniki dzięki wyobrażeniu sobie idealnego rozwiązania, a następnie cofnięciu się aż do miejsca, w którym znajdujesz się w chwili obecnej. Dzięki temu unikniesz urojonych przez siebie przeszkód, zanim jeszcze w ogóle pojmiesz, jak osiągnąć ideał.

Poniższy diagram pokazuje kluczowe punkty planu:

I teraz: Czy dokładny opis stanu aktualnego jest potrzebny, skoro kluczowe pytanie zawsze brzmi: co zmienić? Sprawdźmy.

Wyobraźmy sobie, że robimy porządki w starej piwnicy a celem jest pozbycie się rzeczy niepotrzebnych. Identyczną sytuację mamy z plecakiem, gdy dość regularnie wyjeżdżamy np. w góry, nie chcemy jednak nosić zbędnych rzeczy. Są dwa możliwe podejścia do tego zadania:

  1. przeglądamy wszystko i zastanawiamy się czego się pozbyć,
  2. odkładamy wszystko na bok, i wybieramy tylko to o czym wiemy, że na pewno nadal będzie potrzebne i wiemy do czego, reszta zostaje (z piwnicy: wyrzucona).

Można próbować bronić każdej z tych metod, problem w tym, że pierwsza powoduje (praktyka to pokazuje), że zawsze zostaje prawie wszystko, a przybywa nowego.

Modelowanie organizacji

Natura człowieka to emocjonalne przywiązanie do tego co się już posiada, a z naturą (emocje) trudno walczyć. Dlatego warto czasami ją wspomagać (z tego samego powodu nie należy samemu negocjować tego co jest dla nas bardzo ważne, a jak musimy to robić sami, to należy zrezygnować z negocjacji i z góry ustalić korzystne warunki lub zrezygnować ).

Popatrzmy na znany, nie tylko moim czytelnikom, od lat diagram:

(źr.

Pokazuje on trzy podstawowe poziomy opisu (dokumentowania) organizacji. Najwyższy poziom to model biznesowy, czyli opis strategii (z reguły mieści się na jednej stronie maszynopisu). Najniższy to szczegółowe opisy wymaganych kompetencji, zakresy obowiązków, instrukcje stanowiskowe, procedury i zarządzenia, instrukcje itp. Te dwa rodzaje opisów ma praktycznie każda organizacja bo nawet, jeżeli nie wymaga tego prawo, to wymagają tego podstawy zarządzania.

Środkowa warstwa to coś, czego większość organizacji nadal nie ma, bo uważają że nie jest to potrzebne do bieżącego, operacyjnego zarządzania. Czym jest ten środkowy model? To jest tak zwany wewnętrzny łańcuch wartości organizacji, czyli opis tego jak powstają jej produkty i usługi, i jaką poszczególne prace wnoszą wartość dodaną do całości . Dokumentujemy go jako Model (mapa) Procesów Biznesowych, jest to abstrakcyjny model, pozbawiony szczegółów, pokazuje to ‘co’ robimy i po co a nie ‘jak’. Warto tu zwrócić uwagę na ważną rzecz:

Nie ma żadnego sensu odwzorowywanie na schematach blokowych szczegółów trzeciej najniższej warstwy, bo powstają monstrualne liczby diagramów, które niczego nie wnoszą do projektu, bo ich przydatność jest co najmniej wątpliwa.

To ‘jak’ to robimy zawiera posiadana już dokumentacja w warstwie trzeciej, najniższej; nie ma więc sensu powtórne jej dokumentowanie na diagramach, powołujemy się na nią modelując procesy (więcej w artykule Analiza, wymagania i usprawnianie organizacji).

Czy warto mieć taki model procesów? Owszem, bo podejmowanie decyzji o zmianach bez takiego modelu to loteria. Jednak jeżeli model jest zbyt szczegółowy (patrz powyższa uwaga), to nie tylko opracowanie go jest kosztowne i trwa długo, ale zapoznanie się z nim zajmuje zbyt dużo czasu, więc nikt tego nie robi. W efekcie decyzje są podejmowane tak, jak by tego modelu nie było. Kiedyś decyzje o zmianach podejmowano rzadko i każdorazowe, poprzedzające te decyzje długie analizy, miały sens. Obecnie decyzje takie podejmujmy nie raz ‘znienacka”, i nawet jeżeli nie są częste, to nie ma czasu na poprzedzanie ich analizami, a bez analizy skutków decyzje operacyjne są loterią. W efekcie utrzymywanie aktualnego, ale bez zbędnych detali, modelu organizacji jest możliwe, opłacalne i ma ogromne znaczenie (patrz Audyt organizacji, model Architektury Korporacyjnej).

Poprawnie opracowane modele (mapy) procesów biznesowych pozwalają zrozumieć organizację i przewidywać efekty planowanych zmian.

(patrz: Audyt organizacji, podnoszenie efektywności)

Wdrażanie zmian

Popatrzmy na poniższy diagram:

(J. Żeliński, 2012)

Rozwój organizacji, poza bardzo rzadkimi przypadkami, nie jest (nie powinien być) rewolucją. Pisali o tym nie raz krytycy przywoływanej na początku Radykalnej Reorganizacji Procesów Biznesowych (mało która organizacja ją przetrwała) . Więc co zmieniać i jak? Powyższy diagram mówi, że generalnie zmiany dotyczą najniższej warstwy, ale żeby wiedzieć gdzie jest jej granica, trzeba mieć udokumentowaną także tę środkową. Zmiany procesów biznesowych są rzadkie, dotyczą pojedynczych procesów, i nie są to rewolucje.

Przejście od lewej do prawej strony to nasz plecak w góry: albo przeglądamy wszystko i próbujemy odrzucać nadmiar, albo wybieramy tylko to, o czym wiemy że będzie potrzebne. Skąd mamy wiedzieć, co będzie potrzebne? Jeżeli wykonamy model procesów biznesowych jako model wewnętrznego łańcucha wartości, to znaczy, że doskonale wiemy co i po co robimy, pozostaje jedynie określenie tego jak. I tu właśnie pojawia się moment, w którym określamy jak coś zrobić najlepiej, a potem patrzymy czy to jak to teraz robimy jest takie jak być powinno. Jeżeli tak, kontynuujemy (zabieramy to ze sobą w kolejną podróż), jeżeli nie – zarzucamy i staje sie to wymaganiem, wobec nowego rozwiązania (bez rozpamiętywania historii, sentymenty niestety zniszczyły już niejedną firmę).

W projekcie analizy i usprawnienia powstają więc:

  1. Dokumentacja rynkowego modelu biznesowego, czyli opis strategii (w tym także misja i wizja organizacji).
  2. Model motywacji biznesowej planowanych zmian (wytyczamy kierunek).
  3. Model procesów biznesowych jako model wewnętrznego łańcucha wartości (to jest kilkanaście diagramów a nie kilkaset!).
  4. Analiza przetwarzanych informacji i jej standaryzacja (analiza dokumentów, biznesowy słownik pojęć, reguły biznesowe, standaryzacja treści dokumentów, są to produkty aktywności na modelach procesów).
  5. Wymagania biznesowe (czym ma się charakteryzować nowe rozwiązanie).
  6. Opis (model) rozwiązania, stanowiący sobą tak na prawdę wymaganie dla jego dostawcy (wykonawcy).

Jeżeli pozbędziemy sie nadmiarowych, o wątpliwej wartości dodanej dla tego projektu, prac, to całość trwa od dwóch do sześciu miesięcy, zależnie od wielkości organizacji. W dużych organizacjach łatwo jest podzielić modele na dziedzinowe obszary, w których wdraża się lokalne samodzielne rozwiązania, wystarczy zaplanować ich integrację. Mając model informacyjny (dokumenty i ich wzajemne zależności) nie jest to trudne. Wbrew temu co mówią, dostawcy kompleksowych monolitycznych systemów, nie jest żadnym ryzykiem to że kilka działów przetwarza te same dane, ważne jest zagwarantowanie standaryzacji tych danych oraz ich nośników czyli dokumentów . Jeżeli bez problemu mogą współpracować ze sobą dwie odrębne firmy, to podobnie mogą to robić wydziały tej samej firmy, tym bardziej że w dowolnym momencie taki wydział może zostać wydzielony jako osobny podmiot, i po tej przemianie to wszystko nadal dalej działać. Włączenie do wnętrza organizacji innej firmy podobnie, nigdy nie powinna to być rewolucja informatyczna i wymiana wszystkiego.

Podsumowanie

Praktyka pokazuje, że powyższe sprawdza sie doskonale. Rezygnacja z detalicznych modeli as-is na najniższym poziomie ww. piramidy, nie przynosi straty jakości projektu, nie podnosi też jego ryzyka, a znakomicie skraca czas i tym samym obniża koszt tego etapu pracy (modelowanie procesów).

Owszem, nie raz na początku słyszałem od sponsora projektu: “chcemy zobaczyć te zmiany, chcemy widzieć różnice”. Jednak oferta wykonania takiej usługi w dwóch wariantach: zawierająca model ‘as-is’ i bez tego modelu (oferta fixed-price bo innych niż umowa o dzieło na tym etapie od lat nie składam: klienci chcą znać koszty przed a nie po projekcie), od kilku lat w 100% przypadków kończy się rezygnacją z dokumentowania detali i modeli procesów “as-is”. Więcej w artykule Audyt organizacji, podnoszenie efektywności.

Uważam, że w czasach gdy “czas to pieniądz”, a czas ten liczymy obecnie w tygodniach a nie w latach, projekty analityczne trwające ponad kwartał (czy pół roku w bardzo dużej organizacji) są stratą czasu i środków.

Kluczowe pytanie na koniec:

Kiedy powstają szczegóły nowego rozwiązania? W toku projektowania i wdrożenia…

…i jest to bardzo bezpieczne i zarazem efektywne, bo mając architekturę rozwiązania (wewnętrzny model łańcucha wartości i model architektury rozwiązania) wiemy ‘co’ ma powstać, pozostaje już tylko na bieżąco podejmować decyzje ‘jak’ ma to wyglądać.

Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle ?problemami złośliwymi?. ?Problem złośliwy? to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.

Sprawując ze swojej strony nadzór nad dostawcą rozwiązania, jego nabywca panuje nad wszystkim. Mogę tylko podsumować to tak: to co napisał Ackoff 15 lat temu i ponad 20 lat temu : podejście takie sprawdza sie doskonale.

A co gdy rekomendacje zmian dotyczą środkowej warstwy (wewnętrzny łańcuch procesów)? Wtedy owszem, powstaje model t-bo, jest to rekomendacja, a jej udokumentowanie to jeden diagram…

(tak realizowane były moje projekty dla wielu małych firm, kilku instytucji publicznych, w tym Kancelarii Senatu i Żandarmerii Wojskowej, a także dla KGHM SA)

Źródła

Hepburn, B., & Andersen, H. (2021). Scientific Method. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2021). Metaphysics Research Lab, Stanford University. https://plato.stanford.edu/archives/sum2021/entries/scientific-method/
Ozkaya, M. (2023, April 9). Microservices Architecture. Design Microservices Architecture with Patterns & Principles. https://medium.com/design-microservices-architecture-with-patterns/microservices-architecture-2bec9da7d42a
Weiss, M., & Hari, A. (2004). ICDM - an Integrated Methodology for the Conceptual Design of New Systems. https://www.academia.edu/59514794/ICDM_an_Integrated_Methodology_for_the_Conceptual_Design_of_New_Systems
Włodarska-Dziurzyńska, K. (2012). Pojęcie produktu. Nieuczciwe praktyki rynkowe : ocena regulacji, 141–143. https://ruj.uj.edu.pl/server/api/core/bitstreams/c5d331c9-8945-4f12-9a9b-12eddee0be30/content
Mahesh, B. (2019). Machine Learning Algorithms -A Review. https://doi.org/10.21275/ART20203995
Martin, R. C., & Martin, R. C. (2018). Clean architecture: a craftsman’s guide to software structure and design. Prentice Hall.
Foote, B., & Yoder, J. (1997). Big Ball of Mud. Department of Computer Science University of Illinois at Urbana-Champaign 1304 W. Springfield Urbana, IL 61801 USA. https://www.researchgate.net/publication/2938621_Big_Ball_of_Mud
Alencar, F. (2000). Closing the GAP between organizational requirements and object oriented modeling. Journal of the Brazilian Computer Society. https://www.academia.edu/83364710/Closing_the_GAP_between_organizational_requirements_and_object_oriented_modeling
Rumpe, B. (2007). Model-driven development of complex software: A research roadmap. https://www.academia.edu/16456630/Model_driven_development_of_complex_software_A_research_roadmap
Harmon, P. (2010, December 14). What is a Business Process. BPTrends, 8(21), 6. http://www.bptrends.com/publicationfiles/advisor20101214.pdf
Harmon, P., & Garcia, J. (2020). The States of the Business Process Management Process 2020 (No. 2020). BP Trends Associations. www.bptrends.com
Harmon, P. (2016). The State of Business Process Management 2016. BT Trends. https://www.club-bpm.com/Contenido/Estudios/BPT-Survey-Report.pdf
Nanayakkara, C. (2023, July 7). Microservices Patterns: The Saga Pattern. Cloud Native Daily. https://medium.com/cloud-native-daily/microservices-patterns-part-04-saga-pattern-a7f85d8d4aa3
Gaiardelli, S., Spellini, S., Panato, M., Tadiello, C., Lora, M., Cheng, D. S., & Fummi, F. (2024). Enabling Service-oriented Manufacturing through Architectures, Models and Protocols. IEEE Access, 1–1. https://doi.org/10.1109/ACCESS.2024.3385634
Huang, S.-C. (2006). A semiotic view of information: Semiotics as a foundation of LIS research in information behavior. Proceedings of the American Society for Information Science and Technology, 43(1), 1–17. https://doi.org/10.1002/meet.1450430166
Nuninger, L., Verhagen, P., Libourel, T., Opitz, R., Rodier, X., Laplaige, C., Fruchart, C., Leturcq, S., & Levoguer, N. (2020). Linking Theories, Past Practices, and Archaeological Remains of Movement through Ontological Reasoning. Information, 11, 338. https://doi.org/10.3390/info11060338
Machado, I. (2015). Graphic argumentation: diagrammatic modeling in the communication of science. Communicating and Evaluating Science. Covilhã: Labcom, 177–202. https://www.researchgate.net/profile/Catarina_Gracio_De_Moura/publication/324314608_Communicating_and_Evaluating_Science/links/5c6485c8299bf1d14cc4bc1c/Communicating-and-Evaluating-Science.pdf#page=181
Machado, I. (n.d.). Graphic argumentation: diagrammatic modeling in the. Communication and Evaluating Science, 177–202. Retrieved April 11, 2024, from https://www.academia.edu/download/92934020/Irene_Machado.pdf
Jerzy Zajadło. (2019). Banał formuły “dura lex sed lex.” Banał formuły “dura lex sed lex,” R. 64, nr 5, 5–12. https://palestra.pl/pl/czasopismo/wydanie/5-2019/artykul/banal-formuly-dura-lex-sed-lex
Korycka-Zirk, M., & Dobrzeniecki, K. (2018). Logika dla prawników: kompendium i zadania (Wydanie II rozszerzone). Towarzystwo Naukowe Organizacji i Kierownictwa “Dom Organizatora.”
Lewandowski, S., & Malinowski, A. (Eds.). (2002). Logika dla prawników. Wydaw. Prawnicze “LexisNexis.”
Lewandowski, S., Machińska, H., Malinowski, A., Petzel, J., & Pełka, M. (Eds.). (2022). Logika dla prawników (Wydanie 13). Wolters Kluwer.
Lewandowski, S., Malinowski, A., & Petzel, J. (Eds.). (2021). Logika dla prawników: słownik encyklopedyczny (3. wydanie zaktualizowane i rozszerzone). Wolters Kluwer.
Friedman, J. (1997). What’s wrong with Libertarianism. Critical Review, 11(3), 407–467. https://doi.org/10.1080/08913819708443469
Singla, A., Nathan, V. T., & Vageesh, S. (2016). Model Based Self‐Learning System Engineering Approach. INCOSE International Symposium, 26(s1), 219–233. https://doi.org/10.1002/j.2334-5837.2016.00327.x
Sarnowski, J. (2022). Podatki w krajach nordyckich a gospodarka i dobrobyt. Doradztwo Podatkowe - Biuletyn Instytutu Studiów Podatkowych, 5(309), 4–14. https://doi.org/10.5604/01.3001.0015.8617
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ideału: kształtowanie przyszłości organizacji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne. https://repozytorium.kozminski.edu.pl/pl/pub/3442
Babalola, V. (2016). Public Private Partnership: Imperative in Educational Planning and Management for Human Security in Nigerian Schools. 6.
Keet, C. M., & Fillottrani, P. R. (2015). An Analysis and Characterisation of Publicly Available Conceptual Models. In P. Johannesson, M. L. Lee, S. W. Liddle, A. L. Opdahl, & Ó. Pastor López (Eds.), Conceptual Modeling (Vol. 9381, pp. 585–593). Springer International Publishing. https://doi.org/10.1007/978-3-319-25264-3_45
Busboom, A. (2024). Automated generation of OPC UA information models — A review and outlook. Journal of Industrial Information Integration, 100602. https://doi.org/10.1016/j.jii.2024.100602
Michalak. (n.d.). Ustawa o prawie autorskim i prawach pokrewnych. Komentarz. Wolters Kluwer. Retrieved March 23, 2024, from https://www.ksiegarnia.beck.pl/media/product_custom_files/1/8/18361-ustawa-o-prawie-autorskim-i-prawach-pokrewnych-komentarz-arkadiusz-michalak-fragment_1.pdf
Brambilla, M., Cabot, J., & Wimmer, M. (2012). Model-driven software engineering in practice. Morgan & Claypool.
Boisot, M., & Canals, A. (2004). Data, information and knowledge: have we got it right? Journal of Evolutionary Economics, 14(1), 43–67. https://doi.org/10.1007/s00191-003-0181-9
Chen, M., Ebert, D., Hagen, H., Laramee, R. S., Van Liere, R., Ma, K.-L., Ribarsky, W., Scheuermann, G., & Silver, D. (2008). Data, information, and knowledge in visualization. IEEE Computer Graphics and Applications, 29(1), 12–19. https://ieeexplore.ieee.org/abstract/document/4736452/
Floridi, L. (2005). Is Semantic Information Meaningful Data? Philosophy and Phenomenological Research, 70(2), 351–370. https://doi.org/10.1111/j.1933-1592.2005.tb00531.x
Zins, C. (2007). Conceptual approaches for defining data, information, and knowledge. Journal of the American Society for Information Science and Technology, 58(4), 479–493. https://doi.org/10.1002/asi.20508
Foehr, M., Vollmar, J., Calà, A., Leitão, P., Karnouskos, S., & Colombo, A. (2017). Engineering of Next Generation Cyber-Physical Automation System Architectures. In Multi-Disciplinary Engineering for Cyber-Physical Production Systems: Data Models and Software Solutions for Handling Complex Engineering Projects (pp. 185–206). https://doi.org/10.1007/978-3-319-56345-9_8
(N.d.).
(N.d.).
Therefore, use a Repository, the purpose of which is to encapsulate all the logic needed to obtain object references. The domain objects won’t have to deal with the infrastructure to get the needed references to other objects of the domain. They will just get them from the Repository and the model is regaining its clarity and focus. (n.d.).
Therefore, a new concept is necessary to be introduced, one that help to encapsulate the process of complex object creation. This is called Factory. Factories are used to encapsulate the knowledge necessary for object creation, and they are especially useful to create Aggregates. When the root of the Aggregate is created, all the objects contained by the Aggregate are created along with it, and all the invariants are enforced. (n.d.).
Therefore, use Aggregates. An Aggregate is a group of associated objects which are considered as one unit with regard to data changes. The Aggregate is demarcated by a boundary which separates the objects inside from those outside. Each Aggregate has one root. The root is an Entity, and it is the only object accessible from outside. The root can hold references to any of the aggregate objects, and the other objects can hold references to each other, but an outside object can hold references only to the root object. If there are other Entities inside the boundary, the identity of those entities is local, making sense only inside the aggregate. (n.d.).
A Service should not replace the operation which normally belongs on domain objects. We should not create a Service for every operation needed. But when such an operation stands out as an important concept in the domain, a Service should be created for it. There are three characteristics of a Service: 1. The operation performed by the Service refers to a domain concept which does not naturally belong to an Entity or Value Object. 2. The operation performed refers to other objects in the domain. 3. The operation is stateless. (n.d.).
Entities are important objects of a domain model, and they should be considered from the beginning of the modeling process. It is also important to determine if an object needs to be an entity or not, which is discussed in the next pattern. (n.d.).
(N.d.).
(N.d.).
However, when domain-related code is mixed with the other layers, it becomes extremely difficult to see and think about. Superficial changes to the UI can actually change business logic. To change a business rule may require meticulous tracing of UI code, database code, or other program elements. Implementing coherent, model-driven objects becomes impractical. (n.d.).
In an object-oriented program, UI, database, and other support code often gets written directly into the business objects. Additional business logic is embedded in the behavior of UI widgets and database scripts. This some times happens because it is the easiest way to make things work quickly. (n.d.).
Patrz architektura heksagonalna. (n.d.).

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.