INTENTION REVEALING INTERFACES from DDD

Excerpt from DDD book:


"The beauty of objects is their ability to encapsulate all that so that client code is simple and can be interpreted in terms of higher-level concepts.
But if the interface doesn’t tell the client developer what he needs to know in order to use the object effectively, he will have to dig into the internals and understand the details. A reader of the client code will have to do that same. Then most of the value of the encapsulation is lost. We are always fighting cognitive overload. If the client developer’s mind is flooded with detail about how a component does its job, his mind isn’t clear to work out the intricacies of the client design. This is true even when the same person is playing both roles, developing and using his own code, because even if he doesn’t have to learn those details, there is a limit to how many factors he can consider at once."


It is so true if working on a larger dev team.

Another way to talk about CQRS/Event Sourcing

"A more promising model, used in some systems, is to think of a database as an always-growing collection of immutable facts. You can query it at some point in time — but that’s still old, imperative style thinking. A more fruitful approach is to take the streams of facts as they come in, and functionally process them in real-time."

Turning the database inside-out with Apache Samz
https://martin.kleppmann.com/2015/03/04/turning-the-database-inside-out.html

DTO vs Value Object vs POCO

http://enterprisecraftsmanship.com/2015/04/13/dto-vs-value-object-vs-poco/

Saga basic concept and unit test reference list

In DDD/CQRS, A saga is a “long-lived business transaction or process between aggregates”, also call process manager

http://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-i-of-ii/
http://blog.jonathanoliver.com/cqrs-sagas-with-event-sourcing-part-ii-of-ii/
How to unit test saga
http://www.udidahan.com/2008/02/04/sagas-and-unit-testing-business-process-verification-made-easy/
http://docs.particular.net/nservicebus/sagas/

About Command Idempotency

Definition from Gregor (New ACID)
“In the world of distributed systems, idempotency translates to the fact that an operation can be invoked repeatedly without changing the result.”

http://www.eaipatterns.com/ramblings/68_acid.html
http://codebetter.com/gregyoung/2010/08/12/idempotency-vs-distibuted-transactions/

Idempotency Patterns
http://blog.jonathanoliver.com/idempotency-patterns/

How to deal with communication between aggregate roots?

http://danielwhittaker.me/2014/11/22/4-secrets-inter-aggregate-communication-event-sourced-system/

What is Event-driven architecture?

Behind Event-driven architecture, system model is treated as a state machine. After a command changed the state, an event is generated to notify other components.
http://c2.com/cgi/wiki?EventDrivenArchitecture

What is Aggregate in DDD?

From Eric Evans book DDD Page 90
An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each AGGREGATE has a root and a boundary. The boundary defines what is inside the AGGREGATE. The root is a single specific ENTITY contained in the AGGREGATE. The root is the only member of the AGGREGATE that outside objects are allowed to hold references to, although objects within the boundary may hold references to each other. ENTITIES other than the root have local identity, but it only needs to be unique within the aggregate, since no outside object can ever see it out of the context of the root ENTITY.

By Martin Fowler
a cluster of domain objects that can be treated as a single unit.
http://martinfowler.com/bliki/DDD_Aggregate.html

What is bounded context?

From DDD website:
[[Bounded Context]] The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently.
http://dddcommunity.org/resources/ddd_terms/

From Martin Folwer:
Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.
http://martinfowler.com/bliki/BoundedContext.html

From MSDN
The term bounded context comes from Eric Evans' book. In brief, Evans introduces this concept as a way to decompose a large, complex system into more manageable pieces; a large system is composed of multiple bounded contexts. Each bounded context is the context for its own self-contained domain model, and has its own ubiquitous language. You can also view a bounded context as an autonomous business component defining clear consistency boundaries: one bounded context typically communicates with another bounded context by raising events.
https://msdn.microsoft.com/en-us/library/jj591575.aspx

From "DDD: The Bounded Context Explained"
http://www.sapiensworks.com/blog/post/2012/04/17/DDD-The-Bounded-Context-Explained.aspx

really Explained?

Same question at
http://programmers.stackexchange.com/questions/237513/what-in-reference-to-ddd-is-a-bounded-context

Conclusion:  bounded context is a fence.

How come a key concept in DDD is with so many ambiguous definitions?
:)