DCI Sample

[Marc Grue]

Hi all,

Finally ported the DDD Sample application to DCI (using Java/Qi4j/Wicket)!

I have quite a bunch of thoughts about DCI coming from working with the sample, so I made a blog where I hope you'll find one or two things that could be interesting to talk about here (or on the evolution list):

Architecture - describes how the code layers map to new conceptual boundaries of the DCI paradigm.

Conceptual Enforcement- explains how we can get "architectural safety" by enforcing a strict layering scheme.

Use Cases - looks at how use cases on different levels integrate with DCI.

Testing - goes in detail with the close relationship between UseCase-Context-Test and how we can more systematically organize our test cases.

Process Thinking - analyses in detail how a specific process in the DDD Sample becomes much more directly understandable when coded with DCI and how the thinking goes along processes rather than data structures or technical concerns.

Code in repo/zip:

https://github.com/DCI/dci-sample/

http://marcgrue.com/uploads/dci-sample.zip

Run Start8082 in version b and point a browser to localhost:8082 to start shipping cargos with a DCI backend!

Looking forward to hear your thoughts...

Cheers,

Marc

[Cevat Serkan Balek]

Excellent work, give us a time to study it for our comments :)

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

[James O. Coplien]

On Oct 7, 2011, at 4:31 , Marc Grue wrote:

The more I look at the DDD port the more I see considerable compromises to DCI principles.

Do you mean in the code - can you be more specific, possibly take out
an example?

I am concerned that people will take that port as being what DCI is. It is not.

Can you help me understand what you find is not DCI in the code? I
would sincerely like to learn how that is and work on a version c that
would be more DCI compliant.

The DDD architecture [I presume my DCI Sample?] reflects pretty static thinking; it says a lot about static things but little about objects.

Example in code?

Code provides a smoking gun to illustrate sound or faulty principles. In this case I don't need to go to the code because the principles are made explicit.

Commentary below.

On Oct 5, 2011, at 7:32 , Marc Grue wrote:

Hi all,

Finally ported the DDD Sample application to DCI (using Java/Qi4j/Wicket)!

I have quite a bunch of thoughts about DCI coming from working with the sample, so I made a blog where I hope you'll find one or two things that could be interesting to talk about here (or on the evolution list):

Architecture - describes how the code layers map to new conceptual boundaries of the DCI paradigm.

DCI does suggest an architecture; in fact, that's what it is. We commonly call it "The DCI Architecture."

It goes very well with the MVC architecture.

Firts, the example is pretty layer-y. OO architectures tend to be flat.

Second, if you're going to talk about the source code world, it's important to convey that the architecture is fractal in nature. A role can attach to any object — not just Data objects (e.g., it can attach to a Context object).

Third, I think it's better if the architecture reflects the mental model, and that it is about objects rather than roles. You can see the architecture of a house much better from the house than from its blueprints. This seems more like the blueprints than the house.

Conceptual Enforcement- explains how we can get "architectural safety" by enforcing a strict layering scheme.

But then it wouldn't necessarily human reflect mental models any more.

There is nothing wrong with circular dependencies. Welcome to reality.

There is no infrastructure or domain layer per se in DCI. What you say may apply to more by-the-book DDD, but I don't know how it taps into the fundamentals of DCI architecture.

Use Cases - looks at how use cases on different levels integrate with DCI.

A summary use case does not give a helicopter view of "what this is all about." It is a slice — only a behavioural slice. Data design is not subordinate to use cases: it takes place in parallel.

I do not understand the distinction between scope and context. There is no requirements scoping in DCI other than what Contexts express.

Testing - goes in detail with the close relationship between UseCase-Context-Test and how we can more systematically organize our test cases.

This might be true. You say, "We can simply test all steps and deviations in a use case. We therefore naturally get a corresponding Test file." Note that the combinatorics work against you. If I have one use case with three deviations, then the use case generates 8 scenarios. You need to test each of those scenarios. Even if each scenario takes only two parameters (where data items in the domain classes each count as a parameter to a context) and if you did only boundary condition testing, you could get by with only 32 tests. But you need to do much more than boundary condition testing, and a typical use case can have dozens of variations. You still need to do thousands of tests. So while this is a nice idea in theory, it falls apart in practice.

Process Thinking - analyses in detail how a specific process in the DDD Sample becomes much more directly understandable when coded with DCI and how the thinking goes along processes rather than data structures or technical concerns.

Here, I think the argumentation is much better and very much in line with DCI thinking.

The cheat sheet has many conceptual errors in it. A role is never played by more than one object at a time (what is an "entity"? DCI says nothing about "values" — those are very special object-like things that require very special articulation. A Methodless Role is not a value; the statements about it not having an implementation in the Context and not being played by anything are at best strange statements and at worst wrong.

Try another iteration. Keep at it. It will take a while but in the end it could be worth it. As a foundation for what you write here I urge you to do a simple, ordinary DCI program without entangling it with DDD. Having that under your belt, incorporate DDD notions and note what changes. That can lead to a story worth telling. I am concerned that by first trying to do both at once you have potentially compromised both.

Code in repo/zip:

https://github.com/DCI/dci-sample/

http://marcgrue.com/uploads/dci-sample.zip

Run Start8082 in version b and point a browser to localhost:8082 to start shipping cargos with a DCI backend!

Looking forward to hear your thoughts...

Cheers,

Marc

[James O. Coplien]

On Oct 8, 2011, at 1:14 , James O. Coplien wrote:

Testing - goes in detail with the close relationship between UseCase-Context-Test and how we can more systematically organize our test cases.

Just a follow-up on this: Trygve often cites Hoare:

Finally quoting Tony Hoare: "... there are two ways of constructing a

software design: One way is to make it so simple that there are

obviously no deficiencies and the other way is to make it so complicated

that there are no obvious deficiencies. The first method is far more

difficult."

The bottom line is that if you need testing to show that your code works, you're at a serious disadvantage. We want people to be able to reason soundly about run-time behavior by reading the code. You can very rarely design code in a way that enough execution ahead of time gives you confidence that it will run forever. It's not like building a car, where you can get a good feeling that the engine will continue to run if it works once you've assembled it. Engines have a trivial number of states. Programs have statefulness on the order of the number of stars in the heavens, and any pretense to be able to master its complexity with testing is to play either God, or the fool.

DCI is about making the code understandable, much more so than making it testable.

[Joshua Ramirez]

This looks at first glance well organized and I'm excited to dig into it asap. I've recently discovered DCI and am pretty interested in the concepts. It's nice to have samples like this to agitate the neural nets ;)

[Suissa]

I want some examples too, I've recently discovered DCI too.

On Tue, Nov 1, 2011 at 12:06 AM, Joshua Ramirez <joshuaramir...@gmail.com> wrote:

This looks at first glance well organized and I'm excited to dig into it asap. I've recently discovered DCI and am pretty interested in the concepts. It's nice to have samples like this to agitate the neural nets ;)

--

You received this message because you are subscribed to the Google Groups "object-composition" group.

To view this discussion on the web visit https://groups.google.com/d/msg/object-composition/-/SBT9WhSgmvcJ.

To post to this group, send email to object-co...@googlegroups.com.
To unsubscribe from this group, send email to object-composit...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/object-composition?hl=en.

--
Jean C. Nascimento aka Suissa
WebDeveloper Sênior - PGS - SP

Blog - suissacorp.com.br/suissa/

NoSQL Evangelist - nosqlbr.com.br/

      

XULEPA