Implementing Domain Driven Design by Vaughn Vernon

Clean Code by Robert Martin

I think you will find some code in all of the books but the ideas are applicable almost everywhere.

- Clean Architecture
- Design Patterns: Elements of Reusable Object-Oriented Software
- Domain-Driven Design: Tackling Complexity in the Heart of Software
- Clean Agile

and forget the rest. Life is short and those books are more than enough.

Eric Evans' Domain Driven Design is a good book on the topic.

https://amzn.com/0321125215

https://en.wikipedia.org/wiki/Domain-driven_design

You can learn more about it from this book:

Domain-Driven Design: Tackling Complexity in the Heart of Software

http://www.amazon.com/Domain-Driven-Design-Tackling-Complexi...

(Since then, as with many things in our industry, it seems the book has been turned into a buzzword consulting/training money grab. Sigh.)

It's not about designing APIs, it's about designing your software to reflect the reality you're encoding into your software. It's a book of first principles that you can apply to any software you design.

I’d add DAL should be shelved for a repository pattern and business layer shelved for root aggregates and value objects.

It’s all in Eric Evans’ Domain Driven Design book that still carries enormous weight.

Bonded contexts, for example, immediately clarified how to establish naming conventions across micro-services.

ISBN-13: 978-0321125217
ISBN-10: 0321125215

When developers (and the code), product managers, domain experts, and end users all use different terminology, then cross-discipline communication difficult and imprecise. A documented Ubiquitous Language enforces shared terminology (and meaning) for all communication within the team and in the code.

http://domaindrivendesign.org/node/132

But from the writers:

    * Refactoring
    * Patterns of Enterprise Application Architecture
    * Smalltalk Best Practice Patterns
    * Agile Software Development, Principles, Patterns, and    Practices
    * Domain-Driven Design
    * Structure and Interpretation of Computer Programs
    * The Pragmatic Programmer
    * Design Patterns
    * Analysis Patterns
    * Implementation Patterns

Pluralsight has a nice DDD Learning path which has 2 popular & recommended courses in the above podcast, "Domain-Driven Design Fundamentals" & "Modern Software Architecture: Domain Models, CQRS, and Event Sourcing".

You're probably familiar already with the books "Domain-Driven Design: Tackling Complexity in the Heart of Software" & "Domain-Driven Design Distilled".

You are right! I learn something new every day.

"Although a model-driven design does not have to be object oriented, it does depend on having an expressive implementation of the model constructs, be they objects, rules or workflows. If the available tool does not facilitate that expressiveness, reconsider the choice of tools" - Eric Evans, Domain Driven Design, Ch 5

Now although Eric specifically states that a model-based design doesn't have to follow an OO approach (he gives Prolog/Rule Engines as an alternative), the bulk of the rest of his book does demonstrate how to model a domain using OO techniques. I guess that is why I (and maybe most people) associate DDD so strongly with object oriented design.

I wonder if he had written his book in 2020 he would have included functional modeling approaches along side the OO examples.

As a programmer :

1. The C++ Programming Language by Bjarne Stroustrup.

2. Operating System Concepts by Silberschatz

3. Compilers by Aho

As an agile software developer:

1. eXtreme Programming by Kent Beck

2. Pragmatic Programmer by Hunt and Thomas

3. Continuous Delivery by Jez Humble

As an architect:

1. Domain Driven Design by Evans

2. Pattern-Oriented Software Architecture by Buschmann

3. Envisioning Information by Edward Tufte

As a CEO:

1. Good To Great by Collins

2. Lean Startup by Eric Ries

3. Beyond Budgeting by Pfläging

For those who want a good overview and don't fancy the slog I'd recommend taking a look at http://www.infoq.com/minibooks/domain-driven-design-quickly - a 100 page summary of the book from InfoQ.

The original is definitely worth a read - the summary might let you see why it's worth the effort ;-)

There is an argument that OO is bad because it's so hard to do well. I have yet to be convinced that the same doesn't apply to Functional Programming.

* Fred Brooks - Design Of Design

* Fred Brooks - The Mythical Man month

* Eric J. Evans - Domain Driven Design

