konto usunięte

Temat: Domain-Driven Design i PHP

Witajcie architekci!

Chcialbym zaczac dyskusje na temat Domain-Driven Design i jej implementacji w aplikacjach PHP.

Czy ktos z was to zaimplementowal lub jest w trakcie?
Jaki podzial katalogow uwzgledniliscie?
I jakiego rodzaju DAO uzywacie?

Zapraszam do dyskusji!

konto usunięte

Temat: Domain-Driven Design i PHP

Hej!

Ponieważ nikt nie przyłączył się do dyskusji z ciekawością poczytam jakich rozwiązań ty stosujesz by wcielić DDD w projektach PHPowych.

pzdr
Artur Świerc

Artur Świerc Programista PHP/Java

Temat: Domain-Driven Design i PHP

Paweł Włodarski:
Hej!

Ponieważ nikt nie przyłączył się do dyskusji z ciekawością poczytam jakich rozwiązań ty stosujesz by wcielić DDD w projektach PHPowych.

pzdr

I nici z dyskusji...

Chyba wszystko składa się do tego, co nam oferuje/wymusza dany framework i nikt się nie zastanawia nad tym czy to DDD czy też nie :)
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: Domain-Driven Design i PHP

nas uczyli tego na przedmiocie "Analiza i Projektowanie Systemów Informatycznych", ale niestety nie miałem jeszcze okazji wdrażać tego w życie, jeśli ktoś ma jakieś doświadczenia albo przykłady to chętnie pooglądam/poczytam/posłucham

konto usunięte

Temat: Domain-Driven Design i PHP

Osobiście uważam ,że framework na projekt domeny wpływać nie powinien.

Co do samego DDD to kluczową kwestia wydaje mi się koncepcja "wspólnej płaszczyzny językowej". Swego czasu była taka moda w Javie aby nazwy klas kończyć zarostkiem "bean" co dawało takie twory jak CreditCardBean ( w tłumaczeniu kartokredytofasolka).
Inna kwestią w tym temacie jest nawyk u niektórych programistów aby tworzyć interfejsy w konwencji "INazwaKlasy" zaś implementacje jako "NazwaKlasyImpl" co też według mnie jest jakimś dziwnym wytworem technicznym.
Jest jeszcze kilka ciekawych patentów zaciemniających faktyczną domenę biznesową.

pzdr

konto usunięte

Temat: Domain-Driven Design i PHP

Wojciech Sznapka:
nas uczyli tego na przedmiocie "Analiza i Projektowanie Systemów Informatycznych", ale niestety nie miałem jeszcze okazji wdrażać tego w życie, jeśli ktoś ma jakieś doświadczenia albo przykłady to chętnie pooglądam/poczytam/posłucham

Z ciekawszych książek na które natrafiłem:

"Domain-Driven Design: Tackling Complexity in the Heart of Software
By Eric Evans" - to jest niejako pomysłodawca terminu

"Domain-Driven Design Using Naked Objects"

oraz

"Applying Domain Driven Design and Patterns With Examples in C Sharp and dot.NET"

pzdr
Artur Świerc

Artur Świerc Programista PHP/Java

Temat: Domain-Driven Design i PHP

ja jeszcze dodam blog: http://art-of-software.blogspot.com
Krzysztof Gackowski

Krzysztof Gackowski Senior Software
Developer, Focus
Group, UK

Temat: Domain-Driven Design i PHP

Kilka ciekawych informacji mozna znalezc tutaj:

Domain-Driven Design: Sample Application:
http://blog.fedecarg.com/2009/03/22/domain-driven-desi...

Domain-Driven Design and MVC Architectures
http://blog.fedecarg.com/2009/03/11/domain-driven-desi...

Domain-Driven Design: Data Access Strategies:
http://blog.fedecarg.com/2009/03/12/domain-driven-desi...

Domain-Driven Design: The Repository:
http://blog.fedecarg.com/2009/03/15/domain-driven-desi...

Milego czytania,
Krzysztof Gackowski
http://www.webprogrammer.pl
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Domain-Driven Design i PHP

Ja polecam zajrzeć do grupy http://www.goldenline.pl/forum/projektowanie-i-program... oraz na mój blog - http://blog.wsoczynski.pl/tag/ddd/ . Co do implementacji w PHP, to moim zdaniem sama esencja - obiekty domenowe nie będzie się różnić od innych języków. Różnica leży tylko w warstwie infrastruktury, ja używam do zapisywania encji framework Doctrine 2. Warstwę aplikacyjną (kontroler, widok) tworzy ZF.
Adam Brodziak

Adam Brodziak PHP, football, fun

