What kind of "Service Data" should be public for IT/Ops?

[Neylor Ohmaly Rodrigues e Silva]

If a IT/Ops needs some information from a service they need to see it, right? So, some service data should be exposed as "public". What kind of information should be "public", the? A service should have its data classes public,  should create "Value objects" that is public, or should make its internal messages public? If a junior developer gets a service DLL that contains this public data, they could think: " If this data is public I can use it, manipulate it and store it on my service (with is not a it/ops service)". Its is possible to enforce that some data should be used only by IT/Ops service in code or it should be enforced by the documentation?

[Ben Kloosterman]

This is a huge topic ...  and you need to break it down / be more specific  as each business has different requirements . So here is my best guess reply to what your asking...

Abstraction , Encapsulation  , Ocaps etc were invented to prevent such miss-use  .  A common solution these days is to have anaemic domains / naked entities where all entities are public and logic wrapped in misnamed services or managers which is not ideal  , it is fast and easy  ( and often a requirement of OR mappers) though there is a price . However if you don't integrate much and you have many small apps / services with 1 developer per app / service then such a solution can be overall beneficial .  On the other hand if you have 5 teams working on a single app than you need a different approach.

In your dll example if the dll is always wrapped by an SOA service than you may need rights to call the service - this reuse is what SOA was designed to deal with . Developers just grabbing DLLs  and misusing them is a bigger issue than whether some of the internals are public  ( Im working on a project where they used single threaded WPF Dlls in a multi threaded web service  which is not pretty ) . DLLs should fit somewhere in a design ,  the more internals that are public the  higher the chance of miss-use. A  Fascade pattern is often used to wrap / abstract the internals  . 

I dont think documentation is worth much in most organisations .

Ben

On Fri, Apr 4, 2014 at 11:35 PM, Neylor Ohmaly Rodrigues e Silva <nohro...@gmail.com> wrote:

If a IT/Ops needs some information from a service they need to see it, right? So, some service data should be exposed as "public". What kind of information should be "public", the? A service should have its data classes public,  should create "Value objects" that is public, or should make its internal messages public? If a junior developer gets a service DLL that contains this public data, they could think: " If this data is public I can use it, manipulate it and store it on my service (with is not a it/ops service)". Its is possible to enforce that some data should be used only by IT/Ops service in code or it should be enforced by the documentation?

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kijana Woodard]

" I dont think documentation is worth much in most organisations ."

+1
Never seen it get read. But boy, does it get printed. 😂