poniedziałek, 17 kwietnia 2017

Nauka Modelowania Domeny z Programowaniem Funkcyjnym

Co będzie

  • Będzie warsztat FP + modelowanie domeny-> Modelowanie Domeny z FP - część 1 - Oddzielenie biznesu od efektów ubocznych. Najprawdopodobniej 10 maja ale wiele rzeczy się dzieje to i termin może się przesunąć.
  • na podstawie książki
  • w Scali
  • przykłady praktyczne z wykorzystaniem czasem zaawansowanego FP
  • nie będzie hajbernejta ani żadnych frameworków (nazywanych przez ludzi pozbawionych praktyki programistycznej "zrębami"), które gloryfikują kod gdzie jest więcej annotacji niż samego kodu -> czyli czegoś w stylu :
    @ManyToMany
    @JoinTable(
          name="EMP_PROJ",
          joinColumns=@JoinColumn(name="EMP_ID", referencedColumnName="ID"),
          inverseJoinColumns=@JoinColumn(name="PROJ_ID", referencedColumnName="ID"))
    @WhatDoYouMeanByLearnSQL?
    @FuckThoseRelationsOOPUberAlles
    @IJustWantToHaveAListAndCallGetterOnIt
    @IDontCare
    @PleaseDontForceMeToThink
    @MagicalAnnotationToMakeAllProblemsDissapear
    @AndAlsoPleaseHandleTransactionsForMe
    private List projects;
    
    (co w moich oczach przypomina bardziej średniowieczną alchemię gdzie dąży się do takiego dobrania składników by zamienić metal w złoto - w tym przypadku zamienić zwykłą deklarację listy w jakiś twór, który spełni niebanalne wymagania domenowe)

A dokładniej

Traktujac ksiązkę jako kręgosłup nauki pojawia się następujący plan:

  1. Tworzenie danych/aggregatów i oddzielenie operacji domenowych od operacji na efektach infrastruktory - Option,Try,Future,Validation -> i jak map i flatMap pomagają utworzyć przepływ danych
  2. Lenses i kompozycja przekształceń na agregacie danych
  3. Kompozycja operacji na repozytorium przy pomocy Monad Readera
  4. Type classes i monoid - to da wiedzę jak uzyskąć znacznie lepszą kompozycję poprzez definicję symbolicznych operacji dla danego typu
  5. Funktor,Applicative i Monady - jeszcze wiecej wiedzy jak uzyskać lepszą kompozycje funkcji biznesowych poprzez separację efektów ubocznych systemu. Tutja moga sie pojawiać zastosowania dla bardziej specjalistycznych typów jak StateMonad
  6. No i jedziemy dalej z coraz silniejsza kompozycją - tutja będzie tzw. “Kleisli arrow” , która to konstrukcja pozwala komponować typy jak M[A] => M[B] prz pomocy funkcji z efektami A=>M[B]
  7. Wykrywanie naruszeń zasad biznesowych w trakcie kompilacji - typy Fantomowe
  8. Modularyzacja/Bounded Context przy pomocy FreeMonad

Plan można zmieniać wedle upodobań. Formuła to zapewne dwie części z ćwiczeniami. Część pierwsze zajmie się bardziej mechanika używanych konstrukcji FP a druga bardziej zastosowaniem domenowym. No i formułę tez oczywiście można zmienić wedle upodobań. Także (najprawdopodobniej) 10 maja zapraszam kto chętny : Modelowanie Domeny z FP - część 1 - Oddzielenie biznesu od efektów ubocznych

2 komentarze: