4 ms·

I've been interested and confused about DDD, hexagonal architecture, clean architecture etc. for a couple of years now but unfortunately have not had time to de

I've been interested and confused about DDD, hexagonal architecture, clean architecture etc. for a couple of years now but unfortunately have not had time to dedicate towards reading up on all of them. Has anyone actually implemented any of this as part of their jobs? I guess it all depends what you do. I mainly do web stuff, and Django/DRF lets us go fast. Out of the box, I think this goes against the aforementioned architecture as the ORM couples the domain model with the data model. Besides, gathering requirements (at least at my company) is unfortunately an ongoing thing which is just the nature of a startup I suppose.

rumanator 6y ago
> Out of the box, I think this goes against the aforementioned architecture as the ORM couples the domain model with the data model. It doesn't. You're confusing the persistence model with the domain model. Your persistence model is dictated by your need to persist your data while meeting the requirements of your domain model. Your domain model does not care about your persistence requirements. Your persistence model is bounded to your persistence service and should not leak out, while your domain model is ubiquitous to your system. Let's put it this way: with a Clean Architecture you are able to add/replace any persistence service you wish, and that has no impact on any other service.
- yeswecatan 6y ago
  Can you provide a concrete example? I would assume if you wanted to decouple the persistence model from the domain model then you would need to write a separate domain model in Django since the domain and persistence model are tightly coupled.
  - rumanator 6y ago
    I'm not very familiar with Django thus my ability to provide relevant examples using this particular framework is limited. However I direct your attention to the fact that Django docs make it very clear that to them in general each model maps to a single database table. That's quite Spartan even for an ORM, and obviously the point of a domain model is to model a problem domain, not to model the database.
about3fitty 6y ago
I’ve been using DDD with Django/DRF and as a mid level, I’m confused as to why we aren’t leaning on native Django more and writing less boilerplate. I don’t know if this is a common complaint though.
- yeswecatan 6y ago
  Do you have any examples how you accomplish this? Do you have separate domain models which are decoupled from Django's models? Do you use the repository pattern?
  - about3fitty 6y ago
    I’m hesitant to give examples unfortunately but yes to the above and lots of what we do is bespoke whereas we could leverage Django for a lot of it. How are you putting it together? Independent Python classes that exist outside of most of Django core?
Kunigaikstis 6y ago
Following the DDD practice at my current workplace. Hard to get into initially but it forces you to write modular code. Ramp up has been slow but nowadays, unlike previously, I'm able to write whole services with tests before even running them. And feel comfortable that they'll work. But that might not be solely down to DDD.
PopeDotNinja 6y ago
I've been through a couple monolith to microservice transitions. I will say this... if you're monolith is slow because of it's design limitations, and your plan is to propagate those limitations across N microservices w/ all the overhead that comes with microservices, you're microservices will only be good at scaling the billable hours of the consultants who sold you on the idea in the first place.
patricklouys 6y ago
Yes, we did all that a few years ago and it's still in use. Clean code, hexagonal architecture, DDD, event sourcing. Main lesson is that you should not use it for everything (yes, the books say it, but it's easy to overdo it in the beginning). Don't do DDD for the CRUD parts of your app. It works extremely well for business use cases, but it's very bad at CRUD. A mix of both really hits the sweep spot though. No microservices though, just a monolith. Imo most businesses shouldn't need microservices, only the ones that really need to scale. We definitely don't have anything even close to that.
- PopeDotNinja 6y ago
  I wish hexagonal architecture picked used less overloaded words than ports and adapters. And while we're at it, I wish it used hexagons, or picked a different name. It's super obtuse to learn & teach.
tmstieff 6y ago
I've been on a few projects now that attempted to implement most of these patterns wholesale. The idea is simple to grasp and implement with a small team, but it's been nearly impossible maintain any cohesion for larger organizations. Most enterprise programmers are at least familiar enough with MVC that it's not an issue. But very few in my experience have actually worked on a project that adopted DDD. Some have never even heard of it. Personally, even following all the guidelines laid out by the famous book and other ancillary documentation and articles, such as this one, the whole thing can fall apart quickly when you have a business requirement that doesn't match your technical architecture. You will at some point have to cross-contexts and communicate between domains. In Martin Fowler's article, this is literally hand-waved. I think there's maybe a few sentences on it? Here, the suggestion is to use 'event storming' to make sure you design your services correctly from the start. Okay, what about if your business pivots your initial assumptions are wrong. Our team has adopted an action approach, but it goes by different names (channels, user actions, business actions) which model a single action and compose sub-actions from different domains, usually in a single transaction. This seems to work, but now we're operating in some non-aggregate space that couples all the domains. So basically, the most difficult to manage and complex scenarios, where you model your cross-context flows, are never described beyond, use async (not always possible) and re-organize your services (also, not always possible). Would love to hear if anyone else has any experience here, or maybe I'm missing some fundamental part of DDD.
oftenwrong 6y ago
I've used hexagonal architecture extensively. All of the typically claimed benefits are true. It's great for enforcing separation of concerns, and for permitting easy swapping of components. Great for mocking components in tests. Great for long-life software. Most materials present hexagonal architecture in a very one-sided way, however. They don't discuss the downsides. For example, every connection point between components requires an abstract API layer. This is a significant overhead compared to just having components call into eachother. In the long run, this is worth the effort. In the short term, there is no benefit. Additionally, while it is true that the APIs can be flexibly hooked up to any implementation, there is still plenty of room for bad assumptions to creep into those APIs. When you have many adapters for a given port, those assumptions are entrenched, and are difficult to change.
PaulRobinson 6y ago
You don't need micro services to do DDD - you can do DDD within a Django app. I'm not a Django man myself, but a quick google shows several projects and blogs discussing it. In essence, DDD forces you to have conversations about separation of concerns, and then being careful to stick to them. Microservices force that, but you can get the same effect with well-thought out namespaces in a monolith.
- yeswecatan 6y ago
  Oh, I didn't mean to imply that I was only interested in DDD et al. for microservices.

