State should not depend on the API server

[Ian Booth]

On 16/09/14 19:19, roger peppe wrote:
> On 16 September 2014 02:12, Tim Penhey <tim.penhey at canonical.com> wrote:
>> On 12/09/14 01:35, Nate Finch wrote:
>>> Separation of logic is absolutely a good thing.  Separation of data is
>>> not nearly so useful.
>>
>> What I see as the real benefit of this work is based behind the
>> "interface segregation principle".
>>
>> Effectively this boils down to "don't depend on things you don't need".
> 
> I agree with this sentiment. Dependency hygiene is very important
> (though it seems to me that dependencies
> are perhaps more about implementation than interface).
> 
>> The state package should never depend on packages from the API.
>>
>> This work is not just busy work, but clear separation, and generally
>> what is considered good software development principles.
> 
> I have difficulty with this though. The state package and the API package
> are clearly linked - their concerns are not entirely separate. In my view,
> the state package exists only to serve the purposes of the API, which is
> *the* externally visible part of Juju.
>

There's a few issues here. The state package as it exists today is a mix of Juju
domain business logic and a persistence layer, unfortunately intertwined. What
should be the externally visible part of Juju is a service oriented abstraction
with coarse grained business methods; we have this with the facades. What comes
into those facades over the wire in terms of parameters should be transformed
into domain objects for use by the service business logic called by the facade
endpoints. On the wire data crosses a system boundary to enter/exit the business
services layer and so the data needs to be transformed to avoid unnecessary
coupling. As an example, a machine reference comes in over the wire as a machine
tag, which is transformed to a machine id for use by the services layer, which
us transformed to a global key when passed to the persistence layer. Thus the
api params structs contain attributes that are syntactically distinct from
what's required by the business services. It's a terrible abstraction leak to do
otherwise. Dave has started the process of correcting the implementation issue
we have, and in my view, it is necessary and desirable, based on sound design
principals. IMO :-)

> As such, many of the concerns and data structures dealt with by the state
> package will be the same as those dealt with by the API implementation.
>

This I disagree with - see above. The data structures should not be the same.