Temat: Domain-Driven Design i PHP

Jesteśmy w trakcie rozwoju modelu domeny dla kilkunastu sportów na potrzeby nowej platformy. To ciekawe doświadczenie gdy okazuje się jak wiele jest podobieństw nawet w wydawałoby się tak różnych sportach jak golf i Formuła1, szczególnie jeśli chodzi o strukturę rozgrywek. Mamy to szczęście, że deweloperzy są również ekspertami domeny, życie jest przez to znacznie łatwiejsze.

Od strony technicznej podpieramy sie Doctrine2 jako warstwą perzystencji. Skalowanie nadal jest wyzwaniem ze względu na parę braków w obecnej wersji. Propozyje zmian zostały wysłane deweloperom Doctrine. Jeśli chodzi o DAO to przyjęliśmy własne założenia (np. brak zapisu), które pozwoliły uprościć konstrukcję. Co do struktury katalogów to jest ona wtórna względem struktury klas i obiektów (autoloading).
Jakub Zalas

Jakub Zalas Software Engineer,
Symfony Core
Contributor

Temat: Domain-Driven Design i PHP

Doctrine2 nieco brakuje, aby być w pełni "DDD Ready". Trwa dyskusja na ten temat implementacji Value Objects w Doctrine2: http://www.doctrine-project.org/jira/browse/DDC-93
Alan Gabriel B.

Alan Gabriel B. Software Engineer,
IFX

Temat: Domain-Driven Design i PHP

Jakub Zalas:
Doctrine2 nieco brakuje, aby być w pełni "DDD Ready". Trwa dyskusja na ten temat implementacji Value Objects w Doctrine2: http://www.doctrine-project.org/jira/browse/DDC-93

Trwa??

konto usunięte

Temat: Domain-Driven Design i PHP

Adam Brodziak:
Od strony technicznej podpieramy sie Doctrine2 jako warstwą perzystencji.

Warstwa perzystencji - OMG :D

Sorry za OT :)
Adam Brodziak

Adam Brodziak PHP, football, fun

Temat: Domain-Driven Design i PHP

Marcin Olichwirowicz:
Adam Brodziak:
Od strony technicznej podpieramy sie Doctrine2 jako warstwą perzystencji.

Warstwa perzystencji - OMG :D

Sorry za OT :)

Przepraszam, nie wiem jak przetłumaczyć "persistence layer" na polski. Chętnie się dowiem.

Doctrine2 wiele brakuje w porównaniu do JPA, nie mówiąc już o Hibernate. Tak czy inaczej cieszę się, że jest w końcu projekt z silnym zapleczem, który nie jest kolejną implementacją ActiveRecord.

konto usunięte

Temat: Domain-Driven Design i PHP

Adam Brodziak:
Marcin Olichwirowicz:
Adam Brodziak:
Od strony technicznej podpieramy sie Doctrine2 jako warstwą perzystencji.

Warstwa perzystencji - OMG :D

Sorry za OT :)

Przepraszam, nie wiem jak przetłumaczyć "persistence layer" na polski. Chętnie się dowiem.

Chyba najlepiej nie tłumaczyć bo strasznie zabawnie brzmi takie wymyślanie polskich słów na bazie angielskich ;) A jak się powie "warstwa utrwalenia" to nikt nie załapie ;]
Artur Świerc

Artur Świerc Programista PHP/Java

Temat: Domain-Driven Design i PHP

Utrwalanie brzmi bardzo dobrze, spotkałem się z tym terminem w wielu książkach o JPA i Hibernate.

Myślę, że każdy kto pisze w PHP i interesuje go DDD, prędzej czy później chwyci się za Doctrine2. Już po kilku chwilach spędzonych w D2 ciężko wrócić do projektów, które były pisane z naciskiem na bazę. DDD każe skupiać się na obiektach i ich przeznaczeniu, a nie na strukturze bazy i D2 nam to ułatwia.

Polecam fajną prezentację Sławka Sobótki, traktujące o DDD:
http://art-of-software.blogspot.com/2011/02/ddd-we-wro...Artur Świerc edytował(a) ten post dnia 22.05.11 o godzinie 15:25
Alan Gabriel B.

Alan Gabriel B. Software Engineer,
IFX

Temat: Domain-Driven Design i PHP

Marcin Olichwirowicz:
Chyba najlepiej nie tłumaczyć bo strasznie zabawnie brzmi takie wymyślanie polskich słów na bazie angielskich ;) A jak się powie "warstwa utrwalenia" to nikt nie załapie ;]

