Domain-Driven Design: Tackling Complexity in the Heart of Software

Author: Eric Evans
4.3
All Stack Overflow 161
This Year Stack Overflow 5
This Month Stack Overflow 1

Domain-Driven Design: Tackling Complexity in the Heart of Software

4.3

Review Date:

Comments

by cottsak   2019-04-25
Largely agree with this except the initial objection "Data structure and functions should not be bound together" and the "Why was OO popular?" which is missing the response - because using the notion that "objects" from the real world encapsulate state and behaviour was not only a solid premise, but it was an attempt to interface the computer world with the real. This was not a failed concept. It makes some sense. Just very few teams find the discipline to model their core domain this way.

Which brings be back to the original objection. I think this is true most of the time, except when it's not - which is your core Domain Model. The first 1/2 of the Blue Book[1] lays out straightforward means to arrange code, functions, data/state and related behaviours in a way which can be managed and maintained over time. This is pretty important as most folks who've spent any length of time maintaining vast applications will know that it's incredibly hard to reason about a first-class concept in an application without clear boundaries around said concept, it's structures and it's behaviour. Most of us are unlucky and find this scattered across the landscape. Few applications take the focus to "model" these concepts clearly.

Does this modelling have to be done with "Domain Model", or DDD, or something else that can be loosely coupled with OOD - probably not. But another developer absolutely has to be able to reason about said structures and behaviour. They have to be able to read it easily and grok it quickly. And having done that, they don't want to be surprised by some distant missing element, 20 calls or 1000 lines or 15 modules (repos, submodules, etc, etc) away! This is possibly the biggest time-sink and therefore "cost" of development. One could also take this further and postulate that about 1/2 of us are employed as a direct result of applications whose core concepts are so poorly designed or hard to reason about, that a massive volume of work (time?) is dedicated to unwinding the ambiguity that results.

I don't want to suggest that OOP or OOD/DDD/{other modelling process} would necessarily fix this, but the attempt to clarify and find a means to make modelling these critical concepts easier and less costly is admirable IMO.

It's ok if your infrastructure takes a different approach, or is "functional" or "dynamic" in nature. If your test suite uses completely different patterns and paradigms because the tooling makes that easy then - awesome! But if the core model/concepts of your application are hard to understand, reason about, and therefore maintain, then you're pretty fucked.

OO doesn't "suck". It's spirit is just largely lost and like many other things in life, it's been hijacked and mutilated into something many of us come to loathe because we've never seen it deliver on the promises. I guess we will be having this conversation again in another decade about something else that's hugely popular right now.

[1] https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

by anonymous   2019-01-13

Before you choose an integration mode, there's analysis to be done on a strategic level about the business subdomains, teams that will maintain these services, who owns what, how you expect the models to evolve, etc.

I'd recommend having a look at the Context Mapping part of the DDD book and then Enterprise Integration Patterns by Hohpe and Woolf for concrete implementation.

by karmajunkie   2018-11-10
If you're going to dive into CQRS/ES, I'd recommend:

* Enterprise Integration Patterns (basically an entire book about messaging architectures) [1] * Vaughn Vernon's books and online writing [2], * Domain Driven Design by Eric Evans [3], * and most of what Greg Young, Udi Dahan, and that constellation of folks has done online (lots of talks and blog articles.)

Depending on your platform of choice, there may be others worth reading. For my 2¢, the dragons are mostly in the design phase, not the implementation phase. The mechanics of ES are pretty straightforward—there are a few things to look out for, like detection of dropped messages, but they're primarily the risks you see with any distributed system, and you have a collection of tradeoffs to weigh against each other.

In design, however, your boundaries become very important, because you have to live with them for a long time and evolving them takes planning. If you create highly coupled bounded contexts, you're in for a lot of pain over the years you maintain a system. However, if you do a pretty good job with them, there's a lot of benefits completely aside from ES.

[1] https://www.amazon.com/Enterprise-Integration-Patterns-Desig...

[2] https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

by anonymous   2018-05-09
@AppleBook89 You can read the great tutorial from http://cqrs.nu/ Event-sourcing (and CQRS) works great with (Domain driven design )[https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215]. There are a lot of other sources on the internet, too many in fact to be put here. Look also (here)[https://stackoverflow.com/tags/domain-driven-design/info]
by ChicagoDave   2018-01-25
I can only refer you to Eric Evans book (https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...) and other domain driven design material.

Boundaries are by domain, and yes that's not a simple thing to define. Sometimes, domains have varying interfaces, which makes building micro-services more complex, especially when trying to adhere to REST/Swagger standards (something I'm not overly find of).

But keeping things as simple as possible is really the best approach.

All micro-services should be small. When I see someone say "big", then I'm guessing there are a lot of ad-hoc actions...those need to be broken down into their proper domain or relegated to a query service.

by jgrodziski   2017-10-19
Identifying changing "stuff" in the real world is for me a fundamental topic of any serious data modeling for any kind of software (be it an API, a traditional database stuff, etc). Identity is also at the center of the entity concept of Domain-Driven Design (see the seminal book of Eric Evans on that: https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...).

I started changing my way of looking at identity by reading the rationale of clojure (https://www.amazon.com/Data-Reality-Perspective-Perceiving-I....

More specifically concerning the article, I do agree with the point of view of the author distinguishing access by identifier and hierarchical compound name better represented as a search. On the id stuff, I find the amazon approach of using URN (in summary: a namespaced identifier) very appealing: http://philcalcado.com/2017/03/22/pattern_using_seudo-uris_w.... And of course, performance matters concerning IDs and UUID: https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-ca....

Happy data modeling :)

EDIT: - add an excerpt from the clojure rationale

by anonymous   2017-10-01

Implement Repository pattern is pretty easy, you just need to create interface with CRUD methods and use it in your domain logic.

For example:

class CreateEntityException;
class ReadEntityException;
class UpdateEntityException;
class DeleteEntityException;

interface Repository<Entity> {
    Entity create(Entity entity) throws CreateEntityException;
    Entity read(long entityId) throws ReadEntityException;
    Entity update(Entity entity) throws UpdateEntityException;
    void delete(long entityId) throws DeleteEntityException;
}

Methods count and signature can be different in your own project but an approach is the same. After it you can create concrete implementation of repository that encapsulate one or another datasource - ContentProviderRepository, OrmLiteRepository, RealmRepository etc. Then by using Dependency Injection principle you should inject correct implementation.

There are few good books that covered Repository patterns. Pattern is independent from platform so it is easy to implement and use every platform.

https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

https://www.manning.com/books/functional-and-reactive-domain-modeling

by anonymous   2017-09-18
I agree that this is the best approach. For a very detailed overview of this design pattern, check out the great Eric Evans book, Domain Driven Design (https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215).
by galeaspablo   2017-08-20
> If you aren’t familiar with the database pattern known as event sourcing (don’t worry — it’s relatively new),

It's not relatively new. That “transaction file” thing in your database? Event Sourcing.

https://www.amazon.co.uk/Domain-driven-Design-Tackling-Compl... https://www.amazon.co.uk/Implementing-Domain-Driven-Design-V...

-----------------

If that doesn't do it for you, please just remember the good old CAP theorem.

https://en.wikipedia.org/wiki/CAP_theorem