On 16/09/14 19:19, roger peppe wrote: > On 16 September 2014 02:12, Tim Penhey <[email protected]> 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. -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