* Design Patterns: Elements of Reusable Object-Oriented Software

* Kent Beck - Extreme Programming Explained

* Kent Beck - Planning Extreme Programming

* Michael C. Feathers - Working Effectively with Legacy Code

* Daniel Kahneman - Thinking, Fast and Slow

[EDIT] Correct the author for legacy code

[1] http://www.amazon.com/Domain-Driven-Design-Tackling-Complexi...

I think if someone would dislike microservice if they don't understand the following points very well:
1: The business model of the system you are working on.
2: how to design/develop business models – write a bunch of CURD services on top of database doesn't count.
3: define business boundary is far more important than you think, especially you are working on some projects for computerizing real world business operations.

Strongly recommend reading Domain-Driven Design book.

I thought it was common knowlegse that if really wanted to do configuration right on a given project, you do all 4 (with some library support) and you write your code to gracefully handle the right piece of configuration from the appropriate "override level" (again usually with the support of a good library).

See also: Domain Driven Design[0] which (if you ignore the consultant-fodder and jargon that comes with it) is probably one of the best written guides of how you should abstract systems, just like the gang of four book is a good introduction to structures in program/algorithm implementation you're likely to see in real life.

[0]: https://en.wikipedia.org/wiki/Domain-driven_design

What do you think of this? http://sourceforge.net/projects/timeandmoney/.

I haven't used the library, but its author (Eric Evans) is an old Smalltalker who wrote a good book, Domain Driven Design, in which the examples are in Java. The book is immersed in OO but also kind of points the way beyond OO into something more like "how to develop domain languages", which I find more interesting.

The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what "domain" they fall into. Nevermind that "domain" is basically undefined and can mean many different concepts and different types of concepts. DDD has some decent and good ideas, and is over extended to "this is how you should set up everything." Build more platforms where the domain logic exists in user land, not in code land. Everyone will be more productive for it.

The book Domain Driven Design is also terribly written. Good ideas written by someone who should not communicate with humans.

I think that's actually a very high bar and most code I've seen doesn't "make sense" in that if some non-developing stakeholder looks at it they won't go "oh, ok, I see what this is about" but instead "ok this is a bunch of technobabble that I couldn't possibly understand."

And read or at least skim the "Domain Driven Design" book by Eric Evans. His concept of a "ubiquitous language" is necessary for code that makes sense.

I still don't get it why I've seen so few Node.js applications using Application Service layers, Domain Models and Repositories, and instead clog their MVC containers with calls to whatever datastore directly, with no Domain Model at all.

* The Pragmatic Programmer
* Clean Code
* The Clean Coder
* Domain-Driven Design
* Growing Object-Oriented Software, Guided by Tests

All of these books take the simple maxim:

"Be organized, and stay organized"

and spend thousands of pages expanding on that.

Books like Domain Driven Design are helpful for people who don't know how to program cleanly, but the most important thing is really mentorship from a good programmer. People need code reviews that are firm and guide them in the right direction.

Generally, if you want to work with product development, please learn the importance of good abstraction, readable code, clarity, doing the simplest thing, refactoring, and so on.

Most of the time, you can get away with just hacking away until it works. But code bases developed like that tend to develop tons of incidental complexity, weird logic, unintelligible ownership issues, etc.

Clever algorithms are awesome, but don't let cleverness and complexity grow like vines. Code is like a bonsai tree or something: you have to be meticulous and responsible in pruning it.

Check out SICP. It's a beautiful book that teaches very good design.

Also, take every opportunity to really learn about the languages you code in. Like, if you code JavaScript, you should understand its scoping rules, how its closures work, its peculiar object semantics, its various crazy quirks, etc.

Don't underestimate the value of time. Learn when to take a shortcut, and how to isolate "shortcut code" into a module that can be replaced or improved if needed.

If you're interested in design patterns, read Gabriel's "Patterns of Software" -- http://dreamsongs.net/Files/PatternsOfSoftware.pdf -- for a more nuanced view than most courses and articles.

If you're into OO design, read Eric Evans's "Domain-Driven Design," and take heed when he emphasizes the importance of domain language and concepts.