rumanator 6y ago

> Out of the box, I think this goes against the aforementioned architecture as the ORM couples the domain model with the data model. It doesn't. You're confusing the persistence model with the domain model. Your persistence model is dictated by your need to persist your data while meeting the requirements of your domain model. Your domain model does not care about your persistence requirements. Your persistence model is bounded to your persistence service and should not leak out, while your domain model is ubiquitous to your system. Let's put it this way: with a Clean Architecture you are able to add/replace any persistence service you wish, and that has no impact on any other service.

yeswecatan 6y ago
Can you provide a concrete example? I would assume if you wanted to decouple the persistence model from the domain model then you would need to write a separate domain model in Django since the domain and persistence model are tightly coupled.
- rumanator 6y ago
  I'm not very familiar with Django thus my ability to provide relevant examples using this particular framework is limited. However I direct your attention to the fact that Django docs make it very clear that to them in general each model maps to a single database table. That's quite Spartan even for an ORM, and obviously the point of a domain model is to model a problem domain, not to model the database.

about3fitty 6y ago

I’ve been using DDD with Django/DRF and as a mid level, I’m confused as to why we aren’t leaning on native Django more and writing less boilerplate. I don’t know if this is a common complaint though.

yeswecatan 6y ago
Do you have any examples how you accomplish this? Do you have separate domain models which are decoupled from Django's models? Do you use the repository pattern?
- about3fitty 6y ago
  I’m hesitant to give examples unfortunately but yes to the above and lots of what we do is bespoke whereas we could leverage Django for a lot of it. How are you putting it together? Independent Python classes that exist outside of most of Django core?

Kunigaikstis 6y ago

Following the DDD practice at my current workplace. Hard to get into initially but it forces you to write modular code. Ramp up has been slow but nowadays, unlike previously, I'm able to write whole services with tests before even running them. And feel comfortable that they'll work. But that might not be solely down to DDD.

PopeDotNinja 6y ago

I've been through a couple monolith to microservice transitions. I will say this... if you're monolith is slow because of it's design limitations, and your plan is to propagate those limitations across N microservices w/ all the overhead that comes with microservices, you're microservices will only be good at scaling the billable hours of the consultants who sold you on the idea in the first place.

patricklouys 6y ago

Yes, we did all that a few years ago and it's still in use. Clean code, hexagonal architecture, DDD, event sourcing. Main lesson is that you should not use it for everything (yes, the books say it, but it's easy to overdo it in the beginning). Don't do DDD for the CRUD parts of your app. It works extremely well for business use cases, but it's very bad at CRUD. A mix of both really hits the sweep spot though. No microservices though, just a monolith. Imo most businesses shouldn't need microservices, only the ones that really need to scale. We definitely don't have anything even close to that.

PopeDotNinja 6y ago
I wish hexagonal architecture picked used less overloaded words than ports and adapters. And while we're at it, I wish it used hexagons, or picked a different name. It's super obtuse to learn & teach.

tmstieff 6y ago

I've been on a few projects now that attempted to implement most of these patterns wholesale. The idea is simple to grasp and implement with a small team, but it's been nearly impossible maintain any cohesion for larger organizations. Most enterprise programmers are at least familiar enough with MVC that it's not an issue. But very few in my experience have actually worked on a project that adopted DDD. Some have never even heard of it. Personally, even following all the guidelines laid out by the famous book and other ancillary documentation and articles, such as this one, the whole thing can fall apart quickly when you have a business requirement that doesn't match your technical architecture. You will at some point have to cross-contexts and communicate between domains. In Martin Fowler's article, this is literally hand-waved. I think there's maybe a few sentences on it? Here, the suggestion is to use 'event storming' to make sure you design your services correctly from the start. Okay, what about if your business pivots your initial assumptions are wrong. Our team has adopted an action approach, but it goes by different names (channels, user actions, business actions) which model a single action and compose sub-actions from different domains, usually in a single transaction. This seems to work, but now we're operating in some non-aggregate space that couples all the domains. So basically, the most difficult to manage and complex scenarios, where you model your cross-context flows, are never described beyond, use async (not always possible) and re-organize your services (also, not always possible). Would love to hear if anyone else has any experience here, or maybe I'm missing some fundamental part of DDD.

oftenwrong 6y ago

I've used hexagonal architecture extensively. All of the typically claimed benefits are true. It's great for enforcing separation of concerns, and for permitting easy swapping of components. Great for mocking components in tests. Great for long-life software. Most materials present hexagonal architecture in a very one-sided way, however. They don't discuss the downsides. For example, every connection point between components requires an abstract API layer. This is a significant overhead compared to just having components call into eachother. In the long run, this is worth the effort. In the short term, there is no benefit. Additionally, while it is true that the APIs can be flexibly hooked up to any implementation, there is still plenty of room for bad assumptions to creep into those APIs. When you have many adapters for a given port, those assumptions are entrenched, and are difficult to change.

PaulRobinson 6y ago

You don't need micro services to do DDD - you can do DDD within a Django app. I'm not a Django man myself, but a quick google shows several projects and blogs discussing it. In essence, DDD forces you to have conversations about separation of concerns, and then being careful to stick to them. Microservices force that, but you can get the same effect with well-thought out namespaces in a monolith.

yeswecatan 6y ago
Oh, I didn't mean to imply that I was only interested in DDD et al. for microservices.