Według mnie zabawnie, a nawet kulawo, to brzmią dosłowne tłumaczenia np. "pomocniki", czy "dyspozytor" (tak wyszło chłopakom z php.pl, kiedy zabrali się za manual ZF kilka lat temu).

Osobiście optuję za spolszczaniem typowych branżowych słówek. Moim ulubionym jest "reużywalność" :)
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Domain-Driven Design i PHP

Mam takie pytanie implementacyjne, co wydaje się Wam lepsze ?
Prosty przypadek aktualizacji danych użytkownika:



class User {

private $firstName;
private $lastName;

public function updateInfo(array $data){
$this->firstName = $data['firstName'];
$this->lastName = $data['lastName'];
}
}

class FooController {

//... some code

public function dispatch($request){
$post = $request->post();
$userId = $request->param('id');

$user = $this->repository->find($id);
$user->updateInfo($post);

$this->entityManager->persist($user);

//other code - returning response etc
}

}



czy


class User {

private $firstName;
private $lastName;

public function updateInfo(array $data){
$this->firstName = $data['firstName'];
$this->lastName = $data['lastName'];

EventListener::handle(EventsFactory::factory('EntityChanged',$this));
}
}

class Event_Entity_Change {

private $entity;
private $entityManager;

public function __construct($entity, $entityManager){
$this->entity = $entity;
$this->entityManager = $entityManager;
}

public function execute(){
$this->entityManager->persist($entity);
}
}

//use

class FooController {

//... some code

public function dispatch($request){
$post = $request->post();
$userId = $request->param('id');

$user = $this->repository->find($id);
$user->updateInfo($post);

//other code - returning response etc
}

}

Wojciech Soczyński edytował(a) ten post dnia 23.05.11 o godzinie 10:57
Adam Brodziak

Adam Brodziak PHP, football, fun

Temat: Domain-Driven Design i PHP

Standardowa odpowiedź: to zależy. Trzeba wziąć pod uwagę mnóstwo czynników, ważniejsze z nich:
- czy kontroler jest jedynym miejscem aktualizacji?
- czy po aktualizacji musi zdarzyć się coś poza zapisaniem?
- czy zależność od zdarzeń w encji jest dopuszczalna [sic!]
- czy programista piszący resztę kody spodziewa się zdarzenia?
- i tak dalej...

Nie da się tego ocenić bez kontekstu aplikacji (wymagań, narzędzi, dobrych praktyk). Tu nie da się stweirdzić jednoznacznie co jest lepsze, jak przy porównaniu Singletona i Dependency Ijnection ;) A przecież Singleton bywa przydatny.
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Domain-Driven Design i PHP

Adam Brodziak:
Standardowa odpowiedź: to zależy. Trzeba wziąć pod uwagę mnóstwo czynników, ważniejsze z nich:
- czy kontroler jest jedynym miejscem aktualizacji?
- czy po aktualizacji musi zdarzyć się coś poza zapisaniem?
- czy zależność od zdarzeń w encji jest dopuszczalna [sic!]
- czy programista piszący resztę kody spodziewa się zdarzenia?
- i tak dalej...

Nie da się tego ocenić bez kontekstu aplikacji (wymagań, narzędzi, dobrych praktyk). Tu nie da się stweirdzić jednoznacznie co jest lepsze, jak przy porównaniu Singletona i Dependency Ijnection ;) A przecież Singleton bywa przydatny.

Oczywiście, masz rację co do kwestii kontekstu. Ten przykład jest tylko jakimś tam wyimaginowanym przypadkiem. Celem moich rozważań jest zastanowienie się jak dużo warstwy leżące wyżej powinny wiedzieć o warstwach leżących niżej. Czy kontroler powinien wiedzieć coś o kwestii utrwalania - znać klasę repozytorium, czy też entityManagera. Czy może zastosować event lub rozdzielić warstwę aplikacji i danego kontekstu domenowego fasadą jak np. tutaj:



class User {

private $firstName;
private $lastName;

public function updateInfo(array $data){
$this->firstName = $data['firstName'];
$this->lastName = $data['lastName'];
}
}

class UserContextFacade {

//... some code

public function updateUserInfo($userId,array $data){
$user = $this->repository->find($id);
$user->updateInfo($post);

$this->entityManager->persist($user);
}

}

class FooController {

//... some code

public function dispatch($request){
$post = $request->post();
$userId = $request->param('id');

$this->userContextFacade->updateUserInfo($userId, $post);

//other code - returning response etc
}

}



Zastanawia mnie generalizacja, dla jakiego typu aplikacji, które podejście będzie najwłaściwsze ?

Następna dyskusja:

UI UX Design Courses in Ban...




Wyślij zaproszenie do