Learn how to use some structured to-do system efficiently. Don't try to juggle dozens of random things in your memory. If you realize you will need to do something after you're done with debugging or whatever, you should be able to quickly jot it down.

Learn methodical debugging. Learn to narrow down your problems.

Read books like "The Pragmatic Programmer," "The Passionate Programmer," "Working Effectively With Legacy Code," and so on.

* Design Patterns: Elements of Reusable Object-Oriented Software

* Refactoring: Improving the Design of Existing Code

* Clean Code: A Handbook of Agile Software Craftsmanship

* Code Complete: A Practical Handbook of Software Construction

And some others:

* Working Effectively with Legacy Code

* Domain-Driven Design: Tackling Complexity in the Heart of Software

The book that brought me OO enlightenment was Eric Evans' Domain-Driven Design: Tackling Complexity in the Heart of Software. The book is quite dry and, in the small, it seems to describe nothing new, but by the end it was quite deep.

For impatient readers, I recommend Abel Avram and Floyd Marinescu's Domain-Driven Design Quickly, available as a free PDF: http://www.infoq.com/minibooks/domain-driven-design-quickly

Right now I've got:

- Design Patterns by the Gang of Four

- The DevOps Handbook by Gene Kim

- The Phoenix Project by Gene Kim

- Designing Data-intensive Applications - Martin Kleppmann

- Peopleware - Tom DeMarco

- Code Complete - Steve McConnell

- The Mythical Man Month - Frederick P Brooks Jr

- Growing Object-Oriented Software - Steve Freeman

- Domain Driven Design - Eric Evans

- The Clean Coder: A code of conduct - Robert C martin

- The Pragmatic Programmer - Andrew Hunt

- Building Evolutionary Architectures - Neal Ford

- The Design of Everyday Things - Don Norman

- Don't Make me think - Steve Krug

* Enterprise Integration Patterns (basically an entire book about messaging architectures) [1]
* Vaughn Vernon's books and online writing [2],
* Domain Driven Design by Eric Evans [3],
* and most of what Greg Young, Udi Dahan, and that constellation of folks has done online (lots of talks and blog articles.)

Depending on your platform of choice, there may be others worth reading. For my 2¢, the dragons are mostly in the design phase, not the implementation phase. The mechanics of ES are pretty straightforward—there are a few things to look out for, like detection of dropped messages, but they're primarily the risks you see with any distributed system, and you have a collection of tradeoffs to weigh against each other.

In design, however, your boundaries become very important, because you have to live with them for a long time and evolving them takes planning. If you create highly coupled bounded contexts, you're in for a lot of pain over the years you maintain a system. However, if you do a pretty good job with them, there's a lot of benefits completely aside from ES.

[1] https://www.amazon.com/Enterprise-Integration-Patterns-Desig...

[2] https://vaughnvernon.co

[3] https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

It's applied heavily in the enterprise world simply because it's so powerful. In general as the domain logic becomes more complex the benefits of doing this increase.

Actually, not encountering this style in code-base which is solving a complex problem is a massive warning sign for me. It usually means that concepts are poorly defined and that the logic is scattered randomly all over the code-base.

Apps Hungarian is just a logical style: name functions, variables, types so that they're meaningful within your domain. The result of which is code which is very easy to understand for someone who understands the domain. This doesn't mean long names - if you're doing anything math intensive then using the short names which conform to the norms of the field is perfect. For a business process it probably isn't :)

Don't take this as advice against learning what you want to learn, but I'd caution against the idea that "object-oriented programming" and "good programming" are the same thing (or even that they are correlated). OO in its various incarnations comes with a tremendous amount of baggage. It took me years to figure out I didn't need it, and that insight made me a much better programmer.

"Nine Algorithms That Changed the Future: The Ingenious Ideas That Drive Today's Computers" - John MacCormick

"Domain Driven Design" - Eric Evans

"Artificial Intelligence: The Basics" - Kevin Warwick

...and on the Project management / Executive side:

"Agile Project Management with Scrum" - Ken Schwaber

"Reality Check" - Guy Kawasaki

