Slice & Dice your Monolith with Domain Driven Design by Edson Yanaga

  Рет қаралды 13,493

Devoxx

Devoxx

Күн бұрын

Пікірлер: 6
@tolgatoganduz
@tolgatoganduz 4 жыл бұрын
Duplicating classes in both data model (jpa layer) and domain model is not a problem. Actually they should be separate most of the time. Start design by generating domain model objects like entities, values objects, aggregate without ever thinking about data layer and related libraries like jpa, EF. Sometimes you do not even create a database table (data model) that corresponds to a entity or a part of aggregate, they might be retrieved from an external rest service.
6 жыл бұрын
Lots of wisdom here.
@Boss-gr4jw
@Boss-gr4jw 5 жыл бұрын
SQL in presentation objects. This is just so wrong. Also the suggestion to use same objects for database mapping and domain logic. These should always be separate. There is no justification for having framework dependencies in domain model. Even for demo purpose, you could show it for simplicity, but never say that it is fine to practice it on real project. This leads to mess and make refactoring a pain.
@ebichu8126
@ebichu8126 4 жыл бұрын
If we have coupled persistence and domain layers, it would be a pain in the ass. Entity Mapping structure and domain structure can be soooo different depending on the domain logic.
@gombike95
@gombike95 3 жыл бұрын
@@ebichu8126 This is a DDD talk, which means that in the presented theoretical project we start building up the system with Object Oriented Design and then much more later we can also start thinking about the detail how to store the state of our domain objects. At prototyping phase you might not even want to make a db connection, just to use an in-cache repository. However, if you are working on a legacy system, most of the time you have no choice but using a so called anti corruption layer and to hydrate your domain objects through that (this was also mentioned by Edson Yanaga). On the other hand, decorating your domain objects with JPA annotations might seem to be weird for the first time, but it can save you a lots of time in the end. It has only a few disadvantages like the protected empty constructor... but in the end you don't need to write the mapping functions between domain objects and jpa entities, which could be introduced later anyways with ease if the team decides so for whatever reason.
@amitjain561
@amitjain561 5 жыл бұрын
Nice discussion, Please share code location also.
DDD By Example - Paul Rayner - DDD Europe 2020
54:58
Domain-Driven Design Europe
Рет қаралды 51 М.
1 сквиш тебе или 2 другому? 😌 #шортс #виола
00:36
Всё пошло не по плану 😮
00:36
Miracle
Рет қаралды 2 МЛН
НАШЛА ДЕНЬГИ🙀@VERONIKAborsch
00:38
МишАня
Рет қаралды 2,6 МЛН
Миллионер | 2 - серия
16:04
Million Show
Рет қаралды 1,5 МЛН
Reactive DDD: Modeling Uncertainty - Vaughn Vernon
1:15:16
SpringDeveloper
Рет қаралды 22 М.
Eric Evans - Tackling Complexity in the Heart of Software
56:07
Domain-Driven Design Europe
Рет қаралды 107 М.
Microservices are Technical Debt
31:59
NeetCodeIO
Рет қаралды 530 М.
Mauro Servienti - Talk Session: All Our Aggregates Are Wrong
50:14
1 сквиш тебе или 2 другому? 😌 #шортс #виола
00:36