Found in 13 comments
by ChicagoDave
I can only refer you to Eric Evans book ( 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.

Original thread
by jgrodziski
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:

I started changing my way of looking at identity by reading the rationale of clojure ( -> "Identities are mental tools we use to superimpose continuity on a world which is constantly, functionally, creating new values of itself."

The timeless book "Data and reality" is also priceless:

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: And of course, performance matters concerning IDs and UUID:

Happy data modeling :)

EDIT: - add an excerpt from the clojure rationale

Original thread
by galeaspablo
> 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.

> If you’re not looking at the public chain, you’re wasting your time

I disagree. Not having a single point of failure (one place that can get hacked) is valuable.

> From a trust perspective, it makes no difference if your banking cartel is writing to a Quorum, Hyperledger, or Kafka instance.

Of course it does. The protocol of blockchains makes them work with "proof of X". Appending to any event store, whether in Kafka or SQL does not require proof of anything.

> Blockchains are built for trust, databases for throughput. Event sourcing allows us to achieve a hybrid model with characteristics of both.

No, the reason blockchains can't have high throughpout / almost infinite horizontal scalability... is because there's a logic check. E.g. in bitcoin, you can't send more bitcoins than you have a balance. Event sourcing gives you the high throughpout if there's no logic checks across aggregates --- if there are, you won't have immediate consistency, and you have to be ready for compensating events.

I recommend two books, that cover event sourcing from a Domain Driven Design perspective. The consequences are similar.


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

Original thread
by W0lf
I've gathered all the book titles in this thread and created Amazon affiliate links (if you don't mind. Otherwise you still have all the titles together :-) )

A Pattern Language, Alexander and Ishikawa and Silverstein

Advanced Programming in the Unix Environment , Stevens

Algorithmics: the Spirit of Computing, Harel

Applied Crytography, Wiley

Clean Code, Martin

Clean Coder, Martin

Code Complete, McConnel

Code: The Hidden Language of Computer Hardware and Software, Petzold

Coders at Work, Seibel

Compilers: Principles, Techniques, & Tools, Aho

Computer Systems: A Programmer's Perspective, O'Hallaron and Bryant

Data Flow Analysis: Theory and Practice, Khedker

Dependency Injection in .NET, Seemann

Domain Driven Design, Evans

Fundamentals of Wireless Communication, Tse and Viswanath

Genetic Programming: An Intrduction, Banzhaf

Head First Design Patterns, O'Reilly

Implementing Domain-Driven Design, Vernon

Intrduction to Algorithms, CLRS

Introduction to General Systems Thinking, Weinberg

Joy of Clojure, Fogus and Houser

Let over Lambda, Hoyte

Operating Systems: Design and Implementation, Tanenbaum

Parsing Techniques, Grune and Jacobs

Peopleware: Productive Projects and Teams, DeMarco and Lister

Programming Pearls, Bentley

Software Process Design: Out of the Tar Pit, McGraw-Hill

Software Runaways, Glass

Sorting and Searching, Knuth

Structure and Interpretation of Computer Programs, Abelson and Sussman

The Art of Unit Testing, Manning

The Art of Unix Programming, ESR

The Design of Design: Essays from a Computer Scientist, Brooks

The Effective Engineer, Lau

The Elements of Style, Strunk and White

The Healthy Programmer, Kutner

The Linux Programming Interface, Kerrisk

The Mythical Man-Month, Brooks

The Practice of Programming, Kernighan and Pike

The Pragmatic Programmer, Hunt and Thomas

The Psychology of Computer Programming, Weinberg

Transaction Processing: Concepts and Techniques, Gray and Reuter

Types and Programming Languages, Pierce

Understanding MySQL Internals, Pachev

Working Effectively with Legacy Code, Feathers

Zen of graphics programming, Abrash

Original thread
by jpalomaki
Two books that affected my thinking on the subject were Domain Driven Design[1] by Eric Evans and Object Thinking[2] by David West. Many years since I read the books and I don't claim to have studied them in detail so I'm not saying if they were good or bad, but at least I got some ideas out of them.



Original thread
by stevesun21
I worked with MVC before, but eventually I found that DDD (Domain Driven Design) is what I'm looking for. Domain Driven Design is more like a set of rules of how to apply the existing design partners (eg: repository, factory and aggregation) and building blocks (eg: layering architecture) to design your business models and keep the integrity, invariance between data. Moreover, it lets you easily define the boundary between your services for Microservice architecture.

MartinFowler DDD blogs: Book:

Original thread
by wpietri
This is a great explanation of how to really start seeing objects. Like you, I just look for data that travels together. Then I find code that only ever gets used on that data. I pull it out and figure out a name for it. This observational approach avoids a ton of architecture astronautics, where people dream up giant object hierarchies and stick with them no matter what the code is telling them.

The main compliment I'd suggest to this approach is Eric Evans' book Domain-Driven Design:

In a bottom-up approach, you can often break things down in a variety of ways. But the most stable/useful ways are often the ones that align with the conceptual model of the domain. If I notice that certain data and behavior goes together with incoming money, I might call that an InboundMoneyWorkingUnit. But if I talk to people who've spent years working in the domain, I'll realize the object should be called Payment, and their description of what a Payment does will inform my hunt for other objects and methods.

Original thread
by wpietri
I think the term he's struggling toward is something like "user experience debt" [1] or "product design debt" [2], an area that has been discussed for years.

I think "conceptual debt" is a poor choice of phrase here, as one important kind of technical debt is the sort of software design debt where your domain model ends up being a poor fit for your domain, often because the domain concepts themselves shift. (For those interested, "Domain-Driven Design" is a great book relating to this [3].)

I also find the "worse than technical debt" headline irritating. It's the sort of, "the thing I specialize in is way more important than the thing you specialize in" thinking that is poisonous in a team environment. Which one is actually worse depends a lot on your product and your business conditions.




Original thread
by solomatov
by mpweiher
We didn't have Haskell in 1989. As I wrote, there are things I value in FP languages in general, and more specifically Backus's FP calculus inspired me to come up with Higher Order Messaging[1].

It's nice to have language support for functional style (let, for example) where that is appropriate for the problem at hand, but you can write in that style without the language support easily enough.

On the other hand, when FP style is not appropriate for the problem at hand, it really, really gets in the way, and that's the case a lot of the time. Many if not most problems (outside of writing compilers for FP languages) don't really fit the functional style, and have to be made to fit.

Experienced devs will choose appropriate tools for the problem at hand. Me, I like adaptive tooling that I can bend to fit the problem, which is why I like dynamic OO languages, internal DSLs and Domain Modeling[2] in general.

In fact, I think the current tools are still a little too inflexible for this, which is why I am creating a language to address some of these issues:

FP seems to be more about bending the problem to fit the tooling, which I guess may work for a specific kind of mindset.



Original thread
by ollysb
Perhaps because it's written with examples in java but I often feel like no one in the rails community has ever read Eric Evan's Domain Driven Design[1]. It's far and away the best material I've ever seen on how to organise large code bases. It covers pretty much every suggestion that I've seen from the rails community. Sometimes the rails community can feel like the fitness industry, everybody just rebranding things that have been done before.


Original thread
by facorreia
That's correct, those terms come from Domain Driven Design terminology and are not related to C#.

You can learn more about it from this book:

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

Original thread

Looking for a good book? Subscribe to the weekly newsletter.