"Founders at Work: Stories of Startups' Early Days" - Jessica Livingston

Of books that are more on the craft of programming, "Refactoring" (Also Fowler) is good. And I enjoyed "Practical Common Lisp" by Peter Seibel too.

In general, I suspect that the value of a book has more to do with where the reader is, than where the book is.

Here are the blue and red books.

Martin Kleppmann's Designing Data-Intensive Applications. Based on the frequent praise it receives here, haven't gotten far yet. I have some project ideas (for personal and professional projects) that could benefit from reading through it.

Martin Fowler's 2018 update to Refactoring. I read the original one a long time ago. In context, we have a work lunch & learn series and I'm interested in doing some presentations on the topic of refactoring (why, how, and when in particular) so it seemed appropriate to refresh my memory on some specific terminology from the book as well as to see if it's an appropriate book to recommend to colleagues. My recollection of the first edition is that I'd recommend it to colleagues, but it's been so long I'd rather read it once more before actually recommending it.

I reread Robert C. Martin's Clean Code based on some recent discussion here where it was rather strongly dismissed by a fair number of people. I didn't recall it being bad, my reread confirmed it is not, in fact, bad. Java-heavy, which is now an unpopular style of OOP, but otherwise a very good book. I'd still recommend it to junior colleagues paired with some caveats about avoiding seeing the world in black & white. There is no singular Way of Programming, but learn various ways and find what works for you and your team.

There are some more, but it's almost 5am and I haven't been able to sleep so I don't recall everything that's in the book stack or ebook queue. These are the ones I'm most interested in at present.

I have for some time been attempting to learn everything I can about automated theorem proving. A key paper is Robinson's 1965 paper "A Machine-Oriented Logic Based on the Resolution Principle". It uses quite different notations compared to, say, Kowalski's "Logic for Problem Solving". Robinson made an important contribution, but his work is like the assembly language of logic. Modern papers are much higher level. Kowalski's book is 1979, so its like C. My new domain map made these works much more comprehensible, especially as I switched between them.

The other good point is patents. That's why I'm reading papers from 1965 and books from 1979.

Architecture with a big A is something that is often looked down upon in this community, because it has the bad rap of being over-engineered, not scalable, "done by contractors who don't know anything/are trying to pad billable hours", et cetera.

I can see this in the kind of schlock being peddled as the next great front-end/web solution; usually done by people who would do very well to revisit the last 30-40 years in thinking about the Design of software. Thinking that testing and TDD are replacements for and/or better than static typing is Pretty Fucking Stupid™.

Design Patterns as given by GoF, Fowler, etc are more often than not questionable, but design patterns extracted from your code base are worth their weight in gold.

We have a beefy .NET codebase composed of some 80+ projects (used to be more then we trimmed it down) integrating with 25+ external data sources/APIs and we have leveraged every single fucking thing out there to make sense of it and not let it overwhelm our systems.

Type-level invariants along with a layered validation system is definitely something that we made a bet early on and it paid off. It's very hard to mess it up once it is in place, and not that difficult to understand.

Some of the things we applied are discussed in Enterprise Architecture by Fowler, the Domain Driven Design book also discusses it a bit. Your own application of these principles is what matters, and that's where things get hairy.

.NET/C# is nice because it provides enough facilities through Reflection and Attributes to be able to "pattern"-ize some of the things that come up, and there are other languages that do it better still. I really like Ruby's method_missing and I wish that C# provided an equivalent, but to my knowledge most of the approaches within C# to do something like that are kludges at best.

I highly recommend Eric Evans' book "Domain-Driven Design: Tackling Complexity in the Heart of Software" (2003) mentioned on this page. It is a bit of slog, but worth it.

Or for a quick introduction to domain-driven design, check out the (free download) of "Domain Driven Design Quickly" e-book from InfoQ:

https://www.infoq.com/minibooks/domain-driven-design-quickly

Patterns of Enterprise Application Architecture by Martin Fowler.

Domain Driven Design by Eric Evans.

Growing Object-Oriented Software, guided by tests by Steve Freeman and Nat Pryce.

What are some books you find your self going back to repeatedly (or want to)? My list:

