Is it worth using contexts within an app that was built without them?

Questions / Help
1

I’m currently working on a new module within an an existing application that was first built in Phoenix 1.2. It’s had a significant amount of refactoring work completed on it and it is currently up to date in its code and syntax.

One thing that wasn’t updated was the directory structure away from the 1.2 model structure into the 1.3 context structure. It was thought that such a monumental change in what is quite a large application would require more resources than are available at the moment.

For the new work I have to do I’d really prefer to use the API generators but I feel like working within two different directory structures would create a series of problems that would be a lot of hassle. After a brief bit of experimentation this has seemed to be the case with various missing function warnings and routing issues.

Have you done something similar or am I just being daft and need to decide between using the pre 1.3 structure or updating the existing directory.

2

Don’t go for modern technology idioms unless they help your job.

Contexts for me serve as responsibility boundaries; I’d like my web templates to not know about the database at all. This makes my job easier.

But many people have no problem with everybody being in one room and hugging each other, so to speak. And they can make it work just as well as me who is opting for clearer responsibility boundaries.

Decide instead if your project is going to benefit from forcibly putting contexts in it. If you cannot see an appreciable improvement, save yourself the hassle.

3

The trick is to not delay beyond the point when enough good information is available to define optimal boundaries.

From that point on

https://twitter.com/kentbeck/status/250733358307500032?lang=en

1 Like
4

I am fully on yours and Kent Beck’s side. But I am realistic that many people underestimate the danger (or might never get to enough lines of code for it to be a problem) of not enforcing responsibility boundaries.

1 Like
5

What you both said makes a lot of sense. This particular project is API only and there isn’t any real cross over between models at the moment so there isn’t an immediate gain beyond having it up to modern conventions (and being able to use the generators more easily.)

The linked article from Martin Fowler was very interesting.