- Domain Driven Design

- Ray Bradbury's short stories and Farenheit 451

- George Orwell's Down and Out in Paris and London, The Road to Wigan Pier

- Descent into Hell

- LotR, the Hobbit, and Narnia

- Hitchhiker's Guide to the Galaxy

- Psalms, Job, James

- The Rare Jewel of Christian Contentment

- Wendell Berry's Essays

- Winnie the Pooh

- Augustine

Guess you know what kind of person I am now.

I understand how what I'm suggesting can lead to an Anemic Domain Model antipattern, but I doubt that Martin Fowler suggests to have fat domain models with extremely low cohesion.

I will, without a doubt, check out the Domain-Driven Design book that Martin Fowler refers to.

Thanks for the comment.

The older generation are in this place because back then none of the technologies you listed existed and so they had to know the more low level things.

A book that might help some of your knowledge gaps (at least directionally) is The Imposter's Handbook[1] by Rob Conery.

If you're specifically aiming to get away from CRUD take a look at the various Domain Driven Design books by Eric Evans[2] and others. This is the opposite direction to your ask though (more high level than low level).

If you want to go deeper in Java, read Effective Java[3] and Java Concurrency in Practice (JCIP)[4]

Lastly, if you want to experience the reasons why some of that early comp-sci stuff happened the way it did, playing with expensive hardware is the least effective way to find understanding of constraints. Instead consider grabbing devices with significant limitations like an Arduino, ESP32, or similar (I'm partial to the Wio Terminal[5] and M5Stack[6] as interesting easy to get started devices, but others would suggest various Arduinos or Raspberry Pi devices). Realistically you're going to learn much more by coming up with a self-challenging project and completing it than just by learning it for the sake of learning.

[1]: https://bigmachine.io/products/the-imposters-handbook/

[2]: https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

[3]: https://www.amazon.com/Effective-Java-Joshua-Bloch/dp/013468...

[4]: https://www.amazon.com/Java-Concurrency-Practice-CONCURRENCY...

[5]: https://www.seeedstudio.com/Wio-Terminal-p-4509.html

[6]: https://m5stack.com/

Refactoring is better because it's on a smaller scale and thus able to deliver roughly what it promises.

As far as the enterprise-OO space goes, though, the best book by far IMO is Eric Evans' Domain Driven Design. One reason it's better (apart from being superbly written) is that it's much more exploratory: it doesn't pretend to have figured things out, but rather offers principles you can use to figure things out. Also, the principles, though deep, are easy to understand (as opposed to "enterprise application architecture patterns" which get more confusing the more you try to understand them). In fact, the only weak spots in DDD are the points at which it veers closer to the PEAA approach.

(Disclosure: I worked with Eric for several years. But my high opinion of his book was not caused by this; it was the other way around.)

In the case of the book/approach, the problem is that the IT side doesn't match the business side (in terminology, code organization, etc.). The solution is for IT to become more aligned with the rest of the company.

But in the case of your comment and the article, the mismatch seems to work the other way around. Out of some 'two-pizza methodology' or whatever, the business side now has to split up what should be a single problem/domain in a nonsensical collection of different domains.

I might be entirely off here, though. But if I'm not, is this problem perhaps particular to companies where IT is more in charge than in the types of companies where DDD has been a solution?

Finding an appropriate language/notation for a problem is perhaps the most important step in solving it. But it's also perhaps the hardest. Most software projects don't try. That's one reason most software is a mess.

More widely, addressing the slightly snidey remarks about C++, which form the basis of most attacks on design patterns - this idea that design patterns are snippets of code certainly did take root, and persists to this day. Even with DDD, people missed many of the more interesting 'soft' factors addressed, and walked away from the book thinking all they needed to do was rename their data access objects 'repository'.

But it's utterly useless to say that iterators as a concept are pointless because foreach exists (and whether or not the author wants to believe people are missing the point, this is the foot they launch off from). Languages with first class functions are popular today, and I still hear that you don't need the strategy pattern because of this. And yet I look at Python's urllib (literally today), and its retry mechanism is configured by supplying a value telling it what to do. It's doesn't expose an interface to make the decision yourself. Design patterns in software (whatever the ancestry of the phrase) give you a better granularity to discuss, think about and plan software design. Sure, we have more retrospective patterns, but that's as much to do with the fact that we make a ton more software than architects make buildings.

I certainly agree that we haven't, as a community, got full value out of even our own interpretation of design patterns. But I don't think it's because of any of the issues described in this talk, and I certainly don't think it's because of the limitations of our programming languages.

[1] https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...

[2] https://www.microsoftpressstore.com/store/object-thinking-97...

Eric Evans wrote a big book called Domain-Driven Design about these things, but his advice basically boils down to this.

In addition to the books mentioned in above link I'd like to wholeheartedly recommend Domain Driven Design by Eric Evans. I've found the described approach very helpful in design of enterprise applications on the Java platform.

--------------------------------------

Clean Code (Robert Cecil Martin)

The Art of Unit Testing (Roy Osherove)

Head First Design Patterns (Elisabeth Freeman, Kathy Sierra)

Martin Fowler's blog: https://martinfowler.com/

.

How to gather requirements and write business-readable code:

--------------------------------------

Domain-driven design (Eric J. Evans)

Implementing Domain-Driven Design (Vaughn Vernon)

Patterns, Principles, and Practices of Domain-Driven Design (Scott Millett)

.

Remaining agile and managing your work according to your clients' needs:

--------------------------------------

The art of doing twice the work in half the time (Jeff Sutherland)

The Mythical Man Month (Fred Brooks)

Code Complete: http://cc2e.com/

Introduction to Algorithms (google that one, it's hard to find a good link)

Domain Driven Design: http://domaindrivendesign.org/books/evans_2003

Design Patterns: Elements of Reusable Object-Oriented Software

The term "web development" doesn't mean much. There is web design. There is application development. When the two mix, there is web application development. Any kind of application development is hard, and simply knowing a language or two isn't going to make you a good application developer any more than knowing english will make you Stephen King. (IMO)

In algebraically or mathematically oriented communities like much of the Haskell world, you see a similar kind of "bottom-up programming" but with an added focus on compositional structures with laws for reasoning.

When a Haskell module really comes together beautifully, it's because you've managed to extract useful standalone concepts that combine in an algebraic way, with binary operators, associativity, and so on.

Eric Evans in Domain-Driven Design, usually considered a book about object orientation, also comes to a conclusion that if most of a program's logic can be expressed in pure functions and closed operations on value objects, then you can attain a "supple design."

I suppose the Lisp community has concepts like "value abstractions and syntactic abstractions" or something like that, one of them being related to well-suited data types, and the other being related to macros.

Incidentally, I've recently come to realize that Agda, the dependently-typed Haskell-style language, comes very close to being Lisp-like in its support for syntactic abstractions: you can go a long way with just custom mixfix operators (e.g., defining if_then_else_)... and then there's also a sophisticated macro system, using an AST data type and a "typechecker monad."

It's a lot of fun!

Designing Data Intensive Applications.

Some books on leadership from the recent HN discussion, not decided which yet.

Death's End (book 3 of The Three Body Problem). The first two were really good.

The Algorithm Design Manual. Domain Driven Design.

Some chess books. Some general science and history. The yearly random self help book.

If I manage all that plus whatever I'll decide I want in the actual year, it will be a good year for reading, but maybe I need to have some more focus. We'll see.

Domain Modeling Made Functional by Scott Wlaschin

Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

Practical Object-Oriented Design in Ruby: An Agile Primer by Sandi Metz

Fiction:

Wired Love: A Romance of Dots and Dashes by Ella Cheever Thayer - I saw this mentioned in a HN comment[0].

Rebecca by Daphne du Maurier

[0] https://news.ycombinator.com/item?id=14530693

Edited to fix formatting and add a missing book.

Patterns of Enterprise Application Architecture - by Martin Fowler
Domain Driven Design - by Eric Evans

* Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans)

* F# Deep Dives (Tomas Petricek and Phillip Trelford)

* PostgreSQL: Up and Running AND PostGIS in Action, 2nd Edition (both by Regina O. Obe and Leo S. Hsu)

I'm eyeballing Purely Functional Data Structures by Chris Okasaki (1999) and a few others for after I finished the Postgres books.

Domain Driven Design (The book is hard to read, but worth it I think)
http://martinfowler.com/tags/domain%20driven%20design.html

This uncle bob talk is not too bad
https://www.youtube.com/watch?v=WpkDN78P884

I think the microsoft guide is the most comprehensive, but don't limit yourself to it.

For me code is just a tool for modeling/solving problems in the outside world. It is the outside world that is interesting. I think the emphasis in the article is the right one. If more people focused on applied mathematics rather than category theory then we probably would get more innovation. Eric Evans said something similar in Domain Driven Design "Instead, the technical talent goes to work on elaborate frame-works, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance."

One problem though is that I do like lisp and its lineage (smalltalk etc). Had to take fortran years ago. Never really liked it.

As I alluded to there are many approaches to this problem, but one that I like is more or less just what you suggest: set aside some amount of time every sprint to tackle the legacy codebase. The eventual goal is to bring it up to the newly accepted standard which requires tests, but realistically that will take a while. Live bugs provide a sort of direction to help facilitate updating the legacy codebase. Setting aside a set amount of time each sprint makes sure that the issues don't get swept aside.

It's important to get to the point where fixing live bugs isn't impeding the development of new features, but until then it's simply pragmatic to set aside some amount of time to hedge against new issues, while also having the discipline to set one aside if it can wait until the next sprint.

As an aside, some of the best patterns on the subject of dealing with legacy systems can be found in the later chapters of Domain Driven Design by Eric Evans, particularly chapter 14, Maintaining Model Integrity.

Not entirely, anyway. You can't turn the whole app into a good one in any reasonable time, but when you fix a bug, take time to apply the boy scout rule ( http://www.informit.com/articles/article.aspx?p=1235624&... ) Don't put that down as a separate task that your management can approve or deny, it's part of doing the job of coding properly. That way, at least the buggy parts of the app get better.

You should not be focused only on your career when making coding and tech decisions, but look at it this way: in a year's time, you're in an interview for a job you really want. What are you going to say "I can read and maintain shitty code" or "I can make shitty code better"?

Also consider: documenting your app's architecture (or lack of it) and conventions (or lack of them).

Also consider: reading up on architecture, testing, refactoring and code quality. If nothing else, these will help you get your next, better job. Off the top of my head, try "Domain Driven Design" by Eric Evans, "Growing object-oriented software guided by tests", "Refactoring" By Martin Fowler, and on the last topic "Clean code" by Robert Martin and "Code Complete" by Steve McConnell

Big ball of mud apps (http://www.laputan.org/mud/ ) may be common, but it doesn't have to be that way - you can learn some pitfalls to avoid

"Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modelling the domain is left to others. Complexity in the heart of software has to be tackled head on. To do otherwise is to risk irrelevance."

- From Domain Driven Design by Eric Evans.

Also in the original article is this:

"Except for the most senior software engineers, most of the creativity and innovation in software will move to specialised design and research activities using techniques that exceed the reductionist thinking that dominates computer science departments."

I think that part of the problem is that we need very few real computer scientists (but they are needed). However most people who want to build software are trained as computer scientists. The people who train them naturally teach them to value things that are useful to computer science research but this can cause them to be limited when it comes to solving real world domain problems holistically.

Or as patio11 says "Don't call yourself a programmer" http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...

Basically, it’s not about the code. It’s about the form following the function. That is, first, deeply understand the context and purpose of the software, and the structure will follow.

I also recommend “Domain Driven Design” by Evans. But, a warning - it’s dry. There are a lot of “DDD in Java” code examples out there.

You could go back amd re-read “Code Complete”, and other early Microsoft Press books. Though, some are probably dated.

The Robert Martin books can be also useful, at least in thinking about how to maintain low coupling, high cohesion.

Oh, and “Working with Legacy Code”

Unfortunately, none are specifically Java related. How to structure systems is an art that requires practice. So, maybe start off with some small toy projects, just to get warmed up.